[05:10] <mmcc> back, looking into fsevents code again…
[05:15] <mmcc> two separate bugs in this code
[07:27] <mmcc> email sent, time to go.
[08:33] <JamesTait> Good morning all! :)
[09:51] <mandel> morning all!
[10:47] <mandel> ok, I'm of to have lunch
[10:47]  * mandel lunch
[11:13] <gatox> good morning
[12:21] <alecu> hello all❗
[12:32] <gatox> alecu, hi
[12:50] <ralsina> morning!
[12:51]  * ralsina reads backlog, decides to explain mandel the true meaning of timeshifting
[12:52] <ralsina> mandel: the idea is that you finish late because you START LATE
[12:57] <gatox> ralsina, hi
[12:59] <ralsina> hi gatox
[12:59] <ralsina> gatox: how do you feel this nice feature-freezing morning? ;-)
[13:00] <gatox> ralsina, jeje fine.... i'm adding the behaviour behind the ui now
[13:01] <mandel> ralsina, meh, details
[13:02] <mandel> gatox, question, where is the source code of the fsevents you sued, specially the one with your changes?
[13:02] <gatox> mandel, https://code.launchpad.net/~diegosarmentero/+junk/python-macfsevents
[13:03] <ralsina> gatox: no rush on that
[13:07] <ralsina> gatox: since mmcc and mandel are sprinting, could you be extra alert for reviews, specially those for mac they propose?
[13:08] <gatox> ralsina, ok!
[13:08] <ralsina> gatox: also, stop whining about designer, which is pretty, nice, and the best thing since non-sliced bread! ;-)
[13:08] <mandel> alecu, ping
[13:09] <gatox> ralsina, jejejeje
[13:09] <ralsina> mandel: did you see the RT mail? They will be killing monorail and setting up a beefier box in "a week"
[13:10] <mandel> ralsina, no I did not see it.. nevertheless it would be nice to finish setting it up so that we have jenkins and send them all the instructions to follow
[13:11] <alecu> mandel: pong
[13:11] <mandel> ralsina, sidnei filled a second RT so that monorail can connect to canoncical stack so that the slave can connect
[13:11] <ralsina> mandel: yes, but I would like clarity on whether it's going to work and be useful this week, or if you should just drop that and move onto other stuff until the new box is up
[13:11] <mandel> ralsina, I don't think it will be useful :(
[13:11] <ralsina> mandel: therefore it's not urgent anymore
[13:11] <ralsina> mandel: pick your battles, etc.
[13:12] <ralsina> mandel: a jenkins that takes 12 hours to run a job is the opposite of useful ;-)
[13:12] <mandel> alecu, what are we doing with fsevents, we already have gatox patches on top of it, I think we can push mmcc changes upstream but we shoud not ignore events, that is, send a create and a modify and wrap the modify in our code with an open & close_write
[13:13] <mandel> ralsina, ack
[13:13] <mandel> alecu, gatox, why did you not push the changes you maid upstream?
[13:14] <gatox> mandel, i have to propose my changes to the official repo of macfsevents..... but i've been busy with th menu and share links features
[13:14] <alecu> mandel: I did not understand your proposed solution ("send a create and a modify and wrap the modify in our code with an open & close_write")
[13:14] <gatox> mandel, i can do it today if necessary
[13:15] <alecu> gatox, mandel: wait
[13:15] <alecu> gatox: mmcc sent an email yesterday, with some issues he found on macfsevents
[13:15] <alecu> gatox: so we should propose both things upstream
[13:15] <alecu> gatox: I'll fwd you the mail
[13:17] <mandel> alecu, what I say, is, quoting the email: 'and fsevents.py ignores the second one.' and then his fix proposes and improved way to ignore the event by switching to !=. My idea is to send both events to upper layers
[13:17] <mandel> alecu, we get a create and a modify and is the second event, the modify which we wrap with an open and close_write just like we already have in our code
[13:17] <mandel> alecu, by the way, it is because we get two events that the root daemon works
[13:19] <alecu> mandel: you've only sent that mail to me!
[13:19] <alecu> mandel: would you mind re-sending it, and cc gatox.
[13:19] <mandel> alecu, puto evolution! sure
[13:23] <mandel> alecu, should have been sent to all
[13:23] <mandel> alecu, so, we need to send this to upstream, the way I see it fixed is by not ignoring events and if an event has two flags, generate two events
[13:23] <mandel> the lower level lib should not be trying to be smart
[13:24] <alecu> mandel: +1. The less brains we have, the lower the chance we'll meet zombies.
[13:25] <mandel> alecu, yes, I have tried to be smart before hehe
[13:26] <mandel> gatox, how manyu bugs did you have to fix? can you send me the info and I'll try to make it to the trunk, smae with the mmcc changes and I suppose we should add tests etc..
[13:27] <gatox> mandel, ok, i'll send you an email
[13:27] <mandel> gatox, thx, lets try to get this fixed :)
[13:48] <joshuahoover> dobey: as far as you know, is the u1db package ready to go? bug #1035392
[13:52] <dobey> joshuahoover: it's done. i guess the lp auto-bug-fixer thing didn't set it to fix released
[14:12] <mandel> alecu, ralsina, I think that we should agree to use the same cvs when we fork something mainly to keep the history and know when we did the fork..
[14:12] <alecu> mandel: right
[14:15] <mmcc> morning folks, making coffee, catching up, brb
[14:19] <thisfred> mmmm, coffee!
[14:28] <mmcc> mandel, you are right that we need to send both events - but we do still need to check the mtime against the snapshot because we only get per-directory events.
[14:29] <mmcc> we can't get rid of the != check, because it's in a loop comparing all files in the snapshot to all files we've just seen - trying to figure out which file or files the event is about
[14:31] <mandel> mmcc, oh, true..
[14:31] <mandel> I forgot it was per directory, lame
[14:31] <mmcc> mandel: right :\
[14:32] <mmcc> there is a way to get per-file events from the code, but it's possible that we'd have to take snapshots anyway, since it might coalesce events (and I'm not sure it sends the file paths when it does, just dir paths)
[14:34] <mandel> mmcc, I'll work to get gatox changes in and will look at your code to add tests and try to send this upstream
[14:36] <mmcc> mandel: sounds good - do you mean get his changes into my version? I branched from his version, so that's done already
[14:36] <mandel> mmcc, no, try to put this upstream plus your changes
[14:36] <mmcc> mandel: aha, ok. sounds good
[14:36] <mandel> mmcc, also add tests to our u1client code so that we do know everything works
[14:37] <mandel> tedious but should be fast to do
[14:37] <mmcc> I like that :)
[14:37] <mmcc> not the tedious part, but the knowing everything works part :)
[14:40] <mmcc> mandel so I'll go back to ctypes and smjobbless now… let me know if I need to explain any of my changes.
[14:42] <mandel> mmcc, great, let me know if you need any help
[14:43] <mandel> mmcc, also it looks like we are behind the current trunk of mfsevents (if you branched from gatox code) so we might have so extra bug fixes for free
[14:43] <mmcc> mandel, interesting. looking…
[14:45] <mandel> mmcc, for example, they do have a small diff in the snapshot method, now during the walk the do 'obj in files + dirs' while the fork just goes over files
[14:46] <mandel> mmcc, also, they use lstat and not stat
[14:46] <mmcc> the first one looks like a nice simplification, but shouldn't change behavior ,right?
[14:47] <mmcc> the lstat change is interesting - what do we do on other platforms with links?
[14:48] <mandel> mmcc, we ignore them and we do not follow them
[14:48] <mmcc> ignore them? so if I put something with a symlink into a synced folder, that symlink won't get synced?
[14:49] <mandel> mmcc, no, the main reason is that we just let you sync under ~ and your link can be outside ~
[14:49] <mandel> mmcc, it is a requested feature
[14:50] <mmcc> hmm.
[14:52] <mandel> gatox, can you please explain me what is going on here: http://bazaar.launchpad.net/~diegosarmentero/+junk/python-macfsevents/view/head:/fsevents.py#L197
[14:52] <mandel> ??
[14:53] <gatox> mandel, do you want to have a quick mumble about this lib behaviour?
[14:54] <mandel> gatox, even better :)
[14:54] <gatox> mandel, after standup?
[14:54] <mandel> sure, is very close
[14:54] <gatox> ack
[14:54] <mmcc> oh hey, standup. thanks for the reminder gatox :)
[14:55] <gatox> mmcc, i always remember..... because i eat after the standup.... and i'm already really hungry jeje
[14:55] <mmcc> :)
[15:00] <gatox> me
[15:00] <briancurtin> me
[15:01] <ralsina> me
[15:01] <dobey> me
[15:01] <mmcc> me
[15:01] <gatox> alecu, mandel thisfred ?
[15:01] <mandel> me
[15:02] <dobey> ralsina ?
[15:02] <gatox> dobey, ralsina is the third one
[15:02] <dobey> oh
[15:02] <dobey> i guess we typed at same time and i didn't see it :)
[15:02] <ralsina> alecuuuuuu
[15:03]  * ralsina is lagged
[15:03] <gatox> zzzz
[15:04] <alecu> me
[15:04] <thisfred> me
[15:04] <gatox> DONE:
[15:04] <gatox> Propose a couple of branche for control panel about New shares in the sync menu and the ui for Share Links tab.
[15:04] <gatox> TODO:
[15:04] <gatox> Finish with Share Links tabs: publish and share functionality.
[15:04] <gatox> BLOCKED:
[15:04] <gatox> No
[15:04] <gatox> briancurtin, go
[15:04] <briancurtin> DONE: lots of branches for dev-tools porting
[15:04] <briancurtin> TODO: one or two remaining dev-tools branches, then push on running sso on py3 and see what happens next
[15:04] <briancurtin> NEXT: ralsina
[15:05] <briancurtin> @ping
[15:06] <mandel> briancurtin, pong!
[15:06] <ralsina> ok, everyone that said me, then alecu then thisfred. Go gatox
[15:06] <mandel> briancurtin, ralsina is the weakest link :)
[15:06] <mandel> ralsina, is your turn.. major lag there
[15:06] <alecu> dobey: go!
[15:06] <dobey> DONE: releases
[15:06] <dobey> TODO: finish releases, icon generating magic
[15:06] <dobey> BLCK: None.
[15:06] <dobey> mmcc: go
[15:06] <mmcc> DONE: ctypes code for SMJobBless, bug hunt in fsevents.py
[15:06] <mmcc> TODO: more SMJobBless & code signing
[15:07] <mmcc> BLCK: no
[15:07] <mmcc> NEXT: mandel
[15:07] <mandel> DONE: Look at fsevents issues. Done some tests to reproduce cases in which is borken. It is with small files (as mmcc mentioned, flags are merged) and in large and slow files such as moving a large file from a samba share. Drag & Drop and Copy also lack a in_modify event. Looked at the code of macfsevents upstream they have fixed a number of bugs that we have not.
[15:07] <mandel> TODO: Chat with gatox about his fsevents and try to understand them. Merge chages with trunk and add the ones proposed by mmcc to trigger both events (CREATE & IN_MODIFY).
[15:07] <mandel> BLOCKED: No
[15:07] <mandel> COMMENT: I'm working 'til late and I'll be taking a 2 - 2:30 (depends on traffic) break for rugby training.
[15:07] <mandel> NEXT: alecu
[15:07] <alecu> DONE: api doc for dash webcalls; got indicator-sync branch working, looks nice; reviews for brian's py3k branches; researched webclient implementation in vala
[15:07] <alecu> TODO: more on the dash
[15:07] <alecu> BLOCKED: no
[15:07] <alecu> NEXT: thisfred
[15:08] <alecu> thisfred or ralsina: go!
[15:10] <dobey> fight to the ping!
[15:10] <dobey> two pings enter, one pong leaves!
[15:10] <gatox> mandel, i'll be back in 5 min and we can have the mumble if you want
[15:11] <mandel> gatox, ok, ping me when you are back
[15:11] <ralsina> DONE: dash talk with alecu & beuno, 1-1 with mandel, reviews, scheduled testing for releases, canonicaladmin, mgmt call, misc. TODO; help around, reviews, etc. talk with dobey about u1ms BLOCKED: no NEXT:  dobey
[15:11] <thisfred> DONE: documentation5 TODO: documentation6(-?) BLOCKED: no NEXT: no
[15:11] <ralsina> Forgot: NOTE: I am terribly lagged, so I will go run some errands & lunch, will be back in about 90'
[15:12] <mmcc> mandel - what was the issue you saw with moving large files?
[15:12] <mandel> mmcc, you wont get the in_modify at all yet with the root daemon you get the in_modify once it has been copied over
[15:13] <mmcc> mandel, I think that'll be the same issue with mtime > snapshot.mtime.
[15:13] <mmcc> I mean, I think the != fix will fix that too
[15:13] <thisfred> question: instead of doing "me" at 11 or up to 5 minutes later, and then waiting for everyone to post their statuses, why don't we skip the "me' and just post the second part at 11. Worst thing that can happen is that some reports may get interleaved, which I don't care as much about as the fact that what could take about 20 seconds takes 10 minutes of interruption
[15:14] <mandel> mmcc, yes, I have the same impression too
[15:14] <thisfred> ralsina, ^^
[15:14] <mandel> mmcc, I have a manual 'script' to go through once everything has been merged with the current work at upstream
[15:15] <mmcc> mandel: we can test that with my script that'll show the raw events from copying over - I was running two separate instances, one raw and one with the snapshots, and comparing the two - that's how I noticed the raw had more events…
[15:15] <mmcc> mandel: ok, I'll let you work then :)
[15:16] <mandel> mmcc, I'm using the one you sent me + the daemon just because I have it installed hehe
[15:17] <gatox> mandel, back
[15:18] <mmcc> mandel: I just meant two separate instances of the test event listening script in the branch I posted, not the rest of u1 client…
[15:18] <gatox> mandel, already on mumble
[15:19] <mandel> gatox, ok, launching the thing
[15:19] <mandel> mmcc, ah, ok
[15:21] <ralsina> thisfred: OR we could all be here at 11 and do it in 2 minutes
[15:21] <thisfred> ralsina, I know, but that has happened never
[15:22] <ralsina> thisfred: I'll take another approach. At standup time, the time for "me" is exactly 2minutes. Then post statuses in order. Those who didn't say "me" give their statuses at the end whenever they are ready.
[15:23] <thisfred> ok, let's see if that works. I do realize I'm at least as much to blame as anyone for it dragging on
[15:23] <ralsina> thisfred: since *I* have to read all the statuses, and your proposed solution simply mean I have to check everything then hunt those who didn't post
[15:24] <thisfred> it's just that even when I remember to say me, I'm then either waiting staring at my IRC client for 5 minutes or I get distracted and miss it when I'm pinged
[15:24] <ralsina> so, alecu, dobey, mmcc, mandel, briancurtin, gatox, thisfred: tomorrow, I want the "me"s between standup and standup+2 minutes. If you are not here, don't bother me-ing, just post the status at the end
[15:24] <mmcc> ralsina: ack
[15:24] <ralsina> and I will notice those who are late and post bad things about them on twitter
[15:24] <thisfred> that's fine, I quit twitter :D
[15:24] <ralsina> thisfred: and +1
[15:24] <ralsina> thisfred: sorry, google+
[15:25] <ralsina> thisfred: and goodreads
[15:25] <thisfred> hehe
[15:25] <ralsina> thisfred: and facebook
[15:25] <ralsina> thisfred: and posters in telephone posts
[15:25] <mmcc> not twitter! I don't want @The_Real_Shaq knowing I'm late
[15:26] <ralsina> Now that I read what I wrte, are posters called that way because they are put on posts? Or because they were put on post offices? Weeeeeeird.
[15:27] <mmcc> ralsina: http://www.etymonline.com/index.php?allowed_in_frame=0&search=poster&searchmode=none says fasten to a post
[15:27] <mmcc> now that's a site that could soak up an afternoon.
[15:27] <ralsina> mmcc: gives a whole new meaning to "poster boy"!
[15:27] <thisfred> From Old English pillar, door-post and Old French, from Latin postis (“a post, a door-post”)
[15:28] <ralsina> having clarified that, I will now go to the bank
[15:29] <briancurtin> speaking of post offices, i need to run and get stamps to mail two letters as if its 1990. be back shortly
[15:29] <mmcc> briancurtin: be sure to rewind your answering machine's tape before you leave so there's space
[15:30] <briancurtin> haha
[15:36] <dobey> ok, need to get lunch here as well. bbiab
[15:49] <mandel> gatox, how are the fsevents tests ran, the ones in the macfsevents I mean
[15:50] <gatox> mandel, mmm i don't remember... i thought it says in one of the files..... i'll check
[15:51] <mandel> gatox, ok, no worries I can find out
[15:51] <mandel> python setup.py test :P
[16:03]  * briancurtin back
[16:14] <mmcc> gatox, do you remember why you changed the latency parameter to 0 from 0.01 in fsevents?
[16:15] <gatox> mmcc, yes..... so we can receive more events.... and is not perfect, but we started to get more
[16:16] <mmcc> gatox: so it was sending fewer events than changes?
[16:17] <gatox> mmcc, yes
[16:18] <mmcc> gatox: how were you testing it?
[16:19] <gatox> mmcc, i had some scripts (i think that there are in the wiki you created), that generates a lot of folder and files inside
[16:19] <mmcc> gatox: oh yeah, I remember seeing those - thanks!
[16:26]  * gatox lunch
[16:49] <mandel> mmcc, I;'m adding a keyword param so that we pass our on latency and then be able to push it upstream
[16:50] <briancurtin> ralsina: 1-1?
[16:53] <mmcc> mandel, ok. I'm about to send an email with some thoughts on alecu's question about a loaded system.
[16:54] <ralsina> briancurtin: sure, in 5'
[16:54] <briancurtin> ralsina: i'll be in mumble
[17:06] <mandel> ralsina, mmcc I'm off to rugby and I'll be back in a few hours, ok?
[17:07] <ralsina> mandel: ok, have fun, break nothing
[17:07] <mandel> ralsina, break them ;)
[17:07] <mmcc> mandel: ack. dislocate nothing
[17:07] <dobey> break someone else's leg
[17:07] <ralsina> mandel: avoid rabid racoons
[17:07] <ralsina> mandel: walk in the shade
[17:08] <mandel> lol
[17:08]  * ralsina is all about protecting devs
[17:18] <ralsina> briancurtin: which branches from dev-tools need reviews?
[17:18] <briancurtin> ralsina: i'll put together a paste of them, 1'
[17:18] <ralsina> briancurtin: I see 7 from you, all of them?
[17:19] <briancurtin> ralsina: there are 7 necessary for the porting (all prefixed with py3-) and a general one i just added a min ago
[17:20] <ralsina> briancurtin: ack, will do those 7 then
[17:35] <ralsina> briancurtin, alecu: confirmed success with the proxy working 100% on windows on 3.0.2b :-D
[17:35] <briancurtin> yessssss
[17:35] <ralsina> <fist pump>
[17:36] <ralsina> briancurtin, alecu: there is even a chance that PAC scripts may work since they are supported in latest Qt
[17:36] <ralsina> at least in some cases
[17:42] <ralsina> briancurtin: reviewing py3-int. You are not letting me run the test MAXINT*2 times, you fascist!
[17:42] <ralsina> briancurtin: but more seriosuly, those one-line, obvious branches can merge with one review :-)
[17:43] <briancurtin> ralsina: i guess i got used to covering higher quantity changes from SSO in isolation by type
[17:44] <briancurtin> but yeah i probably should have just merged them in the end
[17:44] <ralsina> briancurtin: no, the small branches are ok, it's just that those can merge with one review
[17:44] <ralsina> briancurtin: it's a bonus for doing small branches :-)
[17:45] <briancurtin> ahh
[17:47] <briancurtin> ralsina: how do you tell LP to do one review for say three small branches?
[17:48] <ralsina> briancurtin: LP doesn't require more than one review
[17:48] <ralsina> briancurtin: so, if you feel the branch is trivial, you just approve it ater you got one
[17:48] <ralsina> briancurtin: personal judgement, we are all consenting adults, etc
[17:49] <briancurtin> ralsina: oh oops i was mixing review with merge proposal, i thought you meant there was some secret way to do one MP for multiple branches. i got it now
[17:49] <ralsina> briancurtin: ah, ok
[18:03] <dobey> thisfred, mmcc: https://code.launchpad.net/~dobey/ubuntu-sso-client/update-4-0/+merge/120626 please
[18:06] <ralsina> dobey: mmcc is sprinting, I'll get it
[18:06] <dobey> oh
[18:09] <thisfred> dobey, +1
[18:14] <ralsina> dobey: +1 from me too
[18:29] <alecu> ralsina: it seems you still can use bigger than int loops in tests:
[18:29] <alecu> >>> int(sys.maxint*2)
[18:29] <alecu><PHONE_NUMBER>3709551614L
[18:29] <alecu> ralsina: anyway... those 3.0.2b news are wonderful!!!
[18:30] <alecu> briancurtin: you've seen the comment I added to this branch, right? https://code.launchpad.net/~brian.curtin/ubuntuone-dev-tools/py3-io/+merge/120478
[18:33] <briancurtin> alecu: i didn't see that yet, but i'll get it fixed up
[18:33] <ralsina> alecu: cool, I will let my test runner working until the heat death o the solar system ;-)
[18:37] <alecu> ralsina: we need a way to have jenkins survive thru the next implosion+bigbang cycle
[18:38] <ralsina> alecu: latest cosmological measurements show universe will expand indefinitely, so problem solved
[18:39] <alecu> let's find a way to keep jenkins atoms close together enough then!
[18:39]  * briancurtin lunch
[18:41] <ralsina> alecu: I propose rubber bands.
[18:45] <dobey> le sigh
[18:54] <dobey> i'll have to duck out early today in ~40 minutes, as I have to go somewhere ~30 miles away to pick up a freight shipment and it will take some time to get down there and back, but i'll try to get some more work done later tonight, or work longer tomorrow to compensate
[19:05] <ralsina> dobey: ok, np
[19:05] <ralsina> dobey: where are we on releases?
[19:05] <ralsina> dobey: also, "a freight shipment"? What are you buying? Collectable fridges?
[19:06] <dobey> having to discuss one of the bits with security
[19:06] <dobey> ralsina: an engine
[19:06] <ralsina> dobey: ack & ack
[19:06] <ralsina> dobey: and awesome.. I never knew someone that had bought an engine :-)
[19:08] <ralsina> briancurtin: I am finishing with your devtools branches, but ne has a needsfixing
[19:08] <ralsina> *one has
[19:09] <ralsina> dobey: the stable-4 branch for sso failed to merge
[19:09] <ralsina> dobey: with a metric ton of lint!
[19:09] <dobey> i know
[19:09] <ralsina> dobey: ok
[19:09] <dobey> ralsina: already fixed it, and already merged :)
[19:10] <ralsina> dobey: awesome :-)
[19:10] <dobey> and i'm talking with security now
[19:12] <briancurtin> ralsina: thanks, i'll take a look
[19:26] <dobey> alright, gotta run. may be back later tonight. cheers all!
[19:36] <ralsina> briancurtin: I am looking at your keys-usage branch an I am not sure it does the same thing after the change
[19:36] <ralsina> briancurtin: or rather, I am sure it doesn't do the same thing, but maybe it's still ok :-)
[19:37] <ralsina> briancurtin: specifically, it now executes the succeed in the case where self.wrapper.protocols.keys is empty and befre it didn't
[19:37] <briancurtin> ralsina: if keys is empty it wouldn't iterate over anything and would fall to the else
[19:37] <ralsina> yes
[19:38] <ralsina> briancurtin: let me think a bit more ;-)
[19:38] <ralsina> briancurtin: yes, it didn't do that before
[19:38] <ralsina> before, if keys was empty, it would not fall to the else
[19:39] <briancurtin> if keys was empty "if connected" would be false, so it would fall to the else
[19:40] <ralsina> briancurtin: ok, then, I got it backwards. If keys is not empty, now it will fall to the else and before it wouldn't
[19:40] <ralsina> since the else is executed whenever there is no break
[19:41] <briancurtin> ralsina: ah, yeah
[19:42] <ralsina> briancurtin: again, not sure if that's actually bad because I don't have enough context
[19:42] <briancurtin> ralsina: i'll look into it
[19:42] <briancurtin> good catch
[19:42] <ralsina> briancurtin: thanks
[19:42] <ralsina> briancurtin: I looked extra hard because I never remember what for/else does :-)
[19:43] <briancurtin> it seems like that should be the operation of for/finally (if it existed)
[19:44] <ralsina> briancurtin: exactly
[19:44] <ralsina> else should be "do this if you didn't actually iterate because that thing was empty"
[19:48] <mmcc> ok, with my ctypes-wrapped code not crashing but not giving useful errors either, time for lunch…
[19:49] <alecu> ralsina: oh, I totally missed that else.
[19:50] <alecu> briancurtin: I think you should add some test cases for the changes in that particular branch.
[19:51] <briancurtin> alecu: i'm thinking about if changing that one is actually worth it
[19:52] <alecu> briancurtin: perhaps it's not worth it, if we are changing the behaviour for wrong! :-)
[19:53] <briancurtin> yeah it's actually fine as-is, or it wouldnt get any cleaner if i was to mess with it
[19:56] <ralsina> then I have no more branches to review :-)
[20:10] <gatox> eod here! see you tomorrow people!
[20:15] <briancurtin> alecu: is https://code.launchpad.net/~brian.curtin/ubuntuone-dev-tools/py3-io/+merge/120478 more what you were looking for?
[20:28] <alecu> briancurtin: right!
[20:32] <alecu> briancurtin: +1
[20:32]  * alecu loves test suites that run fast
[20:52] <mandel> ralsina, alecu, mmcc FYI  I'm back :)
[20:53]  * mandel ran too much and throw up
[20:53] <briancurtin> that's how you know it works
[21:10] <mandel> briancurtin, do you see anything obviously wrong here: paste.ubuntu.com/1159755
[21:10] <briancurtin> mandel: looking
[21:11] <mandel> briancurtin, thx
[21:11] <mmcc> mandel, double * latency = 0.01 is initializing a pointer with a double
[21:12] <mmcc> doesn't that give compile warnings?
[21:13] <mandel> mmcc, he, stupid me, but I just fixed it and I still get schedule gets at most 1 argument (4 given)
[21:13] <briancurtin> mandel: you only supplied one kwarg in the kwlist - you need to add thread, stream, callback, paths as well. the "|s" just makes latency optional but you still need the first four in the kwlist
[21:13] <briancurtin> mandel: your kwlist should be {"thread", "stream", "callback", "paths", "latency", NULL} (or whatever names you want to use)
[21:14] <mandel> briancurtin, awesome, it makes perfect sense.. stupid me
[21:15] <mandel> briancurtin, and that fixed it!
[21:15] <briancurtin> cool
[21:20] <mandel> mmcc, the macfsevents tests are really ugly, the use time.sleep everywhere..
[21:22] <mmcc> mandel, yep
[21:26] <mandel> mmcc, I'm not going to patch all their tests.. I'll do something around it to add tests to the new latency parameter
[21:26] <mmcc> mandel, what do you mean by "something around it"?
[21:27] <mandel> mmcc, let me do a pastebin
[21:30] <mandel> mmcc, this: http://paste.ubuntu.com/1159785/
[21:32] <mmcc> mandel: ok, I get what you meant, thanks. I don't totally follow the second snippet but I don't think I need to yet
[21:33] <mandel> mmcc, I'll send you the code for a review before it goes upstream, but we will need to change the latency in or code to 0 since the default is the one they used, 0.01
[21:33] <mmcc> mandel: ok.
[21:33] <alecu> briancurtin: in py3-unicode-literals, I think that txwebserver.py is missing the "from __future__ import unicode_literals" line.
[21:34] <mmcc> mandel: FWIW, I don't think we'll need latency=0 with the new code - since it checks for multiple event flags in one event now
[21:34] <mandel> mmcc, well, since we have it we can easily test the diff rather than having to compile it all the time :)
[21:35] <mmcc> mandel: yep, good stuff
[21:35] <ralsina> briancurtin, mmcc, mandel: I will do reviews late tonight, feel free to mention them here, I'll see them
[21:36] <briancurtin> alecu: argh, i thought i put that back in. had it before, reverted something, lost it...now it's back in
[21:37] <mandel> ralsina, ok, I'll probably will send a github url via email with the upstream changes we would like to have and will add some tests to our client
[21:37] <mandel> ralsina, yes you still own me the review where I removed the SBJson code form the project :)
[21:37] <ralsina> mandel: will do it!
[21:39] <alecu> briancurtin: approved now
[21:41] <alecu> hey, all, can I get one more review on this? https://code.launchpad.net/~alecu/ubuntu-sso-client/fix-ssl-unicode/+merge/120013
[21:41] <briancurtin> alecu: will look in 1'
[21:50] <briancurtin> alecu: approved
[22:29] <mmcc> alecu, mandel - anyone with a mac around for a quick test? I want to share a folder containing a .app with you and have you try to run the .app.
[22:29] <chaselivingston> mmcc: I've got a mac, if that helps
[22:30] <mmcc> chaselivingston: sure, why not :) you need a u1 client, so give me a second to upload the one I just built that works better with uploads
[22:31] <chaselivingston> haha ok
[22:34] <mandel> mmcc, I'm here :)
[22:34] <mandel> mmcc, share it and will be tested
[22:35] <mmcc> ok mandel, I've shared it.
[22:35] <mmcc> it's just a copy of TextEdit. just see if it runs when you double-click it… (I expect it not to, but I'm not sure what errors to expect)
[22:35] <mandel> mmcc, ok
[22:36] <mmcc> chaselivingston: I guess never mind - since my upload of the new build… isn't uploading :|
[22:37] <chaselivingston> mmcc: no worries, would love to try it out when I can though!
[22:37]  * mmcc goes off to double-check paths and versions
[22:37] <mmcc> thanks chaselivingston, sooooon!
[22:44] <mandel> mmcc, can you zip the app, else it is a dir and the web interface does not work very well to download it
[22:45] <mmcc> mandel: right, that's why you need the client… accept the share in the client. it's important that I don't zip the app - that'll preserve the internal symlinks
[22:45] <mandel> ok
[22:45] <mmcc> if it's a pain, it's not critical right now. just thought it'd be a quick test
[22:46] <mandel> mmcc, is not a pain, but I have a problem the UI has a major bug where the check box to accept the share does not scroll with the rest, do we have sdtool in the bundle?
[22:48] <mmcc> mandel: we don't have sdtool in the bundle but it runs fine from source with the right pythonpath.
[22:49] <mmcc> mandel: but that's already too much work. let's shelve this until later
[22:49] <mandel> mmcc, as you please, I can do that in my morning :)
[22:49] <mandel> mmcc, or even take a look at the bug, it must be simple to fix
[22:49] <mmcc> mandel which bug?
[22:50] <mmcc> oh the UI bug
[22:50] <mmcc> sure
[22:50] <mandel> mmcc, yes, the UI bug
[22:50] <mmcc> right now I'm concerned that copying a big .zip into my u1 folder did not seem to generate the right events to trigger an upload…
[22:51] <mmcc> it looks like the same bug I had before, with a create and no matching modify, but I'm using the new code…?!
[22:51] <mandel> mmcc, anyway, I just managed to merger your work with gatox and upstream, there are some failing bugs but is not dramatic, most of the work went on changing the code so that if other users dont change the code the behaviour is the same (mainly for gatox work)
[22:51] <mandel> mmcc, is that with the changes you added?
[22:51] <mandel> dammed..
[22:52] <mmcc> mandel: yes, unless I'm doing the packaging wrong. I'm running the test script now to see what's up
[22:52] <mandel> mmcc, how is the blessing work going, the deadline is a hard one so we should deliver something that works..
[22:53] <mmcc> hm, I checked and the .pyc inside the site-packages.zip in the packaged app has my new debug strings in it. ugh.
[22:54] <mmcc> mandel, I have a ctypes version of the SMJobBless sample almost working now. todo is to code sign the sample, make sure that works then move that code into u1-cp and codesign u1-cp and the fsevents daemon.
[22:55] <mmcc> the problem is that it doesn't give useful errors when the code signing is wrong, so it's going to be annoying to make sure it works - because code signing python .apps is not documented
[22:55] <mandel> mmcc, fuuu we are always fighting against the world..
[22:56] <mmcc> that's one reason why I stayed up last night working on the fsevents.py stuff, I wanted to have that working in case the code signing was difficutly
[22:56] <mmcc> er, difficult
[22:56] <mandel> mmcc, is been two years and we always have had problems like this outside ubuntu, well, we will just get wisher
[22:56] <mandel> mmcc, ok, I'll work hard on the fsevents then as a back up of the back up he
[22:57] <mmcc> ok mandel. I'm going to do a quick test to see what's up with copying in a 35MB .zip - why my changes didn't catch that - and then go back to code signing
[22:58] <mandel> mmcc, ok, let me know what you find, I'm running the fsevents tests with all the changes and seeing funny things lie PyCObject_AsVoidPtr called with null pointer.. I'll see what is going on
[22:59] <mmcc> mandel: ok. good luck :)
[22:59] <mandel> mmcc, very appropriate thing to say at 1 am hehehe
[23:00] <mandel> mmcc, we are also getting deletes with no delete or rename flag.. bummer
[23:01] <mmcc> mandel, that's the "HUH" string I put in?
[23:01] <mandel> mmcc, yep
[23:02] <mmcc> there's a chance that's not actually an error. I put that in because I expected there to be either a remove(aka delete) or rename flag, but there might be another reason… should probably be some more info printed in that case to figure it out
[23:02] <mandel> mmcc, I'll put my money is some stupid attr changed
[23:03] <mmcc> mandel, don't put too much money - I think that message only happens if there's a file in the snapshot that isn't in the observed set. attr changes shouldn't do that
[23:04] <mandel> mmcc, hm.. I really prefer the daemon way of doing things, at least I fully understand how it works
[23:05] <mmcc> we should probably copy that raw_events dict in my debug script into the main script to let us print the flags as text there…
[23:05] <mandel> mmcc, I would say even add logging to the lib, there is no single way to see what is going on
[23:06] <mmcc> mandel: couldn't hurt. it'd certainly be nice
[23:06] <mandel> mmcc, how can it be that I'm getting 3 events when a file is created, create, modify and None? that looks funny
[23:07] <mmcc> mandel: sounds funny too. is there something you can paste?
[23:07] <mmcc> remember there's always garbage events from .DS_Store…
[23:08] <mandel> mmcc, found the issue, I did something stupid in the merge
[23:08] <mmcc> mandel: ah, that's good
[23:08] <mandel> mmcc, at least one more green test..
[23:12] <mandel> mmcc, im a few sec away, I need to get a drink, this weather is crazy is 87 F at 1 in the morning..
[23:15] <mmcc> mandel: that's awful.
[23:15]  * mandel back
[23:16] <mandel> mmcc, is just crazy.. and I was running at 96 which explains why I nearly collapsed
[23:17] <mmcc> yeah, got to be careful about that…
[23:33] <mmcc> mandel: on my .zip experiment I am missing a modify event. I also got an instance of 'create detected but event not marked as create', which was surprising. it looks like there are some cases where a file being copied by the finder is reported as a rename instead of a create/modify...
[23:33] <mmcc> (in which case, we might need to check the flags for rename if we detect a create from the snapshot, and issue an upstream modify then too)
[23:34] <mandel> mmcc, should we do a create, modify and rename? or just create and rename?
[23:35] <mmcc> mandel: not sure… first I need to reproduce this :\
[23:37] <mandel> mmcc, this fsevents lib is starting to be a little disappointing
[23:41] <mmcc> mandel, agreed.
[23:47] <mmcc> mandel, my "HUH delete detected with no delete or rename flag" message is brain damaged - it's printed when the removed flag is not set *and* the renamed flag is set. it should test if they're both not set, which should not happen
[23:47] <mmcc> I plead early AM hacking
[23:49] <mandel> mmcc, ok, so is not a huge problem, I'll fix that in my version
[23:50] <mmcc> also, I've reproduced my .zip dragging issue. another thinko on my part, if you *move* a file in the finder into the watched dir, you get a single rename event. just rename, no create or modify.
[23:50] <mmcc> if you *copy* a file into the watched folder you get create+modify - either two events or one coalesced event
[23:50] <mmcc> this all makes perfect sense :)
[23:51] <mandel> mmcc, believe it or not it does, because the same happens on windows but you get amoved_to with out a moved_from or a mmoved_from without a moved_to :(
[23:52] <mandel> mmcc, I'll jot this down so when you get a rename event and is not in the snap we get a create + modify
[23:52] <mmcc> mandel: I'm testing a fix now, it's going to be short. are you using bzr for this or just re-doing the changes in a git repo for upstream?
[23:53] <mandel> mmcc, I'm using git because we where outdated, but use bzr and i'll use patch to get them, is not a problem
[23:54] <mmcc> mandel: ok will do
[23:54] <mandel> mmcc, also, if we can push all this to upstream better, I don't want to maintain yet another lib
[23:54] <mmcc> mandel: agreed.
[23:55] <mmcc> although I don't think it's all that actively used. we might be the de facto maintainers even if upstream is taking our patches
[23:55] <mandel> mmcc, it was updated 2 months ago.. or so it says one file in github..
[23:56] <mandel> mmcc, but yest, I fear the worst.. tests have not been changed for about 3 years
[23:56] <mmcc> mandel: yeah, I looked at the github commits, there's one guy who committed a couple minor changes, including one that copies the > instead of != bug from mtime into a check for atime
[23:57] <mmcc> considering how noticeable these bugs should've been, that leads me to believe that people are only using this for hobby projects or something
[23:58] <mandel> mmcc, yes, it does smell a lot
[23:58] <mandel> mmcc, I think I did fix that != is that with the IN_ATTRIB event?


[07:37] <MAASSIVE> hello all
[07:37] <MAASSIVE> rvba thanks alot
[07:37] <MAASSIVE> it worked
[07:38] <MAASSIVE> I just had to assign which distro
[07:38] <MAASSIVE> and worked fine
[07:38] <MAASSIVE> now Im getting this error with juju
[07:39] <MAASSIVE> http://paste.ubuntu.com/6560024/plain/
[07:45] <jtv> MAASSIVE: empty environment name?  That doesn't sound right.  Do you have your juju environment configured on the machine you're doing that on?
[08:06] <MAASSIVE> yes I didn configure it
[08:06] <MAASSIVE> but one thing I noticed
[08:06] <MAASSIVE> I ran juju bootstrap
[08:06] <MAASSIVE> then it got interrupted
[08:07] <MAASSIVE> tried again
[08:07] <MAASSIVE> I started getting this error
[08:08] <MAASSIVE> I tried juju destoy-environment
[08:09] <rvba> jtv: could you please have a look at https://bugs.launchpad.net/maas-test/+bug/1259972
[08:09] <rvba> ?
[08:10] <MAASSIVE> I got this http://paste.ubuntu.com/6560108/plain/
[08:11] <MAASSIVE> also just to note that I installed juju
[08:11] <MAASSIVE> then added juju-core
[08:11] <MAASSIVE> and removed juju
[08:11] <MAASSIVE> kept juju-core
[08:11] <jtv> MAASSIVE: I think the "conflict" error means that Juju tries to deallocate a machine when it's in a state where that makes no sense...  I think there's a known bug about that.
[08:12] <rvba> MAASSIVE: can you give us the version of maas and juju?  (apt-cache policy maas / apt-cache policy juju-core)
[08:12] <jtv> rvba: that bug looks pretty easy (provided all you want is a better error).
[08:13] <rvba> jtv: well, not really a better error.  The check must not fail in this case… and it does.
[08:13] <jtv> Why?  The interface must have an IP address for the tests to work.
[08:15] <rvba> Well, the check is about detecting DHCP servers on the network.  In my case, the NIC is connected to a completely unconfigured network.  And the interface connected has no IP yet.  So I'd expect the check to let maas-test run instead of blowing up in my face.
[08:16] <MAASSIVE> http://paste.ubuntu.com/6560133/plain/
[08:16] <jtv> rvba: it's a bit awkward if we can't do the DHCP check at all, but we could log a warning about it...
[08:17] <MAASSIVE> that was output for apt-cache policy maas / apt-cache policy juju-core  / apt-cache policy juju
[08:17] <rvba> jtv: I think that would be better than blowing up.  Again, in my case, there is no DHCP server at all.  The check is just unable to perform the detection, which is fine, but this should not prevent me from running maas-test.
[08:18] <jtv> Then we can check for the result from get_interface_IP().
[08:21] <rvba> MAASSIVE: yeah, like jtv said, you're hitting some bugs that where present in the package released in precise.  As stated in the documentation (http://maas.ubuntu.com/docs/install.html), you should really use the cloud-archive:tools ppa on precise.
[08:21] <rvba> MAASSIVE: see the "Note" on that doc page.
[08:23] <MAASSIVE> ???
[08:23] <MAASSIVE> A more up-to-date MAAS is available for the most recent Ubuntu LTS release in the Canonical cloud archive. You can activate the archive with sudo add-apt-repository cloud-archive:tools. Using packages from this archive is recommended as it contains important fixes and new features that are not always available in the Ubuntu archive.
[08:24] <MAASSIVE> shall I just run sudo add-apt-repository cloud-archive:tools
[08:24] <rvba> MAASSIVE: yes
[08:24] <MAASSIVE> then re-install juju-core
[08:24] <rvba> And maas
[08:24] <MAASSIVE> ?
[08:26] <rvba> The ppa in question contains backported versions of maas and juju-core.  i.e. versions from later releases backported into precise.
[08:26] <MAASSIVE> what do u mean by and Maas?
[08:26] <rvba> So, you need to run the add-apt-repository, then 'sudo apt-get update' to refresh your local cache, then install juju-core and maas (and you should see them being downloaded from that ppa)
[08:27] <rvba> You need to reinstall maas as well.
[08:27] <rvba> Once the ppa is set up.
[08:27] <MAASSIVE> apt-get install maas ?
[08:27] <rvba> Yeah
[08:28] <rvba> MAASSIVE: http://paste.ubuntu.com/6560199/
[08:30] <MAASSIVE> juju-core didnt change
[08:30] <MAASSIVE> http://paste.ubuntu.com/6560202/plain/
[08:30] <MAASSIVE> output of the commands
[08:30] <MAASSIVE> shall I now bootstratp?
[08:35] <rvba> Yeah, it should be fine.
[08:35] <rvba> The ppa from which you installed juju-core contains a very up-to-date version of juju-core.
[08:35] <rvba> That's why it did not get upgraded.
[08:36] <MAASSIVE> shall i do $ juju bootstrap --upload-tools
[08:36] <MAASSIVE> or $ juju bootstrap
[08:39] <jtv> rvba: by the way, does your branch for creating zones include an edit form for zones?
[08:40] <rvba> jtv: let me check… (doing so many things in parallel I'm a bit confused right now)
[08:40] <jtv> Understandable.
[08:40] <rvba> jtv: http://paste.ubuntu.com/6560244/
[08:40] <jtv> I just didn't want to implement my own and then discover that we had massive conflicts.
[08:41] <rvba> jtv: your branch seems to be more advanced than mine (in fact, I just started working on it).
[08:41] <MAASSIVE> which command is the correct one
[08:41] <MAASSIVE> $ juju bootstrap
[08:41] <jtv> I guess that form you just posted would be enough if we change the foreign key?
[08:41] <rvba> jtv: yes
[08:41] <MAASSIVE> or $ juju bootstrap --upload-tools
[08:42] <rvba> MAASSIVE: this has been changed very recently so I'm not sure if the version of juju you're using requires '--upload-tools' or not… hang on.
[08:44] <rvba> MAASSIVE: you should be fine without '--upload-tools'.
[08:46] <rvba> MAASSIVE: the "uploading of the tools" step is not done with "juju --sync-tools".
[08:47] <rvba> s/not/now
[08:47] <rvba> oops :)
[08:47] <MAASSIVE> oops
[08:47] <MAASSIVE> ERROR environment is already bootstrapped
[08:48] <MAASSIVE> lbgmaas@lbgmaas1:~$ juju bootstrap ERROR environment is already bootstrapped
[08:48] <MAASSIVE> shall destroy
[08:48] <MAASSIVE> ???
[08:48] <rvba> Yes.
[08:49] <MAASSIVE> ERROR gomaasapi: got error back from server: 409 CONFLICT
[08:49] <MAASSIVE> after tryung to run destroy-env
[08:52] <rvba> Can you go to the MAAS UI and "release" the allocated node(s)?
[08:54] <MAASSIVE> oops here is the strange thing, I wen tot MAAS I fond two nodes being off
[08:54] <MAASSIVE> just powered them
[08:54] <rvba> After that, re-destroy the env (it should work this time).
[08:54] <MAASSIVE> dunno how they got powered off
[08:54] <rvba> In what state are your nodes?
[08:54] <MAASSIVE> shall I destoy or bootstrap  first
[08:56] <rvba> If the IPMI is configured correctly, you shouldn't have to power your nodes up or down manually. At all.
[08:56] <rvba> So, destroy first.  If it work, bootstrap.
[08:56] <rvba> works*
[09:18] <MAASSIVE> ooops
[09:18] <MAASSIVE> destroy give this
[09:18] <MAASSIVE> ERROR gomaasapi: got error back from server: 409 CONFLICT
[09:21] <MAASSIVE> this is strange
[09:21] <MAASSIVE> when I try to destroy I get the error : ERROR gomaasapi: got error back from server: 409 CONFLICT
[09:21] <MAASSIVE> and my nodes get powered off
[09:38] <MAASSIVE> ??
[09:39] <rvba> We need to know in what state your nodes are to help you.
[09:39] <MAASSIVE> here is a more strange one
[09:41] <MAASSIVE> one of my nodes keep on reverting to install mode
[09:41] <MAASSIVE> as if its the 1st time
[09:41] <MAASSIVE> this happened after I added the new repo
[10:00] <MAASSIVE> rvba: i think the update has messed maas
[10:00] <MAASSIVE> everytime I try to power on a node it reverts to the install mode
[10:01] <MAASSIVE> as if its doing it fresh
[10:01] <MAASSIVE> any clue why this behaviour?
[10:01] <MAASSIVE> when destroying the juju, one node gets powered off
[10:01] <MAASSIVE> ERROR gomaasapi: got error back from server: 409 CONFLICT
[10:02] <MAASSIVE> do you recommend that I start from scratch?
[10:02] <rvba> MAASSIVE: can you tell me in what state the nodes are when you run the juju destroy-env command?
[10:03] <MAASSIVE> one of them goes to ready
[10:03] <MAASSIVE> it was allocated to root then goto ready
[10:05] <MAASSIVE> so it reverts to ready.
[10:05] <MAASSIVE> is this normal?
[10:05] <rvba> So all the nodes are ready when you run the command?
[10:05] <MAASSIVE> yes
[10:05] <MAASSIVE> but I get ERROR gomaasapi: got error back from server: 409 CONFLICT
[10:06] <rvba> This is really weird, if all your nodes are ready, you shouldn't get that.
[10:06] <rvba> MAASSIVE: I'm sorry, I'll have to recommend that you delete all the nodes from MAAS and re-enlist/re-commission them.
[10:07] <jamespage> allenap, is the task for pymongo on bug 1237615 still valid?
[10:09]  * allenap looks
[10:10] <allenap> jamespage: Are you wondering if it’s been fixed in saucy by a recent upload?
[10:11] <jamespage> allenap, I was trying to figure out whether it was a configuration issue or an actual bug
[10:13] <allenap> jamespage: I’m not actually sure which side of the fence this falls on. I’m inclined to say that the pymongo task can be marked invalid.
[10:13] <jamespage> allenap, done
[10:13] <jamespage> thanks
[10:13] <allenap> jamespage: Cool :)
[10:19] <allenap> MAASSIVE: By any chance did you allocate the nodes to yourself in MAAS before using Juju?
[13:29] <MAASSIVE> rvba: I did delete all nodes and added one node now
[13:29] <MAASSIVE> still same issue
[13:30] <MAASSIVE> allenap: pls explain more on allocating to myself
[13:44] <ticking> hey is there a workaround of the maas-import-pxe-files bug?
[13:45] <ticking> I have the latest maas on a 13.10
[14:47] <ticking> how comes that the latest version is basically unusable out of the box without manual fixes? Does everybody use 12.x or is the userbase so small?
[15:17] <MAASSIVE> Hi there
[15:17] <MAASSIVE> sorry if I missed something
[15:22] <stokachu> any know if bug 1238390 will be addressed by 14.04?
[15:23] <stokachu> i think its purely cosmetic
[21:47] <lazypower> So, correct me if i'm wrong, but you can use MAAS to provision LXC containers on a single server?


