[07:57] Bug #1464866 changed: Unable to commission node which needs hwe kernel on trusty [08:27] Bug #1464984 changed: Crash in TFTP server booting NUC under UEFI [08:57] Bug #1464894 changed: Crash in TFTP server code serving UEFI boot loader [12:44] * Mmike grabs food [14:31] Bug #1465305 opened: Spurious test failure: UnknownRemoteError: Code: exceptions.TypeError: query() argument after ** must be a mapping, not unicode [15:28] I am trying to setup MAAS 1.8.0 rc3 on an HP Moonshot. When I click "Chassis" under the "Add Hardware" dropdown, choose "Moonshot Chassis Manager" for "Power type", and enter my host/username/password info, I get the following: http://paste.ubuntu.com/11719979/. Any suggestions? [15:43] ctlaugh_, you get that in the web UI? [15:43] newell, ping? ^ [15:43] ctlaugh_, just for comparison, have you tested 1.7.5 and does it work? [15:44] kiko, newell: yes -- it shows up in the UI [15:45] roaksoax, potential 1.8 bug above [15:46] let me get our moonshot qa team here [15:46] ctlaugh_: so just to make sure I understand what you are doing, you tried probe-and-enlist with 1.7.5 and 1.8.0 rc3 and the first one works and the later doesn't? [15:46] newell, he's doing add hardware which AIUI is new in 1.8 [15:47] kiko: okay never tried adding a chassis with that new capability yet, could be a new bug [15:48] If a bug is filed I don't mind taking a look at it [15:48] newell, could you test meanwhile? ctlaugh_ can add a bug, but his experience is pretty simple [15:48] ctlaugh_, which cartridge type? [15:49] kiko: I haven't tried 1.7.5. I just added the ppa:maas-maintainers/testing and grabbed the lastest out there. [15:49] ctlaugh_, if you could try with 1.7.5 that would give us subsidy to stop the presses with 1.8 and get the bug fixed [15:50] i.e. if it is a clear regression in 1.8 [15:50] newell: I haven't tried 1.7.5. The latest I was running with before was some version of 1.7 that did NOT have the new Add Chassis UI. [15:50] kiko: yeah I will test [15:51] kiko: I'm using a mix of m300 and m400... BUT, I haven't even gotten to the point of enlisting anything. I was just trying to add the chassis. [15:51] ctlaugh_, without the UI, you can still do probe and enlist through the CLI -- did you know that? [15:51] kiko: I did know that, but I do it so infrequently that I can't remember how :) [15:52] ctlaugh_, sure, but I guess my question you've answered -- with 1.7 you did it via the CLI and I presume it worked. [15:52] kiko, newell: are there any additional logs that I could grab that would help? [15:52] kiko: I did via the web UI and it worked. [15:53] kiko: (in 1.7) [15:53] ctlaugh_: if you look at /var/log/maas/*.log files on the region and/or cluster controller machines that would help [15:54] kiko: but that was before the "Add Chassis" functionality. I just manually added the MACs of the nodes I wanted, and manually entered the MSCM IP and auth info and everything worked fine. [15:54] ah [15:54] ctlaugh_, so you never used the probe and enlist action [15:55] kiko: narinder gupta did help me with a script to probe and enlist the moonshot chassis and nodes from CLI and that worked with 1.7 too. [15:55] newell, is it undocumented, maas cli probe and enlist? if not, could you get us a URL? [15:55] ctlaugh_, ah, that script likely called probe and enlist [15:57] ctlaugh_: kiko: http://maas.ubuntu.com/docs/api.html#nodegroup look for probe_and_enlist_hardware in this section [15:58] newell, that's not trivial to convert into a cli example though [16:02] kiko: you didn't ask for an example :P, one sec [16:03] newell, "I hate our docs" [16:05] newell, kiko: looks like, from the error JSON, it's trying to do the probe_and_enlist and that's what's failing. The only thing I see in the logs related to this is a 400 entry in the apache2/access.log. [16:05] newell, kiko: http://paste.ubuntu.com/11720179/ [16:09] ctlaugh_: if you do this you should be able to probe and enlist from the cli [16:09] $ uuid=$(maas admin node-groups list | grep uuid | cut -d'"' -f4) [16:09] $ maas admin node-group probe-and-enlist-hardware $uuid model=mscm host=10.228.45.67 username=chassis_username password=chassis_password [16:10] where "admin" is the maas profile and the host ip address is supposed to be ip for the Chassis [16:15] newell: I just ran the command.... returned with no visible output. [16:20] ctlaugh_: nothing in the logs? nothing showing up on the UI as being enlisted? [16:21] newell: No change in the UI yet, no apparent log messages either [16:23] ctlaugh_: can you --> tail -f /var/log/maas/*.log so that you can see what is happening when you issue that command? [16:23] ctlaugh_: you should definitely see something after issuing the probe and enlist command [16:26] newell: regiond.log had a single line show up showing the HTTP POST coming in (with 400 HTTP response code) [16:27] ctlaugh_: can you paste the command you used? [16:30] newell: http://paste.ubuntu.com/11720318/ [16:53] ctlaugh_: don't know if you responded to me or not, I lost connection [16:53] newell: Here's the command and regiond.log message: http://paste.ubuntu.com/11720318/ [16:55] ctlaugh_: docs say 400 error is form parameters not being passed properly. Could you try to use the deprecated cli command probe-and-enlist-mscm and then just delete the model=mscm portion? [16:56] newell: That got a "Success" message from the CLI and an HTTP 200 in regiond.log. [16:57] newell: Nodes are showing up in the web UI too [16:58] ctlaugh_: would it be possible for you to report a bug on this? That would help. [16:59] https://bugs.launchpad.net/maas [17:01] newell: Yes, no problem [17:02] ctlaugh_: thanks :) [17:02] ctlaugh_: go ahead and post the bug url here when you are done and I will assign myself to it [17:08] newell, okay, so it's broken for real in 1.8? [17:08] kiko: I haven't tested it myself but when he uses the deprecated probe-and-enlist-mscm it works [17:08] while when he uses the probe-and-enlist-hardware it doesn't, so something is not working right [17:08] I'm trying to get sfeole to join as I am curious how testing hasn't picked this up [17:11] ctlaugh_: could you do another test for me? Could you try the original probe-and-enlist-hardware command that was failing but also pass the accept_all=true parameter at the end (in addition to what you had before)? [17:11] newell: https://bugs.launchpad.net/maas/+bug/1465353 [17:12] newell: still failed (with accept_all=true) [17:12] ctlaugh_: thanks [17:16] newell: no problem -- glad to help [17:20] Bug #1465353 opened: Unable to probe and enlist a Moonshot chassis in MAAS 1.8.0 (rc3+bzr4000) [17:37] ctlaugh_, thanks for testing! we'll get this nailed. thank narinder for the assistance if you run into him [17:37] ctlaugh_, what are you using maas for? [17:39] kiko: No specific purpose... just using to quickly provision clean nodes when needed for testing. In the past, was using w/ Juju to deploy Openstack on the nodes. [17:39] cool [18:18] ctlaugh_: you still around? [18:18] newell: yes [18:19] ctlaugh_: could you test the probe-and-enlist-hardware again with one slight modification? [18:19] yes [18:20] do same command but instead do model=mcsm [18:21] newell: 'c' and 's' switched positions? [18:21] yeap [18:21] typo ;) [18:21] newell: success.... [18:21] cool [18:21] ctlaugh_: can you now test with the add hardware on the UI? [18:23] newell: still an error (as expected?)... data: host=10.36.0.21&username=administrator&password=password&model=mscm [18:24] oh okay yeah...now we need to change the file [18:24] ctlaugh_: can you do this... [18:24] open with admin rights /usr/lib/python2.7/dist-packages/maasserver/api/nodegroups.py [18:24] do a search for mcsm and switch it to mscm [18:24] save the file [18:24] then on the command line restart the region by doing.... [18:25] $ sudo restart maas-regiond [18:25] then retry using the webui [18:27] newell: That worked -- no visible "success" message, but the "panel" closed and a few seconds later, a new node that I had previously deleted reappeared. [18:29] ctlaugh_: cool, thanks for testing that out for me [18:30] newell: You're welcome. Glad that's all it is :) [18:31] ctlaugh_: I typo'd it in the source and unit tests so didn't catch until you reported this, thanks [18:32] kiko: https://code.launchpad.net/~newell-jensen/maas/fix-1465353/+merge/261997 [18:32] I know this needs to be backported to 1.8 branch as well [18:37] kiko: gotta run for doctors appointment but will do an MP for 1.8 branch when I get back [18:41] Bug #1465367 opened: Enhancement: Display node architecture in table [18:42] Can any of you guys point me to an example of a commissioning script ? [18:43] I can't seem to get a simple script working and I think an example would point me in the right direction [18:44] kiko, roaksoax ^^ ? [18:45] negronjl, roaksoax is on vacation, blake_r is on paternity leave and I am clueless, but.. [18:45] let me try and help [18:45] haha [18:45] hey kiko ... thx for trying [18:47] kiko: Im trying this on MAAS 1.8 if it makes any difference [18:49] negronjl, I don't think it does, and to confirm, this is not about a preseed, but rather custom commissioning, right? [18:50] kiko, correct [18:50] negronjl, what are you wanting to do during commissioning incidentally? [18:50] (brb) [18:50] Bug #1465367 changed: Enhancement: Display node architecture in table [18:50] kiko: Trying to modify /etc/environment by adding some http_proxy .... and https_proxy stuff to it [18:50] kiko: Any example that creates a file should give me a good idea [18:51] kiko: creates and populates a file I should say [18:52] negronjl, hmm, but how could that be relevant for commissioning? that feels like something you want to do during install no? [18:52] kiko: That's the thing ... I can't find any documentation on when the commissioning scripts run or if they persist ... so I'm trying there ... [18:53] kiko: Is this something that I should be doing via /etc/maas/preseed/preseed_master ? [18:53] ah! [18:53] negronjl, what you want is a custom preseed [18:53] negronjl, I happen to have an example of that [18:53] kiko: cool [18:53] http://paste.ubuntu.com/11549501/ [18:53] negronjl, it's a bit cryptic so bear with me [18:53] negronjl, I think this can only be done via the CLI at the moment [18:53] (and smoser can correct me if I'm wrong) [18:53] but [18:54] $ maas home-smoser node start node-79b67e82-d25c-11e4-a333-00163eca91de user_data=XXX= distro_series=trusty [18:54] negronjl, the user_data piece is the secret there; it's a base64-encoded string [18:54] in this case, this is the script that was encoded [18:54] http://paste.ubuntu.com/11549482/ [18:55] kiko: The encoded script is what you used in user_data=..... right ? [18:56] negronjl, you pass in base64 encoded user_data. cloud-init reads that user_data during first boot of the installed system. [18:56] kiko: This works for me ... it does what I need [18:56] kiko: Any chance of setting this globally ? [18:57] no. [18:57] smoser, ack ... thx [18:57] you need vendor_data for that (which maas *does* need) [18:57] well, so not 'no'. === imthewherd is now known as cgseller_is_away [18:58] you oculd do it in the preseed_master as you showed or in a late_command to /etc/maas/preseeds/curtin_userdata [18:58] yup ... that works for me [18:59] negronjl, just a warning, though, /etc/environment will not be paid attention to by upstrat. [18:59] upstart [18:59] Bug #1465367 opened: Enhancement: Display node architecture in table [18:59] damn proxies ... they are everywhere here ... so I'll have to figure something out for that [18:59] or services that it invokes. [18:59] kiko, smoser: thx for the help ... this gives me the information i need [19:00] negronjl, for such an environment, /etc/environment is the best i've come up with though. :-( [19:00] smoser, yup ... that and a hijacking iptables rules to redirect to proxy :/ [19:00] not elegant but, it works ( mostly ) [19:00] you can make it more dynamic by putting a forwarding proxy like tinyproxy on the system. [19:00] and pointing everything at that. [19:01] oh, i never tried hijacking iptables rules. [19:01] http://bazaar.launchpad.net/~smoser/+junk/sstack-proxy/view/head:/sstack-proxy [19:01] that is what I do some places. [19:02] it is a pain though, in that it means all connections require the intermediate proxy. [19:02] smoser: and some things like embedded pip commands ignore proxies altogether [19:02] yeah, its AWESOME. [19:04] The iptables rule that I use ( normally on the MAAS server ): sudo iptables -t nat -A PREROUTING -i -p tcp -m multiport --dports 80 -j REDIRECT --to-ports 3128 [19:04] and http_port 3128 transparent somewhere in squid.conf [19:24] smoser, ah, late_command in curtin_userdata is the piece I was missing [19:25] smoser, is there a bug on vendor_data for maas? [19:29] i guess not, kiko. [19:29] i answered 'vendor_data' to you a while ago when you asked about landscape integration [19:30] I am clueless about these magic feature strings though :) === cgseller_is_away is now known as imthewherd [19:41] negronjl, would it be annoying to ask you to post an ask.ubuntu.com question that I could respond with this? [19:42] negronjl, it could serve as an initial stab for proper documentation [19:42] kiko: Sure .. give me a few to test this out [19:57] kiko: https://askubuntu.com/questions/636837/are-there-examples-of-commissioning-scripts [19:58] negronjl, you rock^2 [21:26] negronjl, smoser: http://askubuntu.com/questions/636837/are-there-examples-of-commissioning-scripts/636867#636867 [21:26] your comments welcome [21:26] smoser, I would like some detail on vendor_data and your reference to preseed_master [21:28] ah, I see, it could be added to preseed_master as opposed to the late_commands stanza in curtin_userdata [21:28] the naming of these files is FUCKING CONFUSING!!