[00:03] stokachu, still there [00:03] ? [00:03] http://paste.ubuntu.com/6211669/ [00:05] so that "works for me". and I tested by following doc/devel/README.txt [00:05] and my 'launch' command [00:05] ./tools/launch $BOOTIMG --publish $ROOTTGZ --add config -- curtin -v install --config config/my-network.conf "PUBURL/${ROOTTGZ##*/}" === CyberJacob is now known as CyberJacob|Away [02:09] bigjools: if you can review the moonshot stuff would be greatlt appreciated [02:09] roaksoax: I am overloaded with stuff at the moment, I will ask jtv to look [02:10] What needs reviewing? [02:10] thanks [02:10] lp:~andreserl/maas/moonshot_enablement [02:10] OK [02:10] jtv btw is maas-import-ephemerals done? [02:14] Just about. We need to back up the old pserv.yaml before overwriting it, the "arches" setting needs to be in a place where it can be shared between the import scripts, and some settings can do with clearer names. But that's all easy stuff. [02:14] With those changes in place, we can land the switchover branch that is already pending. [02:15] awesome [02:15] jtv: thanks for the hardwork [02:16] All in a good cause! [02:16] Oh, I see Raphaël has the back-up-pserv.yaml branch up for review already. [02:16] Excuse me while I do reviews... [02:18] Argh. Nope. That looks buggy. OK, so back to plan A. :) [02:19] Nope, nope, it works. Go Raphers! [02:22] roaksoax: that mechanism for including scripts in the userdata is really paying off, isn't it? [02:22] jtv: yeah i love it... [02:22] wanna put maas_enlist there when i rewrote it to pythin [02:23] can we bring maas-signal back there too? [02:25] bigjools: xan you subscribe maas-maintainers to djorm-ext-pgarray .. kinda critical [02:25] bigjools: and maas signal has always been in maas the reason why we ship itnwith maas-enlist is for end user usage on remote nodes [02:26] yes I was getting mixed up [02:27] roaksoax: what do you need the subscription for? [02:27] bigjools: it is already.. to be able to promote the package to main [02:27] it needs bug subscriber [02:28] roaksoax: I don't understand what you want [02:29] bigjools: nevermind it is done already [02:30] bigjools: but add maas-maintainers as a subscriber for launchpad.net/ubuntu/+source/curtin [02:30] roaksoax: bug subscriber you mean? [02:31] I will not add teams as subscribers to things as that's pretty obnoxious, people should subscribe themselves [02:32] * jtv comes up from email, gasps for breath, goes under again [02:37] bigjools: well maas-maintaoners maintain those packages [02:37] not just me [02:37] thats why it is subscribes [02:37] that's fine but team subscriptions suck [02:37] thats a maas dependenxy that *we* maintain [02:37] I subscribed myself, feel free to ask the red guys [02:37] as it is in ubuntu only for maas [02:40] now, which sprint track is maas in at SF ... [02:42] roaksoax: bigjools also wrote some script to detect whether the host is physical or virtual... He checked for qemu initially, but I think he found a more general way. [02:42] jtv: I didn't :) [02:42] Oh blast. Maybe it was allenap then. [02:42] there's a package called imvirt that we should use [02:43] jtv: well I wrote a commissioning script [02:43] but we need to generalise [02:43] Found it. roaksoax, have a look at src/metadataserver/models/commissioningscript.py and search for "notvirtual" [02:44] I see now that it does mention qemu... [02:44] Still, may be useful to compare, to see if we get consistent answers. [03:31] smoser: nice testing that now [03:38] stokachu, oh. in-target wont work in your version [03:38] :-( [03:38] but this should [03:40] http://paste.ubuntu.com/6212161/ [03:40] and i'm off to bed now. [03:47] smoser: thanks will test some more [04:59] interesting the web-ui doesn't update the nodes start/stop status if commissioning/starting nodes through maas-cli [05:00] and of course just after i type that it shows up [05:00] * stokachu is tired apparently === CyberJacob|Away is now known as CyberJacob [06:52] jtv: we need to fix the Makefile so "make doc" does not try to rebuild the database. Very annoying :/ [06:54] Urgent? [06:54] jtv: did you merge lp:~rvb/maas/backup-config ? [06:54] No... I assumed you had. [06:54] Because it's landed. [06:55] Weird, I didn't [06:55] jtv: is everything okay for me to land the branch that makes the switch to the new script? [06:55] Not _quite_. I need two simple reviews! [06:56] Okay, I'll review them now. [06:56] I really want us to do the switch so that I can do another round of testing. [06:57] Thanks. I'll be back by call time. [06:57] Yes, quite. [07:27] jtv: all reviewed, let's land! [07:29] rvba, jtv: apparently juju-core now supports maas-tags as constraints [07:50] jtv: should I land the switch now? [07:50] rvba: let me just check if my last branch landed — previous attempt failed because of the prerequisite. [07:51] k [07:51] Ah yes, that's landed. [07:51] So go ahead! [07:51] * rvba lands [08:14] bigjools, jtv, allenap: All of the migration-related branches have landed… and the branch that switches to the new script has landed as well… a package is being built in the daily ppa… test away! === freeflying_away is now known as freeflying [08:15] jtv: Thanks for looking at that PostgreSQL thing. I suspect we just take the hit first time around. [08:18] allenap: I don't know much about the situation, but it seems reasonable... Or maybe there's some heuristic that will get most of the rows you want to delete. [08:28] bigjools, allenap, jtv: the package is ready. fresh outta the oven. [08:28] Does it work? [08:28] rvba: What jtv said. [08:28] Well, we all need to test it! [08:30] And is this in the daily PPA? [08:30] jtv: yes === CyberJacob is now known as CyberJacob|Away [08:59] allenap: have you got a quick example of how to use the LLDP constraints? [09:00] bigjools: do you have time to have a look at: https://code.launchpad.net/~rvb/maas/fpi-button/+merge/190049 [09:00] sure [09:00] ? [09:00] Ta [09:01] rvba: s/curtin/fast installer/ on the buttons [09:02] bigjools: well, I thought you were okay with both… I choose curtin because it is shorter. [09:02] rvba: it's too jargon-y for the UI [09:02] bigjools: From Juju, no; Dan said he was going to talk to mramm about getting someone to sort that out on their side. [09:02] allenap: they said it was working I hear [09:02] bigjools: then we need to re-work the wordings entirely, otherwise it won't fit [09:02] bigjools: With regards to a tag, yes, I'll find something... [09:02] allenap: cheers [09:03] rvba: how many characters do we have? [09:03] bigjools: let's say that what we have now fits. [09:03] ok but new people are going to say "wtf is curtin?" [09:04] And we don't have much more space. [09:04] dude! [09:04] display = "Use the default installer" [09:04] is longer :) [09:04] bigjools: the critical piece is display_bulk. [09:05] display_bulk = "Mark the selected nodes as using the default installer" [09:05] s/default/fast/ in the other button [09:05] I'm testing that right now. [09:05] ok [09:05] bigjools: s/default/fast/ in the other button? [09:06] d-i is not fast :) [09:06] the UseCurtin one [09:06] you already have something *longer* for the d-i button [09:06] "Use the fast path installer" does not fit on the node's page. [09:07] s/path// then [09:07] "Use the default installer" fits [09:07] so two options: [09:07] "Use the fast installer" [09:07] and [09:07] "Use the default instaler" [09:07] ok? [09:07] Yeah, that's the best option. [09:07] great [09:07] Mark the selected nodes as using the fast installer/Mark the selected nodes as using the default installer [09:08] That fits. It's a bit tight but okay. [09:08] FWIW I got caught out the other week when I assumed should_use_fastpath_installer was a property :( [09:09] bigjools: //lldp:chassis/lldp:id[@type="mac"]/text() = "20:4e:7f:94:2e:10" [09:10] would select a machine that's connected to the router with that MAC. [09:10] * bigjools blinks [09:10] remind me which API field... [09:10] bigjools: Tag definition. [09:10] ok [09:11] bigjools: routers are a special case for acquire(); it now accepts connected_to and not_connected_to arguments, which are MACs. [09:11] Or multiple MACs. [09:12] allenap: nice [09:12] bigjools: rvba did that bit. [09:12] allenap: this sounds like it needs its own doc [09:12] too much for release notes [09:12] bigjools: Yep. [09:13] Ok when I land the release notes, someone can add a :ref: to the new doc [09:14] bigjools: I pushed the change to my fpi-button branch. [09:15] rvba: should I be concerned that the ordering changed in test_views_nodes.py? [09:16] oh you changed the code being tested. sorry [09:16] bigjools: the ordering? AFAIK I only changed the error messages. [09:16] yeah my bad [09:16] approved¬ [09:17] approved! [09:17] Ta [09:17] ¡Ta! [09:21] ¡Olé! [09:23] allenap: I'll rebuild the package soon, if you want to land your lldp to be part of the build you can do so now (unless you want to tweak the UI some more before landing). [09:25] https://code.launchpad.net/~julian-edwards/maas/release-notes-13.10/+merge/190061 [09:25] hello gmb [09:25] Hi bigjools. [09:26] bigjools: My account on Kanban appears to have been deactivated… I'm assuming that wash;'t you and am contacting their help desk, but just to check… ;) [09:26] rvba: I probably won't be ready in time. [09:26] gmb: oh didn't anyone tell you yet? [09:26] * bigjools joking [09:26] Laugh? Nearly shat. [09:27] allenap: can you check my release notes branch please? [09:27] bigjools: Sure. [09:27] gracias [09:27] or ¡gracias! [09:28] allenap: okay, no worries. We can build a package quickly with https://code.launchpad.net/~julian-edwards/+recipe/maas-daily-saucy so just build a package when you land you branch and then we'll test it. [09:28] your* branch [09:28] gmb: you're still marked as a board user for the maas board so that's all very odd [09:29] bigjools: Hmm… sounds like some kind of password / authentication snafu. ISTR this happening earlier this year to awd and domas on the green squad board, actually. [09:30] ¿yay? [09:33] bigjools: If there were a phrase to accurately confer "We are about the only corporate users of that particular half-maintained web app," then I would use that. ¿yay? will have to do. [09:34] I thought there were many users [09:34] anyway time to put kids to bed, back in a bit [10:16] rvba: the new ephemerals script doesn't care. [10:16] It'll just take releases that are in the stream, and optionally filter those. [10:17] While maas-import-pxe-files won't care anymore because it skips failing downloads. [10:18] jtv: okay, makes sense. [10:25] rvba: Do you think you'll have time to review https://code.launchpad.net/~allenap/maas/lldp-commissioning-results-in-ui/+merge/189663 again today? [10:26] allenap: sure… is it much different from the branch Jeroen reviewed? [10:27] rvba: Yes, it's almost all new. [10:28] allenap: okay, I'll have a look… could you provide a screenshot of the page? [10:30] jtv: allenap: could any of you take care of fixing ./etc/maas/import_pxe_files please? [10:31] rvba: by removing the RELEASES setting? [10:31] jtv: that or adding Saucy. [10:31] OK [10:32] Testing is going to be hard though. :( [10:32] I have a large instance, but it's not large enough. [10:32] You need to symblink to /mnt/ [10:32] symlink* [10:32] Plenty of space there right? [10:32] Oh, that worked for a "large"!? [10:32] Yeah. [10:33] Great. [10:34] Oh dear [10:34] I think our config conversion is broken... [10:35] :/ [10:35] Need a different way to get the variables. [10:36] allenap: I'm a bit confused by merge_details_cleanly/merge_details. Does the usage of merge_details_cleanly() mean the change in backward incompatible? [10:37] is* [10:39] rvba: http://people.canonical.com/~gavin/ui/lldp-commissioning-results-in-ui/ for screenshots. [10:39] Thanks. [10:40] rvba: merge_details_cleanly() generates the XML without using the lshw details as the document root (so that they're in there once without a namespace, and once in the 'lshw' namespace). [10:41] rvba: When tagging you get both, so that old expressions work. [10:41] rvba: But we want to encourage people to use only the namespaced XML from here on. [10:41] allenap: okay, thanks; makes sense. [10:58] rvba: Do you think I should add highlighting support to the XML? It's very easy with highlight.js, and looks good. [10:58] allenap: look like a nice addition, but probably not critical for today :) [10:58] allenap: I can use a little help with the testing ;) [10:58] rvba: Okeydoke :) [11:02] allenap: jtv seems to be busy with the migration stuff, if you could fix (and, most importantly test) ./etc/maas/import_pxe_files, that would be one thing off the list. [11:02] allenap, rvba — either of you willing to review a simple branch? https://code.launchpad.net/~jtv/maas/use-unexported-config-vars/+merge/190089 [11:03] Yeah, this is distracting me from the /etc/maas/import_pxe_files change I'm afraid. [11:03] I've got another thing to fix here. [11:03] jtv: I'll take it. [11:03] Merci beaucoup. [11:07] jtv: I have one small suggestion for the env branch, hang on... [11:07] * jtv hangs on [11:10] jtv: Done, on the mp itself. [11:10] OK [11:10] Thanks [11:16] rvba: Can I hit the build button again? [11:16] allenap: go! :) [11:17] allenap: I added the quoting, and will sleep better because of it. But not the "&&," because AFAICT the script never ran with "-e" in the first place. [11:18] jtv: Okay, cool. [11:18] * allenap wonders why bash scripts don't default to -eu ... [11:19] Because dried grapes are hilarious. [11:20] jtv: Que? [11:21] Wait... what was that other word for dried grapes? [11:21] jtv: raisins... reasons...? [11:21] And I don't mean hilarious... I mean that other word that's sometimes used instead. [11:22] jtv: depressing? [11:22] Normally means something like insane, loudly irrational... [11:22] Ah yes. Hysterical. [11:22] Raisins are hysterical. [11:23] * allenap goes to have lunch because that's normal. [11:23] In Unix shell tradition, bash is an interactive shell. You don't want it to exit on the first mistake. [11:23] Had it been developed purely as a batch shell, things might have been different... [11:23] dash is more like that. [11:24] In that it's not very accommodating to humans. [11:25] bash accommodates all human error. [11:25] Exactly. [11:25] Because it's meant to support interactive use. [11:25] Try running your terminals with "bash -e"... [11:26] Actually, that might be a good way to train novices. [11:26] Direct, merciless, effective. [11:26] Drop and give me 50! [11:29] roaksoax: we landed the branch that switches from the old script to the new script. Testing is in progress but it's looking okay so far… could you test upgrading the package from older versions? Something weird happened, I upgraded (using our daily ppa) from a package built one hour ago to a package built 10 minutes ago (the difference was only 2 revisions) and after the upgrade the 'maas-cluster-celery' [11:29] service was down. === teknico1 is now known as teknico [11:44] allenap, rvba: another small branch needs reviewing... If you'd be so kind: https://code.launchpad.net/~jtv/maas/load-immutable-config/+merge/190095 [11:44] This is the other fix for the config conversion. [11:54] roaksoax: is maas-cluster-controller really supposed to depend on maas-dhcp? [11:54] Isn't that a Recommends? [11:55] jtv: I'll review your branch [11:55] Thanks. [11:55] Having a bit of trouble with the latest packaging branch though: can't install maas-cluster-controller without also installing the DHCP server! [11:56] I think roaksoax told me they wanted to make maas-dns and maas-dhcp mandatory and not optional. [11:56] roaksoax will confirm this. [11:56] Isn't that going to wreak havoc on people just trying it out in small networks? [11:57] No really, if you don't configure an interface to be "managed" the dhcp server won't be started. [11:57] Not* really [11:57] Phew. [12:04] Thanks allenap & rvba for your reviews. With this landed, the config conversion works. [12:10] rvba: The package looks like it's used revno 1676, which is from yesterday. What am I missing? [12:10] 1.4+bzr1676+dfsg-0+1689+209~ppa0~ubuntu13.10.1 [12:11] "1.4+bzr1676+dfsg-0" comes from the packaging. [12:11] 1689 is the upstream revision used. [12:11] 209 is the packaging revision. [12:11] rvba: No one would believe me if I said packaging is arcane :) [12:12] allenap: look at the recipe: it uses a funky pattern to create the package name. [12:12] allenap: {debupstream}-0+{revno}+{revno:packaging}~ppa0 [12:12] rvba: And {debupstream} is where the weird bit comes from. [12:13] allenap: yeah, that comes from the packaging's first line of debian/changelog. [12:15] smoser: You're logged into the garage maas. Are you using it? [12:18] allenap, rvba: I'm done as of r1689. Unless there's anything urgent that either of you need help with. [12:18] smoser: filed bug 1237215 [12:18] bug 1237215 in curtin "late_commands in maas provision node fails" [Undecided,New] https://launchpad.net/bugs/1237215 [12:21] allenap, i have a node in use, why? [12:22] smoser: I want to test the latest daily package. [12:22] allenap, garage maas really isn't the place to do that. [12:22] jtv: Nope, I'm good :) [12:22] smoser: Why not? [12:23] because people expect for it to work. [12:23] jtv: I'm good too :). [12:23] cts people are expecting to be using that this week. [12:24] smoser: I thought the deal was: you put your name in the calendar, then it's yours, and you leave it in the state you found it (or working, if it wasn't). [12:24] smoser: My name's in the calendar :) [12:25] allenap, i don't really think "go crazy and put it back" is a sustainable plan on a shared resource. [12:25] smoser: What's it there for then? [12:27] use of maas. [12:27] not development of maas. [12:27] how will you put it back to the state which you got it ? [12:27] do you know the state that its in? [12:27] do the packages correctly downgrade? [12:28] how can you reasonably expect to "put it back the way you got it" [12:28] honest question. [12:29] allenap, you can use the QA lab to do this sort of testing. it's supposed to be used like that, you use and throw away, next person (or automated test) will re-build the whole thing anyway) [12:30] smoser: I've not used the garage MAAS in anger before, so I would expect someone to have documented this by now. I know I've seen it broken more times than I've seen it working, but that's perhaps because I get asked to look with it is broken. [12:30] s/with/when/ [12:30] you've seen it broken because of what i'm saying above. [12:31] so my solution is not to let people break it. [12:31] matsubara: I'm currently testing things in the lab, the idea was to parallelize the testing. [12:31] rvba, I see. ok then. I'll let you guys fight for the resource then :-) [12:31] i'm perfectly fine if we can come up with a "put it back into known state" button. [12:31] but we dont have that now [12:31] and others will expect to be able to use that shared resource. [12:32] i'd love a "redeploy garage maas" button. [12:32] Has the functionality in 1.2 to add archives for newly provisioned machines been dropped in Maas 1.4 ? [12:33] rvba, https://bugs.launchpad.net/curtin/+bug/1237215 [12:33] Ubuntu bug 1237215 in curtin "late_commands in maas provision node fails" [Undecided,New] [12:34] caribou_: boot images you mean? [12:34] hm.. [12:34] stokachu: nope, there is a button in the config section to add entries to the sources.list; it's no longer there in 1.4 [12:35] ah === caribou_ is now known as caribou [12:53] smoser: is the curtin installer supposed to work on ARM nodes? [12:53] no. [12:53] Okay. Thanks. [12:54] it has no way of setting up bootloading on arm nodes (unimplemented). [12:54] rbasak, could add that. [13:10] rvba: MAAS supports one Juju environment per *user*, is that right, not per API key? [13:11] allenap: that's how it's supposed to work indeed. But there is that bug we talked about recently in juju-core that makes the maas provider take down *all* the instances it can get his hands on when bootstrapping an env. [13:12] rvba: I'm thinking about the user preferences page, where it says "You'll need a separate MAAS key for each Juju environment". [13:13] rvba: That's not just misleading, that's wrong :-/ [13:13] allenap: it's both indeed. [13:13] rvba: I shall file a bug for it. [13:17] allenap, i think that the real blocker is if you're admin its a global space [13:18] regular users can be separated, but if an admin tries to use juju, he'll wipe out all nodes [13:19] hi all, know today is going to be tough but I was curious if anyone has tested juju-core, maas tag constraints yet? [13:19] smoser: I still thought that an admin would only destroy those nodes allocated to him/her. The problem is that Juju destroys nodes that have been allocated independently of Juju. [13:20] danwest: Not yet. [13:20] my understanding is that for hostname placement you need to create a tag with the hostname in it [13:20] danwest: Speaking for me. [13:20] which just seems wrong [13:20] danwest: Eugh, I hope not. [13:20] allenap: going to ping juju folks to check if they know [13:21] allenap, well, i thought the bug was that if you juju bootstraped then juju would release all nodes that it could release. [13:21] and as admin that is "all nodes" [13:21] smoser: I'll check. [13:27] allenap: confirmed with juju-core folks that new maas constraints would indeed require a hostname tag to use hostname as a constraint [13:29] allenap: which means to make it 'just work' we would need to auto-gen a hostname tag but concerned that is unmaintainable [13:29] smoser: You're right. That's fairly awful. [13:30] danwest: It should be fixed in juju-core. [13:31] allenap: agreed but I fear there are arguments against it, at a minimum we need to document this behavior/requirement in maas release notes [13:31] rvba: In juju-core, maasEnviron.AllInstances (and therefore maasEnviron.instances) should not return all instances when handed an empty slice, it should return only allocated instances. Does that sound correct? [13:32] danwest: Yeah, there's nothing we can do to fix that in time for release, other than documenting it. [13:32] agreed, thx [13:32] danwest: Do you know who's looking after the release notes for MAAS? [13:32] allenap: thought it was bigjools, no? [13:32] danwest: Of course, yes. I'll email him. [13:33] roaksoax: ^^? [13:33] the key release note there is "do not be admin" [13:33] allenap: yes, but instances *allocated to this environment*. [13:33] one thing that sucks about "do not be admin" is that there is no way that i'm aware of to create a user that is non-admin [13:33] other than the GUI (which i dont consider useful) [13:34] rvba: One step at a time :) Firstly we just want to only select instances allocated to the calling user, not just all instances. [13:35] allenap: That's correct. [13:35] rvba: Cool. I might see about fixing that then. [13:35] danwest: bigjools is [13:35] roaksoax: thx [13:37] rvba: so ... did you guys land anything that would affect commissioning? i tested it yesterday with saucy on amd64 with no issues whatsoever [13:38] roaksoax: we didn't change anything in this area. [13:38] rvba: then maybe something with the image you used? [13:39] roaksoax: I don't know, I tested using a fresh instance and AFAIK, we check the md5sum of the images we download. [13:39] roaksoax: but I'm happy to test again. [13:41] rvba: sure! ill also test but did yesterday with my moonshot enablement and worked just fine [13:43] roaksoax: I just tested again, same result: "Failed tests," [13:44] k [13:45] rvba: is there console output of the commissioning? [13:45] roaksoax: no [13:46] rvba: well i think it would be a good idea to obtain it [13:46] roaksoax: no sure how to do that in the lab [13:46] not* [13:49] rvba: maybe the new import ephemerals has something to do with it [13:49] roaksoax: possibly… let's see if you see the same problem… [13:50] smoser: http://paste.ubuntu.com/6213826/ everything works except for the network_commands, i was hoping to just append to the existing /etc/network/interfaces but im assuming it doesn't work like that? [13:50] stokachu, well, theres not a lot of value in appending i dont think [13:51] but if you want, just don't override builtin [13:51] and make your entry run after builtin [13:51] i think you will run before builtin as it is, and it would overwrite yours. [13:51] so would putting it in late_commands solve this? [13:52] have to look. i wish i'd have made 'builtin' '00builtin' [13:53] but i think if you just chainge '102_add_vlans' to 'c102_add_vlans' it'll be fine. [13:53] oh, and remove your overwriting of builtin [13:53] ok ill try both ways and see what happens [13:55] stokachu, you can definitely do it in late_commands. [13:56] that paste bin doens't look right hough [13:56] you dont have a clsing ] on 'maas:' [13:57] smoser: yea it chopped it off when copying from vi [13:57] i verified its there [14:05] roaksoax: btw, we need to re-add "saucy" in etc/maas/import_pxe_files. [14:05] yup [14:08] smoser: here is what is currently working http://paste.ubuntu.com/6213897/ [14:08] it adds the vlan information into /etc/network/interfaces now [14:10] i wish i had done a archive format for config. [14:10] such that you could put your config changes separate from maas's stuff. [14:10] so you didn't have to modify maas's late_command [14:10] but could just add your own [14:11] you can do that with multiple configs, but you only have one config here. [14:11] yea so far just one [14:18] what i should have done (and will do in the future) is support an archive format for config. [14:18] ie, 'cloud-config-archive' format. [14:18]