[03:45] <xavpaice> hey there, is there a way to get logs for the openstack API calls the controller is making during `juju add-machine --constraints "instance-type=kubernetes-xxlarge zones=k8s-rack3"` ?
[03:45] <xavpaice> I need to know what it's requesting, and which openstack user it's using to confirm we have the quotas right
[05:01] <xavpaice> I tried increasing the logging to DEBUG, but so far it just tells me that "ERROR juju.worker.provisioner provisioner_task.go:985 cannot start instance for machine "41": suitable availability zone for machine 41 not found".  There's two machines each for k8s-rack1 and k8s-rack2, but only one for k8s-rack3, and we already have machines on that AZ.  Is that the issue?  Capacity is fine, but maybe some anti-affinity thing going on?
[08:14] <Hybrid512> o/
[10:39] <gnuoy> stickupkid, thanks for you help with getting the spaces patches landed.
[10:40] <stickupkid> gnuoy, more than happy to, anytime!
[16:49] <teldredge> Does Juju select a MaaS machine entirely at random or is there a way to have it choose a machine closests to its CPU\RAM\HDD constraints?
[16:50] <stickupkid> teldredge, https://juju.is/docs/constraints
[16:53] <teldredge> I understand it must choose a machine that satisfies the minimum constraints. I'm wondering if it's random from there. If the constraint is 4GB and it has an 8 and a 16 available- does it choose at random or select the 8 for being closer?
[17:28] <stickupkid> teldredge, It's what ever maas gives us back and we use that order, so I would say first one that meets the constraints
[17:28] <stickupkid> teldredge, if you want the 16GB one, then selecting anything higher than 8 will do the job
[17:32] <teldredge> Gotcha, I was hoping it would choose the closest match. I'm using Proxmox so I have a bunch of VMs MaaS can grab when it needs them so I was hoping to make it use the least resources needed, but I probably just need to use tags.
[18:30] <teldredge> Curious if anyone has seen any projects deploying kubevirt with juju
[20:45] <teldredge> If I bootstrap a juju-controller and use it to deploy a kubernetes cluster, do I have to deploy another juju-controller running in the cluster?
[20:45] <teldredge> Or can I use the original juju-controller to control the Maas 'cloud' and the k8s cluster?
[21:09] <thumper> you should be able to do the later
[21:09] <thumper> adding the k8s cluster to the controller