=== Aaton is now known as Aaton_off
[03:46] <burnbrighter> bigjools: I saw you updated bug 992075 (this is kurt_ btw  - I finally registered a real nick)
[03:46] <ubot5> Launchpad bug 992075 in maas (Ubuntu) "Commissioning status persists with cloud-init 0.6.3-0ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/992075
[03:46] <bigjools> hi
[03:46] <burnbrighter> hi there
[03:46] <burnbrighter> you say this is expected per bug 1015223
[03:46] <ubot5> Launchpad bug 1015223 in cloud-init (Ubuntu) "cloud-init-nonet main process killed by TERM signal" [Low,Triaged] https://launchpad.net/bugs/1015223
[03:47] <burnbrighter> however, the behavior I see after that message is the system (VM in my case) boots to local disk then thus bypassing PXE boot
[03:47] <burnbrighter> (after the timeout period)
[03:48] <burnbrighter> this has been a real problem with my set up
[03:51] <burnbrighter> and yes, the clocks have been checked in my particular case
[03:54] <bigjools> pxe booting is before that message so it can't be bypassing it
[04:04] <burnbrighter> I'll try again.  I found a debug option to turn on in maas_local_settings.py
[04:09] <burnbrighter> How does this happen...
[04:09] <burnbrighter>   File "/usr/lib/python2.7/dist-packages/maasserver/api.py", line 420, in create_node
[04:09] <burnbrighter>     raise ValidationError(form.errors)
[04:09] <burnbrighter> ValidationError: {u'mac_addresses': [u'Mac address 00:0c:29:91:61:a8 already in use.']}
=== vibhav is now known as Guest81049
[05:10] <bigjools> burnbrighter: you're adding a new node and its mac address is already defined for another
[06:36] <burnbrighter> bigjools: thanks.  It was an old error message.
[06:37] <burnbrighter> bigjools: how goes the cobbler replacement stuff?
[06:37] <bigjools> it goes :)
[06:38] <bigjools> a little tricky but getting there
[06:39] <burnbrighter> good stuff.
[06:40] <burnbrighter> that bug about ubuntu and WOL on HP servers - could that apply to other types as well, or only observed on that particular model?
[06:42] <bigjools> no idea
[06:43] <bigjools> I expect it'd be news if so
[06:57] <burnbrighter> kk
=== Guest81049 is now known as vibhav
[13:44] <rvba> frankban: Hey Francesco, I've got a review for you if you're available: https://code.launchpad.net/~rvb/maas/pxe-off-preseed/+merge/111225
[13:47] <frankban> sure rvba, on it
[13:47] <rvba> ta
[13:47] <rvba> frankban: please add allenap as a second reviewer when you'll be done with it.
[13:48] <frankban> rvba: ok
[14:29] <cheez0r> hey maas guys, I know that Cobbler is deprecated, but I'm trying to access the web interface from a MaaS node- but the http://<host>/cobbler path just gives me a list of files, not the Cobbler WebUI.
[14:29] <cheez0r> Any tips on what path I can use to access the Cobbler WebUI and/or how I can enable the web interface for Cobbler from the MaaS-installed version?
[14:30] <cheez0r> apt-get install cobbler-web fails due to broken packages
[14:45] <roaksoax> rvba: so I';m just about to sent a diff to debian for the yui packaging changes
[14:45] <roaksoax> rvba: if it gets accepted, I'll upload a yui3.5 source package that contains the change in installation method
[14:46] <roaksoax> Daviey: smoser ^^ just FYI.. this is what's blocking me from getting a maas package ready
[14:47] <rvba> roaksoax: cool.  Do you know how long it could take to be rejected/accepted?  I suppose you can't know that in advance but based on previous experience maybe you have an estimate.
[14:48] <roaksoax> rvba: so I'm just submitting a debdiff for them to review. If they accept is up to the maintainer to upload the package. once they do, I'll manually sync it over Ubuntu (yui2.8). This should be days
[14:48] <czajkowski> rvba: allenap jtv you each have a mail from me :)
[14:48] <roaksoax> rvba: so I'm just submitting a debdiff for them to review. If they accept is up to the maintainer to upload the package. once they do, I'll manually sync it over Ubuntu (yui2.8). This should be daysom debian
[14:49] <roaksoax> this should be a day or so
[14:49] <rvba> All right.
[14:49] <roaksoax> rvba: now, to get yui3.5 would bempretty simple with the new install directories in ubuntu
[14:49] <Daviey> roaksoax: ok, if it doesn't get accepted by Monday, we'll carry a diff.. if it's not making progress. deal?
[14:50] <roaksoax> Daviey: ok, so this is what I would do. If they don't accept the changes, I'll update yui to 3.5 and start carrying a diff (for which we would have a yui source package instead of yui3.5 source package)
[14:51] <roaksoax> Daviey: my plan was to first make them accept changes in tt 'yui' source package, so then we can upload a 'yui3.5' source package, that won't have conflicting installation paths
[14:51] <roaksoax> rvba: ^^
[14:55] <rvba> czajkowski: I'm not sure round robin is an appropriate method here.  Some questions will require knowledge that only some of us have.
[14:56] <Daviey> roaksoax: that sounds like a winner
[14:56] <rvba> roaksoax: sounds good to me too.
[14:57] <rvba> roaksoax: btw, do you need me to fix up the usage of raphaeljs now or can it wait ~1 week?
[14:57] <roaksoax> rvba: it can wait... either way it is a tiny js lib
[14:57] <czajkowski> rvba: right but also posting to the list isnt ideal either so if yours does suit, then tell me and I'll find someone else but the questions do need to be answered.
[14:58] <roaksoax> rvba: I'll, however, upload a new librapahel to archives
[14:58] <roaksoax> rvba: so is ready to use when you do so
[14:58] <rvba> roaksoax: cool.
[14:59] <roaksoax> rvba: oh btw.. now yui source shipts a build/* and a api/* dir. I';m installing build under /usr/share/javascripts/yui/<ver>/ and api inside that dir, makes sense?
[14:59] <czajkowski> rvba: trying to be fair, I had 3 questions, so you each got one.
[14:59] <czajkowski> I've spoken to mrevell about this and agreed it there as we are trying to support the users and questions
[15:00] <rvba> czajkowski: I completely agree that we should make an effort to answer questions.  I'm just not sure the round robin method is appropriate.
[15:01] <czajkowski> well posting to the list means it goes into the unknown
[15:01] <czajkowski> and there is no accountabilty for when it will be answered and by whom
[15:01] <rvba> czajkowski: I'll have a look at "mine" though.  At first glance it just looks like something for the packaging guys.  but I guess this will be true for most of the questions ;).
[15:02] <czajkowski> rvba: ok, what are would you prefer ?
[15:02] <rvba> roaksoax: you mean that the 'api' directory will end up in /usr/share/javascripts/yui/<ver>/api ?
[15:02] <roaksoax> rvba: yes
[15:02] <rvba> roaksoax: sounds good to me.
[15:04] <rvba> czajkowski: I think we (the red squad and the server team) should commit to answering to one question every day.  But we should pick the questions.  For instance, for "my" question, I'll have to poke someone from the server team.
[15:04] <roaksoax> rvba: cool then
[15:09] <rvba> czajkowski: note that appreciate the fact that you're trying to get the questions answered.  We should probably help more with that … and I agree we probably need to be "pushed" a little ;).
[15:10] <rvba> frankban: time for another review? https://code.launchpad.net/~rvb/maas/use-reverse/+merge/111240
[15:11] <czajkowski> rvba: fair enoughm you can find someone to answer it, but at present it's been sitting there
[15:11] <frankban> sure rvba
[15:11] <rvba> ta
[15:11] <czajkowski> I spoke to Daviey and said I'd ask as a filter to spread the questions to people
[15:14] <rvba> czajkowski: I guess my whole point is that round robin is probably not the appropriate filter then.  Even if it's a filter, I give you that :).  Deployment questions involving images, boot sequence etc can be better handled by the server team.  Questions related to how to do manual stuff with nodes, how to customize things (other than images & stuff) are best for the red squad.
[15:15] <rvba> czajkowski: does that make sense?
[15:16] <czajkowski> rvba: right, but again, if you can't answer it, ask someone else to answer, it. At present all the questions are not being answered or are falling to one person.
[15:16] <czajkowski> rvba: I can roughly work out which one goes to a person, but am trying to be fair here as well so one person doesnt get all the easy ones and not one person gets lumped with them all either.
[15:17] <rvba> czajkowski: fair enough.
[15:48] <cheez0r> Daviey: are you around?
[15:48] <Daviey> cheez0r: today, i am mostly asquare.. but at least i am here.
[15:48] <cheez0r> Cool- mind if I PM you for a sec?
[15:49] <Daviey> rvba / czajkowski : I entirely agree that having a single marshal is better than 'best effort'.. Round-robin until czajkowski fully appreciates where best to push particulars, makes most sense.
[15:49] <Daviey> ... really, just having someone on the hook to make sure the issues is resolved is key.
[15:49] <Daviey> cheez0r: sure
[16:00] <Daviey> smoser / roaksoax: would you be able to help out cheez0r?
[16:01] <cheez0r> They've been providing assistance on occasion so far
[16:01] <Daviey> He has dual nic in the bootstrap node..
[16:01] <Daviey> Sounds like zookeeper isn't coming up
[16:01] <Daviey> ... and no ssh key sent to the node... could be contacting metadata service issue
[16:01] <cheez0r> I'm actually about to go through decommissioning and recommissioning all of my nodes except the MaaS node
[16:01] <cheez0r> let me work through that and then try a fresh juju bootstrap and see where we get
[16:01] <Daviey> super
[16:02] <cheez0r> I'll also do the SSH key workaround- I published it to http://askubuntu.com/questions/147714/invalid-ssh-key-error-in-juju-when-using-it-with-maas
[16:05] <smoser> cheez0r, after you've insalled a node, and can ssh into it, then i'd like to see what we can figure out
[16:05] <smoser> i'm fairly certain that the node is not seeing the metadata service
[16:06] <Daviey> ugh
[16:06] <Daviey> I agree with smoser.
[16:07] <cheez0r> well part of my issue today is time; I've only got about an hour and a half before I have to take off.
[16:08] <cheez0r> anyhow let me get started rebuilding the MaaS, back in a bit.
[16:23] <cheez0r> Okay, all of the nodes are in the process of commissioning. Here's an overview of my current environment: MaaS Node is dual-homed, eth0 is dom0 network, 192.168.1.1/24, eth1 is public, IP masquerade is configured for outbound connections from dom0 network, maas-dhcp is installed and both it and the maas package have been dpkg-reconfigured.
[16:24] <cheez0r> Steps done so far: 11 nodes added to MaaS WebUI GUI and rebooted. User has SSH public key populated in both ~/.ssh/id_rsa.pub and the MaaS WebUI.
[16:26] <cheez0r> Unusual configuration aspects: IP masquerade; dnsmasq is configured for static IP mappings for all 11 nodes, and /etc/hosts on MaaS node has entries for static IP address to hostname mapping for all 11 nodes that match their DNS Name in Cobbler/MaaS.
[16:27] <cheez0r> One more note: This is HP BladeServer hardware that doesn't support WOL very well, so I've been manually booting the nodes.
[16:29] <cheez0r> All 11 nodes are done with commissioning and are now off.
[16:38] <smoser> cheez0r, the nodes got through the commissioning without issue or help?
[16:39] <cheez0r> they're all in Status: Ready right now.
[16:39] <cheez0r> My next step would be to juju bootstrap and then manually power on the node it picks to host the juju system.
[16:40] <cheez0r> (and yes, got through commissioning with nothing other than adding them to MaaS and power-cycling the box.)
[16:42] <Daviey> so.. that suggests MD is working.
[16:42] <cheez0r> should I proceed?
[16:42] <Daviey> yeah
[16:42] <cheez0r> bootstrap completed, I see the node allocated in MaaS.
[16:42] <Daviey> smoser: ^
[16:43] <Daviey> so, lets see how the install goes.
[16:43] <cheez0r> server is now powering up; takes 5-8 minutes, damn HP hardware
[16:44] <Daviey> heh
[16:45] <smoser> bootstrap completed.
[16:45] <smoser> meaning juju says so?
[16:45] <cheez0r> yes.
[16:46] <cheez0r> meaning juju can contact maas and allocate a node.
[16:46] <cheez0r> so now once the machine is booted up, I should be able to run juju status and get a status response from juju.
[16:46] <cheez0r> It just started the PXE boot.
[16:57] <cheez0r> okay, the machine is now booted to a login screen.
[16:57] <cheez0r> ran juju -vvv status; accepted the SSH key warning, and now the server is refusing to accept the client.
[16:57] <cheez0r> oh, wait.
[16:57] <cheez0r> it actually worked!
[16:57] <cheez0r> SWEET!
[17:00] <cheez0r> so now I've deployed mysql and just booted the node maas picked for it.
[17:01] <Daviey> \o/
[17:01] <cheez0r> Daviey: it was your hostname questions that pointed me in the right direction
[17:02] <cheez0r> the hostname of the MaaS node was resolving to the public IP.
[17:02] <burnbrighter> When api keys are correctly installed in environments.yaml, and you run in to:
[17:02] <burnbrighter> Bootstrap aborted because file storage is not writable: The supplied storage credentials were not accepted by the server
[17:02] <cheez0r> I fixed that and it seems to have fixed my SSH key propagation issue.
[17:02] <burnbrighter> any ideas?
[17:02] <Daviey> cheez0r: thought it might be something like that
[17:02] <Daviey> super
[17:05] <cheez0r> and on that note I'm out of time for today; we'll have to pick up tomorrow sometime. Thanks for the help Daviey and smoser!
[17:08] <Daviey> cheez0r: speak soon!
[18:39] <burnbrighter> cheez0r: I'm looking at your solution here: http://askubuntu.com/questions/147714/invalid-ssh-key-error-in-juju-when-using-it-with-maas
[18:40] <burnbrighter> what needs to be done after the maas.preseed is updated?
=== Aaton_off is now known as Aaton
[23:33] <cheez0r> burnbrighter: re-commission the nodes and boot them.
[23:33] <cheez0r> When they come up, the ssh key should work.
[23:33] <cheez0r> err, the password should work.
[23:34] <cheez0r> also read the note below the answer- the cause of my lack of SSH key propagation seems to have been a hostname issue with the MaaS node.