=== CyberJacob|Away is now known as CyberJacob === CyberJacob is now known as CyberJacob|Away [12:31] jtv: I got an unrelated failure in my branch. Does http://paste.ubuntu.com/8079607/ ring any bells for you? [12:31] allenap: yes, I think I know what that is. [12:31] factory.make_node() randomises the node's disable_ipv4 setting. [12:32] So for a test that requires the node to report IPv4 addresses in its ip_addresses property, or in DNS, pass disable_ipv4=False. [12:35] allenap: that particular failure may already be fixed in trunk actually. [12:38] jtv: Okay, I’ll just try landing again :) [12:38] Thanks. [12:39] You can try merging trunk and running that one test. Trick to save time: state the same test multiple times on the same command line. [12:39] Only have to do the costly schema setup once, but you get quick statistics on an unreliable test. [13:44] rvba: qa fix [13:44] rvba: https://code.launchpad.net/~blake-rouse/maas/qa-disable-i386/+merge/231194 === lazyPower_ is now known as lazyPower === beisner- is now known as beisner [15:32] Hi blake_r, thanks for the branch, I just reviewed it/ [15:33] rvba: thanks [15:33] rvba: will it work with just trusty? [15:33] rvba: or should I import precise? [15:33] blake_r: well, I really think we should be using trusty from now on. [15:34] rvba: okay [15:34] rvba: I will update it to trusty then [15:34] blake_r: cool. Then we need to make sure it works ;) [15:34] rvba: yeah, :) [15:36] rvba: is there a way to merge it so it gets the author and reviewer in the commit message, or do I need to do that manually? [15:37] blake_r: you need to do it manually [15:37] rvba: okay [15:38] blake_r: the trouble with breaking the CI for that long is that we landed a bunch of branches since your change… so if the CI breaks when you land you CI branch, it's going to be painful to see if the problem still is in the CI code or if we introduced a regression in MAAS itself. [15:38] your* CI branch [15:38] rvba: yeah sorry about that, i guess we will see! [15:39] blake_r: that's fine, but just make sure you're subscribed to the CI ML; the ML is a bit verbose but this way you'll be warned when the CI breaks. [15:40] rvba: yeah I am, it just fails on and off all the time, its hard to know when to check it [15:40] rvba: okay its merged [15:40] rvba: we will see [15:41] blake_r: unfortunately, I have the "feeling" it will break at the 'juju bootstrap' stage :). [15:43] blake_r: latest failure: http://d-jenkins.ubuntu-ci:8080/view/MAAS/job/utopic-adt-maas-manual/118/console (missing trusty image!) http://people.canonical.com/~rvb/missing_image.png [15:46] blake_r: btw, you can get the name of the latest LTS in a programmatic fashion: import distro_info; distro_info.UbuntuDistroInfo().lts() [15:47] blake_r: much better than hardcoding release names :) [15:47] rvba: yeah thats true [15:47] rvba: that error is because its missing the report boot image [15:48] rvba: i hate that error [15:48] rvba: so terrible [15:48] rvba: idk how it could of said they were reported then [15:48] blake_r: what do mean its missing the report boot image? [15:49] rvba: means that the report_boot_images did not run, yet... [15:49] blake_r: did you change how this works? Because the reporting happens right after the import. [15:50] blake_r: and the CI script waits for the images to be reported before it enlists the nodes. [15:50] rvba: no i didnt [15:50] So it doesn't make sense to me. [15:50] rvba: thats what is wierd [15:51] rvba: yeah doesn't make since, the image should be reported if the api said it was there [15:51] Exactly. [15:52] blake_r: I'm guessing you'll get rid of the old boot image list in the UI right? [15:52] rvba: yes [15:53] blake_r: there is a run in progress, looks like the images are import all right: http://10.98.3.59/MAAS/clusters/c2750ad3-717d-4b4c-965c-134b787bea92/bootimages/ [15:53] blake_r: I think this run started without the changes you just landed… I'll kill it. [15:54] Done, another run is in progress now. [16:35] blake_r: looks like the reporting of the images is broken; the current run has been checking the images for ~10 minutes now… [16:37] these fancy new names are pretty sweet [16:37] node names [16:41] blake_r: run failed: http://d-jenkins.ubuntu-ci:8080/view/MAAS/job/utopic-adt-maas/429/console [16:43] rvba: okay will have a looj [16:44] blake_r: it's https://bugs.launchpad.net/maas/+bug/1349891 [16:44] Ubuntu bug 1349891 in MAAS "celery tasks fail with a HTTP Error 504: Gateway Time-out" [Undecided,New] [16:44] Nothing to do with your changes. [16:44] blake_r: that's the spurious failure that's been plaguing us for quite some time now. [16:45] rvba: dang celery! [16:45] I like to eat celery [16:45] preferably with peanut butter [16:45] well eat all of Maas celery and get ride of it! [16:46] blake_r: Celery is not responsible for this. [16:46] blake_r: i have some ipmi nodes managed by a top of trunk maas; power status is always yellow on them; is that a bug right now? [16:46] blake_r: btw, did we get a definitive answer from the designers about the colors? [16:48] rvba: I think it was said to leave it for now, we will work on ui next cycle [16:48] at least that is what roaksoax told ne [16:49] blake_r: we should at least change the color for when a node is off. red seems to indicate a problem/failure. [16:49] jhobbs: ipmi I believe is queryable [16:49] so it's a bug i guess [16:49] i thought maybe it wasn't all enabled [16:49] rvba: not to me! ;) [16:50] jhobbs: ipmi and amt should be [16:50] ok [16:50] rvba: but if others agree then we can change it [16:50] i agree [16:50] rvba: red to me means off [16:50] many people have commented on the red [16:51] and how it should mean error [16:51] black is a good off color imo :) [16:51] jhobbs: I was about to say the same :) [16:51] disagree! :) but should display the same meaning [16:57] acquire/start/stop in the GUI now is also cool [16:57] although it seems stop=release [16:58] that seems a little strange! [17:02] also does start actually mean = install? [17:02] jhobbs: blake_r https://code.launchpad.net/~rvb/maas/fix-power-color/+merge/231231 [17:03] rvba: i think the title should just be === roadmr is now known as roadmr_afk [17:03] rvba: title="node.power_state.capitalize [17:03] does the title get displayed as a tip when you hover? [17:03] jhobbs: yes [17:04] rvba: i don't think it needs "Power state:"? [17:04] yeah seems redundant to me too [17:05] Hum, on/off are pretty clear indeed. But 'unknown' is not. [17:05] rvba: looks like the latest test is now configuring juju [17:06] rvba: unknown should really be there once all of the power types support query [17:06] rvba: shouldnt* [17:06] it will be there whenever the node can't be contacted right? [17:06] or will that show Error [17:06] jhobbs: error [17:06] jhobbs: etrror [17:07] blake_r: okay, fair enough, I'll remove the 'power state' prefix. [17:14] rvba: juju bootstrap worked [17:15] blake_r: so far so good [17:28] blake_r: # juju deploy mediawiki [17:28] ERROR charm not found: cs:trusty/mediawiki [17:28] uh-oh [17:30] rvba: uhm, pretty sure that exists [17:32] blake_r: it's not in the list: https://manage.jujucharms.com/charms/trusty [17:34] rvba: wow [17:34] blake_r: we can still deploy the precise-based charm (on Trusty). [17:35] blake_r: arg, no, this would force the machine to use precise. [17:48] rvba: couldnt we just deploy juju-gui, check that 80 is open? [17:48] rvba: or postgres [17:48] blake_r: I think we should just deploy mysql and only continue with deploying mediawiki on top if we're using precise. [17:49] blake_r: i.e. https://code.launchpad.net/~rvb/maas/qa-lab-tests-trusty/+merge/231236 [17:52] blake_r: but yeah, we could check that the port 3306 is open. [17:52] rvba: i think we should deploy keystone [17:52] rvba: it only requires mysql [17:52] rvba: openstack identity service [17:54] blake_r: now that Juju itself has a nice CI, we probably don't need to test the relations. Only that a Juju service comes up. === roadmr_afk is now known as roadmr [17:55] rvba: i guess if maas networking is being tested by just using juju then yeah probably not [17:55] rvba: keystone is small, just an idea to test some more [17:56] blake_r: yeah, but I really think bootstrapping and deploying a service is enough now. [17:56] rvba: okay [18:01] blake_r: I updated my branch to remove the mediawiki stuff (instead of disabling it). [18:02] blake_r: testing it now on utopic-adt-maas-manual [18:03] rvba: okay watching it now === CyberJacob|Away is now known as CyberJacob [18:56] blake_r: I just landed my CI branch. The CI should be back online with the next run. [18:58] rvba: perfect [19:03] blake_r: I'm open to a better solution (w.r.t. https://code.launchpad.net/~rvb/maas/fix-data-schema-migration/+merge/231244) [19:03] blake_r: you know that code better than I do ;) [19:03] rvba: yeah I will take it [19:03] rvba: i will stop putting data migration into schema, that just doesnt work ti seems [19:03] blake_r: it's clearly a recipe for disaster [19:04] blake_r: but like I said on the MP, adding a migration now won't really help, you'll have the data migration as 101 and the schema migration as 105 [19:04] blake_r: so it's the same as what I wanted to do. [19:04] blake_r: maybe just a tad cleaner [19:04] Since we won't be bundling two different things inside one migration. [19:04] yeah its the same result, just cleaner [19:05] blake_r: also, if you make 101 a pure data migration, you'll have to regenerate all the migrations after that. [19:05] :/ [19:05] ugh, thats true [19:06] yeah what if we had a data migration as 100 [19:06] two 100 [19:06] which is fine to south [19:07] Can we still control the ordering? [19:07] I mean, we need the data migration to be run before the schema migration. [19:07] that would be before [19:07] 100 the schema is 101 [19:07] it can run in any order of removing cluster from the the model [19:08] Right, instead of moving the data migration inside an existing one, you create a new one. [19:08] yeah, same result as yours but cleaner so the file has correct name [19:09] This shouldn't modify the chain of migrations since this is a data migration — this should work. [19:09] Sounds good to me. It's only marginally better than my solution but it's probably worth it. [19:09] Okay. [19:23] blake_r: btw, your changes to the API (revision 2206) broke the backward-compatibility of the API. Considering the changes that you're making, there is probably no way around it (although we could have kept the extract UUID parameter and ignored it). My point is that we need to be careful with these backward-incompatible changes and keep track of them very carefully: they need to be listed in the release [19:23] notes. [19:23] roaksoax_: ^ [19:23] rvba: yeah didn't think there was away around it [19:24] rvba: i guess I could add that back in and support both [19:26] blake_r: maybe you could still accept the UUID param and ignore it. Wouldn't that be enough? [19:26] rvba: yeah but would be very wierd [19:27] rvba: if we have both, then we have the new way without breaking the old [19:27] blake_r: yeah, that would probably be better. [19:32] blake_r: juju bootstrapping on liquid-meal.maas :) [19:39] rvba: https://code.launchpad.net/~blake-rouse/maas/fix-101-migration/+merge/231249 [19:40] rvba: cool, watching the test now [19:40] what are the changes made? === roaksoax_ is now known as roaksoax [19:41] roaksoax: its a new migration file 100 [19:41] roaksoax: and removal of the data migration in 101 [19:41] blake_r: ok [19:41] blake_r: cool, approved. [19:42] blake_r: land it.. i need this asap :) [19:42] roaksoax: its landing now [19:42] blake_r: aweosme! [19:55] roaksoax: its merged [19:55] roaksoax: ci test passed! [19:55] rvba: ^ [19:55] awesome! === ming is now known as Guest23909