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