#maas 2012-07-09
<roaksoax> rvba: howdy! did enlistment change for some reason?
<rvba> roaksoax: not that I know of...
<roaksoax> rvba: ok, I;ll check as robbiew reported some issue there in on of the latest bzr revs that I pushed last week
<roaksoax> robbiew: could you confirm the enlistment issues you were seeing?
<robbiew> yo
<robbiew> well, I suspect it was dnsmasq hokey ness....I'm using my laptop as the maas server
<robbiew> so there's dnsmasq all over the damn place :/
<roaksoax> heh, maybe indeed. I haven't really tested enlistment yet. But will do and try to confirm whether there's an issue there
<robbiew> roaksoax: okay...let me sort out this dnsmasq nightmare first, then I'll re-enable the ppa
<roaksoax> cool!
<robbiew> roaksoax: okay...so I just remove/purged it all, and will renable your ppa now
<robbiew> these remote access cards are awesome btw...web control and KVM access is sweet
<roaksoax> hehe nice!!
<robbiew> I really think we need to figure out a better way to get dnsmasq playing nicely with existing processes on Ubuntu Desktop...it's PITA otherwise
<robbiew> at least defaulting to bind-interface
<robbiew>  bind-interfaces
<roaksoax> well I guess we could bind the interface that is being used for MAAS in that case
<roaksoax> though dnsmasq will soon be removed once the bind9 support is added
 * roaksoax brb
<robbiew> roaksoax: enlist failed
<robbiew> :/
<robbiew> RoAkSoAx: http://pastebin.ubuntu.com/1083114/
<robbiew> I suspect this is the cause of the error
 * robbiew is using the testing ppa on precise...not quantal or bzr trunk
<roaksoax> robbiew: ack. I'll look into that now
<robbiew> cool, thx....I'll grab lunch ;)
<roaksoax> robbiew found the issue will give you a patch after lunch :)
<robbiew> cool deal
<robbiew> thx!
<robbiew> RoAkSoAx: so ipmi over lan seems a bit broken...or at least I can't seem to set it properly in MAAS...cobbler complains everytime I try
<roaksoax> robbiew: alright, I'll take a look
<robbiew> RoAkSoAx: nevermind...helps to have ipmitool installed
<robbiew> maybe make that a depends on maas...or at least have it check for it somehow
<robbiew> the error message provided: "Unknown problem encountered with the Cobbler server."  doesn't help much :P
<roaksoax> robbiew: hehe yeah it doesnt/ though I think the depends is missing in fence-agents
<roaksoax> will take care of that
<roaksoax> I'll have your patch in a bit
<roaksoax> (for the enlistment
<robbiew> RoAkSoAx: agreed
 * robbiew ran the command in cobbler template...and boom! :)
<robbiew> works
<robbiew> RoAkSoAx: still can't seem to mark IPMI-over-LAN as a power on option in MAAS.  I think MAAS is incorrectly passing an option to cobbler
<robbiew> http://pastebin.ubuntu.com/1083356/
<roaksoax> yeah seems that somethign is missing there
<robbiew> again...I'm using the latest in the testing PPA, so /could/ already be fixed in trunk
<roaksoax> I will get the latest trunk today too
<robbiew> perfect, thx
<roaksoax> robbiew: http://paste.ubuntu.com/1083378/ apply that in /usr/share/pyshared/maas/ and restart maas
<robbiew> ok
<robbiew> RoAkSoAx:  assuming you meant /usr/share/pyshared/maasserver/ ;)
<robbiew> applied
<roaksoax> robbiew: ah yes :)
 * robbiew restarts and reboots one of the servers
<robbiew>  RoAkSoAx:  hmm....no change, but maybe I didn't properly restart maas...given there's no "maas restart", that's always a bit tricky to me
 * robbiew goes to do a system reset just to be sure
<roaksoax> sudo service apache2 restart should do the trick
<robbiew> RoAkSoAx: worked
<robbiew> ;)
<roaksoax> \o/
<roaksoax> allenap: still around?
<robbiew> RoAkSoAx: things looking good...the ipmi stuff isn't *that* big of a deal, but would be a nice to have for the demo on Wednesday...but I can also talk my around it, if need be ;)
<robbiew> juju bootstrap worked
<robbiew> so whoohoo
<roaksoax> robbiew: cool, and yeah I already fixed the ipmi selection on the UI, but now I found a different bug related to that, so I'm gonna upgrade to latest trunk and test again
<roaksoax> so I'm guessing it should be fixed tomorrow
<robbiew> cool
#maas 2012-07-10
<ScheerI> Hello Dear Members! I would like to use xen under ubuntu maas cloude. Can someone show me some directions about it?
<ScheerI> I was searching howtos about, but I did'nt find anything.
<roaksoax> rvba: howdy!
<roaksoax> allenap: howdy
<rvba> \o roaksoax.
<allenap> roaksoax: Hello!
<roaksoax> rvba: so I'fe found a couple errors that seems to be related to JS script
<rvba> roaksoax: I'm listening :)
<roaksoax> allenap: so I so you added python-tx-tftp to trunk.. where's the source that you wanted me to package
<allenap> roaksoax: otp, be with you in 20 minutes.
<roaksoax> rvba: i found them while testing the power stuff for ipmi, which also is buggy and doesn't work. Trying to fix it
<roaksoax> allenap: sure
<allenap> roaksoax: https://github.com/shylent/python-tx-tftp
<roaksoax> rvba: let me get you access to the instance first
<rvba> k
<roaksoax> rvba: oh and the SRU for maas 1.0... you are killing me man.. it requires overwriting the config on the SRYU and I'm not sure whether we wanna do that
<roaksoax> :)
<roaksoax> robbiew: you are welcome! here's the ipmi patch http://paste.ubuntu.com/1084518/ you should patch /usr/share/pyshared/provisioningserver/
<roaksoax> robbiew: then sudo service maas-pserv restart && sudo service apache2 restart
<roaksoax> robbiew: i haven't yet uploaded a new version as there are a few JavaScript issues I wanna run first with rvba
<rvba> roaksoax: I'm back, I'll have a look at the JS issue right now.
<robbiew> RoAkSoAx: nice, thanks!
<roaksoax> rvba: awesome. so 1. Add button doesn't respond (sometimes) 2. When editing node, sometimes power parameters boxes are not automatically shown. 3. when editing a node, some images seem to not show. That's up to bzr720
<rvba> roaksoax: the "sometimes" is frightening.
<roaksoax> rvba: is enum.js correlated to any of these?
<rvba> roaksoax: I don't think so.
<roaksoax> robbiew: you're welcome. just let me know if you run into any more issues
<roaksoax> rvba: ok!
<robbiew> RoAkSoAx: for sure
<rvba> roaksoax: that's what my gut feeling tells me but I'll investigate and get back to you.
<roaksoax> rvba: alright, cool, thanks
<rvba> roaksoax: the problem is indeed related to the enum.py change.
<rvba> roaksoax: we're looking for code snippets based on the names of the available power methods.
<roaksoax> rvba: hold on, I applied this patch http://paste.ubuntu.com/1084518/ for it to work
<roaksoax> rvba: however, even with the patch applied there's JS issues
<roaksoax> rvba: i.e. I select a different power method, and the boxes stay and JS does not update
<rvba> roaksoax: all the problems I see are related to the wrong enums.py.
<roaksoax> rvba: this is what I see: http://people.canonical.com/~andreserl/power.png
<roaksoax> allenap: the tft is still not operational right?
<rvba> roaksoax: also, the problem with the images is a bug, plain and simple, a wrong path.  I'll fix that right away.
<roaksoax> rvba: cool
<roaksoax> rvba: btw.. who disabled http://paste.ubuntu.com/1083378/
<roaksoax> rvba: its breaking enlistment
<roaksoax> )
<roaksoax> rvba: because maas-enlist in precise sends after commmissioning action = 2
<rvba> roaksoax: hum, bzr blame says Jeroen did that, not sure why...
<rvba> jtv: are you around by any chance?
<roaksoax> rvba: heh, ok, I'll reenable it
<rvba> roaksoax: let me track down in which branch it was disabled first.
<roaksoax> k ;)
<rvba> I don't think Jeroen did that without a good reason.
<rvba> roaksoax: that change looks wrong.
<roaksoax> rvba: ok, I'll get that fixed then
<rvba> roaksoax: cool
<roaksoax> allenap: so let me know when we can discuss the tftp stuff please
<roaksoax> rvba: would you be so kind of reviewing https://code.launchpad.net/~andreserl/maas/reenable-after-commission/+merge/114206
<roaksoax> abd https://code.launchpad.net/~andreserl/maas/correct_power_methods/+merge/114198
<roaksoax> i need to roll up an update
<roaksoax> a packaging update
<rvba> roaksoax: I'm getting confused now, why did you s/ipmi/ipmitool/ exactly, that seems to be what caused the problem...?
<roaksoax> rvba: because ipmi looks for a file like: /etc/cobbler/power/power_ipmi.template which doesn't exist and consequently fails
<rvba> I mean these values are completely internal.  But the problem arises where there is a difference between enum.py and enums.js.
<rvba> roaksoax: oh, I see, maybe we should simply rename the template then.
<roaksoax> rvba: right, but renaiming the template causes more problems because we have to SRU to precise, and roll testing updates of maas-provision and etc etc
<rvba> Well, I guess it's six of one and half-a-dozen of the other.
<rvba> roaksoax: ok
<roaksoax> rvba: i think once cobbler is ditched, we can change them back
<rvba> Like I said, these values are internal so it's really not a problem.
<roaksoax> ok cool :)
<rvba> roaksoax: but that template should be shipped in MAAS itself rather than fetching those from cobbler.
<roaksoax> rvba: right, but we are still using cobbler for power management
<rvba> roaksoax: MAAS supports that now, the templates are in: ./src/provisioningserver/power/templates/
<rvba> but we only have ether_wake.template  virsh.template right now.
<roaksoax> rvba: and are these templates being used to do the power management?
<roaksoax> rvba: because, as I can see, these are still pushed into cobbler
<rvba> roaksoax: they should be.  At least everything is in place to do so.  I'm not sure if the very last bit of wiring has been done though.
<roaksoax> rvba: ok, as far as robbiew tests from yesterday, it is cobbler the one who stll does the power management
<roaksoax> rvba: http://pastebin.ubuntu.com/1083356/ -> that's the error
<roaksoax> in cobbler
<roaksoax> rvba: that's why I';m saying, once we ditch cobbler we can simply merge rename then and add the templates
<robbiew> RoAkSoAx: I haven't tested the patch you sent yet, but I was able to set IPMI-over-LAN without the previous error...so a good sign
<robbiew> oddly, I had to select IPMI-over-LAN...save...and then go back to add the IPMI-over-LAN info
<rvba> robbiew: that's weird.
<rvba> robbiew: you mean the power info was not persisted the first time you saved the page?
<roaksoax> rvba: it didn't persist because it failed to save
<rvba> robbiew: about the branch "reenable-after-commission", I don't think we want to enable "NODE_AFTER_COMMISSIONING_ACTION.CHECK".
<robbiew> RoAkSoAx:  right...I selected it, and I wasn't able to fill in the info
<robbiew> until I saved and went back to edit again
<rvba> robbiew: err, roaksoax ^
<roaksoax> robbiew: yeah that's a JS issue that will be fixeddnoce  role up the nn package
<roaksoax> robbiew: i'll update the branch
<roaksoax> err
<roaksoax> rvba: :)
<rvba> haha :)
<roaksoax> haha
<roaksoax> rvba: so anyways, the problem was thii. 1. edit node. 2. select  ipmi. 3. save failure. Why? because when the information was sent to cobbler there was no power template named power_ipmi.template
<roaksoax> rvba: cobbler failed, telling maas "I failed", and consequently maas didn;t save
<rvba> I get it now.  Note that this whole power management UI was never meant to be used with Cobbler.
<roaksoax> rvba: so changing s/ipmi/ipmitool sets the power type ot ipmitool in cobbler, which works, and maas can save the node
<roaksoax> rvba: oh indeed, but it is still doing so
<roaksoax> rvba: still sending the updates to it
<rvba> roaksoax: Right, we need to change this.
<robbiew> RoAkSoAx: just did a juju deploy and the machine was allocated...but not powered on :/
<roaksoax> robbiew: uhmm ok I think what it is wrong
<roaksoax> robbiew: i think we need the ipmi templates then
<robbiew>  RoAkSoAx:  I have templates in /etc/cobbler/power
<robbiew> do they need to be somewhere else?
<roaksoax> robbiew: i think maas is not using cobbler for that anymore
<robbiew> ah
<roaksoax> i'll have to check that
<rvba> roaksoax: I'm not sure your fix to enum.py will be us very far.  Like I said, there parameters are not meant to work with cobbler template so the fact that the names are almost compatible is mostly luck (well, and the fact the our templates are greatly inspired by cobbler's templates).
<rvba> s/will be/will get/
<rvba> s/there parameters/these parameters/
<roaksoax> rvba: https://code.launchpad.net/~andreserl/maas/reenable-after-commission/+merge/114206 updated
<rvba> roaksoax: the thing is that these values were disabled because there is no actual implementation behind them.
<roaksoax> rvba: right, the problem is this: "power_type = ipmi" is save as power_type in cobbler, and that power type in cobbler does not exists
<roaksoax> rvba: so when virsh and ether_wake where created in maas, they matched the names of power_type in cobbler
<rvba> roaksoax: maybe maas enlist should simply use the default value (0) instead.
<robbiew> well all I know is that if I run the command in the cobbler ipmilan template...it works :)
<roaksoax> rvba: yeah but I
<roaksoax> rvba: yeah but I'd need to SRU that
<roaksoax> and SRU takes times :)
<roaksoax> robbiew: cool, yueah so it seems that maas is not using cobbler for that anymore
<robbiew> coolio
<robbiew> no biggie..it's clearly trivial, so I can tell folks it's coming soon ;)
<roaksoax> robbiew: i'll try to get that working within maas itself by tonight
<roaksoax> rvba: removing those after commissioning actions is a feature removal and is not backwards compatible
<rvba> roaksoax: even better, you can just omit the 'after_commissioning_action' parameters during enlistment and the default action will be picked up by MAAS.
<rvba> roaksoax: well, not really, we simply removed the UI because there was nothing behind it.
<rvba> roaksoax: if we want to enable these only to test things, then that's fine but it really doesn't make sense to enable them on trunk as there is no functionality behind it.
<roaksoax> rvba: right the only problem i see is that we need to fix maas-enlist in precise
<rvba> roaksoax: is that a problem only because of the SRU thingy?  I confess I don't really know how much work that involves so I'll let you and Daviey be the judges on that... but I'd rather not enable an option in the UI which doesn't mean anything yet.
<roaksoax> rvba: SRU in this case is really simply TBH
<roaksoax> rvba: but if I wanted to add more functionality then that's a problem SRU'ing
<roaksoax> or bacporting
<rvba> roaksoax: so I guess we can fix maas-enlist then.
<roaksoax> rvba: http://paste.ubuntu.com/1084714/
<roaksoax> rvba: that's the fix
<roaksoax> rvba: thast';d be default
<rvba> roaksoax: that will use 0 which happens to be the default currently but if you simply remove that parameter, then MAAS' default will be used.
<roaksoax> rvba: I can do that, but, will it be useful sometime in the future?
<roaksoax> passing different commissioning option
<rvba> roaksoax: not sure about that, setting it to 0 is fine by me.
<roaksoax> rvba: anyways, I'm more concerned about the power_management stuff rather than that
<roaksoax> rvba: so what do we do about that? I think we should rename back to ipmi/ipmi_lan once cobbler is ditched
<roaksoax> rvba: and add the templates that can be later renamed too
<roaksoax> rvba: that's simple enough
<rvba> roaksoax: we could do that but I confess I'm concerned about the fact that this still uses cobbler's template.  That really is a gamble.
<roaksoax> rvba: i think it is not using cobbler template. robbiew confirmed maas is not powering on a machine, but cobbler is. which means maas seems to not be telling cobbler to power it on
<roaksoax> rvba: it is either, not send the power_type to be saved in cobbler, or send a power_type that cobbler support, hence the patch
<rvba> roaksoax: the error you pasted was about cobbler not recognising the power setting, so MAAS talks to cobbler.
<roaksoax> rvba: right, the problem is maas tells cobbler
<roaksoax> "
<roaksoax> "save these power options, and send power_type =ipmi"
<roaksoax> rvba: cobbler says "
<roaksoax> rvba: cobbler says "i don't know ipmi, but I have ipmitool ipmilan"
<roaksoax> rvba: that's why it fails, but when it comes to *power on* it is not using cobbler aparently
<rvba> roaksoax: right, that makes sense.
<roaksoax> rvba: when the power inteface was first developed, the power types were set to the same names cobbler supports. In our case, cobbler supports virsh, ether_wake, ipmitool, ipmilan
<rvba> roaksoax: I'm ok to approve the MP if it unblocks you, but we will need to work on that to get it properly working.
<roaksoax> rvba: so MAAS power_types were virsh and ether_wake, to *match* cobbler supported ones
<roaksoax> rvba: yes please. I'll start looking on it after I prepare a package update
<rvba> roaksoax: ok
<rvba> roaksoax: ~andreserl/maas/correct_power_methods will be landed shortly.  I tried to summarize our findings (well, your finding :) ) on the MP.
<roaksoax> rvba: awesome, thanks!
<rvba> roaksoax: thank *you* :)
<roaksoax> heh :)
<robbiew> RoAkSoAx: If you just wanna send me a patch to use the right cobbler template, I can roll with that....no need to do work that we have to undo once cobbler is removed
<rvba> roaksoax: don't forget to regenerate (manually for now) enums.js.
<roaksoax> robbiew: will do! I'll just try to fix everything to work right rather than have a temporary patch
<roaksoax> robbiew: will do ;)
<roaksoax> rvba: will do :)
<roaksoax> rvba: ah so the power stuff is using celery then
<rvba> roaksoax: yes, but we have only templates for virsh and ether_wake right now.
<roaksoax> rvba: yeah i'll take care of the ipmi ones then :)
<rvba> roaksoax: adding support for ipmi shouldn't be too complicated though.
<rvba> roaksoax: \o/
<rvba> roaksoax: note that we can do it really :)
<roaksoax> rvba: hehe no worries, I'll take care of it :)
<rvba> roaksoax: all right, thanks.  I need to go now but I'll review your branch(es) tomorrow (my) morning if you have branches up for review by then.
<roaksoax> rvba: will do, thanks
<roaksoax> robbiew: do you happen to have the output of the command "/usr/bin/ipmitool -H "$power_address" -U "$power_user" -P "$power_pass" power "$power_mode"" ?
<robbiew> RoAkSoAx: you mean run it with those variables filled in..or find that output in some sort of log
<roaksoax> robbiew: i'd like the output of the command if you replafce it with the real values
<roaksoax> i.e.
<roaksoax> > ipmitool -I lan -H 1.2.3.4 -f passfile chassis power status
<roaksoax> Chassis Power is on
<robbiew> ack
 * robbiew turns them off first
<robbiew> RoAkSoAx: http://pastebin.ubuntu.com/1084872/
<roaksoax> robbiew: what about if you pass the "status" option
<robbiew> I just turned it back off, so the status returned:  Chassis Power is off
<roaksoax> robbiew: ok cool thanks
<roaksoax> robbiew: so in maas are you using IPMI or IPMI LAN?
<robbiew> I was using IPMI LAN
<roaksoax> robbiew: alright cool. I almost have a patch for you
<robbiew> RoAkSoAx: okay, so I have to run to lunch...will be back in a little over an hour...then I'll have to break this stuff down and leave for Houston, but I'll try and test before
<robbiew> RoAkSoAx: just email me the patch or link to pastebin...just in case ;)
<roaksoax> robbiew: will do
 * roaksoax food
<allenap> roaksoax: Hi there. Any ideas about http://askubuntu.com/questions/159436/default-password-for-ubuntu-12-04-maas-image/160391? Lots of people seem to be having a similar problem, where their SSH keys are not being propagated to the nodes.
 * roaksoax looks
<roaksoax> allenap: seems like ssh keys were added *after node enlistment but i thought that bug didnt exist anymore*
<allenap> roaksoax: Do you mean enlistment, or allocation? I don't remember this bug :_-/
<allenap> That should have just been :-/ I haven't been in an accident today.
<roaksoax> allenap: can't remember TBH, or the keys have to be added before they get accepted after enlistment
<roaksoax> allenap: i'll have to test
<roaksoax> allenap: maybe the users accept & commission and then they add the users
<allenap> roaksoax: Ah, could be. So, maybe not a bug in the conventional sense, but a fairly major usability flaw. I'll talk about it with the other squaddies tomorrow morning. Thanks.
<roaksoax> allenap: cool. we';ll have to confirm though
<allenap> roaksoax: Also, lp:python-tx-tftp has imported.
<roaksoax> allenap: yeah I saw, I'll package it as soon as possible
<allenap> Awesome, thanks :)
<roaksoax> allenap: what's the license?
<allenap> roaksoax: MIT.
<roaksoax> allenap: coolt hanks
<roaksoax> allenap: you don't happen to have his email, do you?
<allenap> roaksoax: No, he won't give it up :) I've been communicating exclusively through issues and pull requests on GitHub.
<roaksoax> allenap: heh.. that's weird
<roaksoax> allenap: ahh dahh mark.lvov@gmail.com>
<allenap> roaksoax: Where did you find that?
<roaksoax> allenap: launchpad///
<roaksoax> allenap: 31. By shylent <mark.lvov@gmail.com> on 2012-07-02
<allenap> roaksoax: Hehe, tip top :)
<allenap> roaksoax: Have a good evening, I'm off now.
<roaksoax> allenap: you too
<robbiew> RoAkSoAx: hey...so I applied the patch as you suggested and restarted celery...nothing :/
<robbiew> should I try removing the machines, and adding freshly?
<roaksoax> robbiew: what's the output of /var/log/maas/celery.log?
<robbiew> http://pastebin.ubuntu.com/1085367/
<robbiew> RoAkSoAx:   ^
 * roaksoax looks
<roaksoax> robbiew: never seen that one before, and I don't see it in a newer version of the one I'm running. can you pastebin the whole log?
<robbiew> one sec
<roaksoax> robbiew: and can you also pastebin /etc/maas/celeryconfig.py and /etc/init/maas-celery.conf
<robbiew> http://pastebin.ubuntu.com/1085386/
<robbiew> celery.log
<robbiew> http://pastebin.ubuntu.com/1085387/
<robbiew> /etc/maas/celeryconfig.py
<robbiew> http://pastebin.ubuntu.com/1085388/
<robbiew> /etc/init/maas-celery.conf
<robbiew> RoAkSoAx: there ya go!
<roaksoax> robbiew: can you add this "env PYTHONPATH="/usr/share/maas/" to /etc/init/maas-celery.conf right before the "exec"? should look like:http://paste.ubuntu.com/1085390/
<roaksoax> robbiew: that's already fixed and I'm preparing an update
<robbiew> done
<roaksoax> robbiew: so then would be "sudo service maas-celery restart"
<roaksoax> robbiew: and pastebin /var/log/maas/celery.log again please
<robbiew> http://pastebin.ubuntu.com/1085393/
<roaksoax> robbiew: ok it should work now
 * robbiew is waiting for bootstrap to complete
<robbiew> :)
<robbiew> will try soon
<roaksoax> alright cool, in the meantime I'l finish preparing the update
<robbiew> RoAkSoAx: http://pastebin.ubuntu.com/1085403/
<robbiew> failed :/
 * roaksoax looks
<roaksoax> robbiew: ok, so what if the ipmilan.template gets modified like this> http://paste.ubuntu.com/1085418/ (it would require restart of maas-celery maas-provision and apache2)
<robbiew> oh wait...power_id is supposed to be the IP address?
<robbiew> I thought it was the user id number
<roaksoax> robbiew: the IP address
<robbiew> ffs
<roaksoax> robbiew: that might indeed be the cause of the failure
<roaksoax> robbiew: I'm fixing that too cause the names are bias
<robbiew> so yeah...I was wondering how the IP was determined...I assumed MAAS provided it based on the hostname lookup
<roaksoax> it is actually the first time i'm looking at this so it clearly needs lots of things to get improved
<robbiew> no worries
<robbiew> me too :)
<roaksoax> hehe :)
<robbiew> but given MAAS knows the hostname
<robbiew> oh wait
<robbiew> nevermind
<robbiew> IPMI IP address != hostname
 * robbiew has to go to team dinner...I'll shoot you an email with the results of ip address change
<roaksoax> robbiew: alright, cool, and if that doesn't work try the minimized template :)
<robbiew> heh
#maas 2012-07-11
<roaksoax> Daviey: stil around?
 * roaksoax dinner
<robbiew> RoAkSoAx: bingo!...put in the hostname for "User ID" and worked like magic ;)
<Daviey> roaksoax: hey
<javor> Hi. I trying to install MAAS onto Virtualbox. I did everything what i should (i guess) but doing juju bootstrap just show me error 409. Anybody has it installed and its works good (onto virtualbox)?
<roaksoax> Daviey: checking
<roaksoax> rvba: howdy!! I have the power stuff I just haven't proposed a branch yet as I wanna test it first with real ipmi cards, even though, robbiew confirmed it worked
<rvba> roaksoax: that's great news!
<roaksoax> rvba: what's the democeleryconfig.py for?
<rvba> roaksoax: the celery config used in dev mode.
<rvba> i.e., when running MAAS directly from the tree.
<roaksoax> rvba: and is services/celeryd/run also par of dev mode?
<rvba> Yes.
<roaksoax> ok, just checking before I package something up :)
<rvba> That's how we start the services in dev mode, that uses 'supervise'.
<roaksoax> rvba: oh btw.. I wanted to ask you, how can I effectively determine/check/test that the templates are being rendered correctly. Where can I see a similar output of passing -x to shell
<rvba> roaksoax: it's only interesting for you (as far as packaging is concerned) as an example about how we start the services in a dev environment.
<rvba> roaksoax: I assume you want to test the new power templates... then I think you should add tests in there ./src/provisioningserver/power/tests/test_poweraction.py
<roaksoax> rvba: yes want to test them, but want to see the output of the rendering
<rvba> roaksoax: have a look at the last tests in this file.
<rvba> roaksoax: test_virsh_checks_vm_state
<roaksoax> rvba: right, but is there no way to actually see how it is being rendered?
<roaksoax> rvba: becuase the error messages received are not helpful at all
<rvba> roaksoax: action = PowerAction(POWER_TYPE.VIRSH) / script = action.render_template(...)
<rvba> roaksoax: ^ isn't what you're looking for?
<roaksoax> rvba:that's the same output being placed on the logs, isn't it?
<roaksoax> on celery.log when something fails
<rvba> I /think/ you see the full stacktrace in celery.log when something fails.
<roaksoax> rvba: http://pastebin.ubuntu.com/1086195/
<roaksoax> rvba: you see a stack strace but you don't see rendered output or failure
<roaksoax> rvba: what I want to see is if the variables have been rendered correctly and things like that
<roaksoax> rvba: similar to placing -x on a shell script
<roaksoax> either way, the template is shell and we should eb able to see how it gets rendered right?
<rvba> roaksoax: that error means we had an error running the generated script.  Thee rendering went fine, otherwise you would have gotten a perfectly clear error about the missing variable.
<rvba> s/Thee/The/
<roaksoax> rvba: yes, but while the rendering might not have had any errors, I don't know whether the variables ended up with a value, and then passed empty values to the command, which made it fail
<roaksoax> rvba: so the command might have failed because it had empty arguments
<roaksoax> rvba: thta's what I wanna test
<rvba> roaksoax: fair enough.
<rvba> roaksoax: http://paste.ubuntu.com/1086199/
<rvba> roaksoax: that's the code that generate this error... there is a TODO there :)
<roaksoax> yeah
<rvba> roaksoax: I could add the generated script in the error log.
<roaksoax> rvba: but anyways, regardless of that being in place in tehe code, isn't there a manual way to test it?
<rvba> roaksoax: you can manually do this http://paste.ubuntu.com/1086200/ to see the rendered script in the error log
<roaksoax> rvba: more than just the rendered script, isn't it possible to see the output of it as if it was passed the "-x" (cause it is a shell script at the end of the day_
<roaksoax> rvba: cool, Ill try that
<rvba> roaksoax: what does "-x" do exactly?
<rvba> (I think I asked that question before but I don't remember the answer...)
<rvba> roaksoax: maybe I forgot to mention that this is a change to run_shell in ./src/provisioningserver/power/poweraction.py.
<rvba> roaksoax: also, in that method, 'subprocess.Popen' is what calls the script, you could probably add "-x" in there.
<roaksoax> rvba: ok cool. I'lll look into that
<roaksoax> rvba: btw.. does this make sense to you? http://paste.ubuntu.com/1086214/
<roaksoax> rvba: since those are UI changes mostly, I just wanna make sure it makes sense
<rvba> roaksoax: you're also changing the parameters for ipmi_lan.
<roaksoax> rvba: yeah
<roaksoax> that's why I said mostly :)
<rvba> roaksoax: but yeah, the UI changes make sense.
<rvba> roaksoax: I'm trying to find where I took the list of the parameters from.
<roaksoax> rvba: from cobbler: /usr/bin/ipmitool -H "$power_address" -U "$power_user" -P "$power_pass" power "$power_mode"
<rvba> roaksoax: right, so, did I got it wrong for ipmi_lan ?
<roaksoax> rvba: for for ipmilan you simply add -I lan
<rvba> roaksoax: anyway, I'll trust you on this one :).
<roaksoax> rvba: hehe :)
<czajkowski> Daviey: I have 2  server questions that need to be answered, can you recommend someone on the server team who could help out please?
<roaksoax> czajkowski: what are the questions
<czajkowski> roaksoax: http://askubuntu.com/questions/160198/openstack-dashboard-access-after-installing-w-maas  and http://askubuntu.com/questions/157717/can-i-provision-a-maas-node-with-an-arbitrary-install-image
<roaksoax> czajkowski: so 1. goes for adam_g
<roaksoax> adam_g: http://askubuntu.com/questions/160198/openstack-dashboard-access-after-installing-w-maas
<roaksoax> rvba: support for quantal in MAAS is not yet ready right?
<rvba> roaksoax: no, right now, precise is hardcoded.
<roaksoax> rvba: ok
<roaksoax> allenap: I tested the ssh keys with one of the latest maas revs and everything works as expected
<roaksoax> allenap: 1. after enlist before commissioning. 2. after clicking on commissioning but before it actually commissions. 3. afgter commissioning, before deploying (After having it allocated to admin)
<roaksoax> allenap: so the issue might be related to the fact that a machine was never allocated to the admin or a user before it was deployed?
<allenap> roaksoax: I'm not sure that's possible... or I think it should not be. rvba?
<roaksoax> allenap: maybe they started the machine when in "Ready" state, without clicking manually on MAAS to start a node maybe?
<allenap> roaksoax: Possibly. Cobbler could well be in the right state to just install the machine.
<roaksoax> yep
<roaksoax> that's what I'm thinking
<rvba> allenap: the 'acquire' step makes the node the property of the user requesting a node for deployment.
<rvba> So it's not possible for a node to be deployed without having an owner.
<czajkowski> roaksoax: THANKS
<czajkowski> damn caps sorry.
<roaksoax> rvba: right, but after the node is ready, it has no owner, however if you click on "Start Node" it allocates it to the user
<roaksoax> rvba: so maybe users were manually turning on nodes before they were manually allocated with "Start Node" on the WebUI
<roaksoax> ending with no keys
<rvba> roaksoax: that seems possible indeed.  But the node were definitely powered up outside of MAAS control.
<rvba> nodes*
<allenap> We might be able to address that by ensuring that netboot_enabled is off when the node is in the ready pool.
<roaksoax> indeed
<allenap> However, even that's not 100%. A node that was once allocated and returned to the pool is not wiped, so turning netboot off just means it'll boot into the previous OS.
 * allenap thinks we *really* ought to wipe machines that are deallocated.
<roaksoax> allenap: that might not be a good idea
<roaksoax> you might one to deallocate a machine from the pool
<roaksoax> allenap: but keep everything installed for some reason
<roaksoax> allenap: either way, from deallocation back to ready, shouldn;t be a problem, cause once is allocated again, you would wipe the intsllation
<roaksoax> allenap: rvba btw.. there's no way to get an allocated node back to the pool from the WebUI right?
<allenap> roaksoax: I'm thinking also about data security. It may be a requirement that the disks are wiped, though I guess that's another story.
<roaksoax> yeah
<roaksoax> allenap: so if in the WEbUI i click on "Start Node", I'm only presented with a  "Delete" button, right? SO that means there's no way to bring it back to the pool
<roaksoax> such as "Stop Node"
<roaksoax> that powers it off and allocates it back to the pool
<allenap> roaksoax: Really? Gulp.
<roaksoax> allenap: last I check it was like that
<roaksoax> anyway, I'll finish up with releasing a new maas and recheck
<allenap> rvba: Do you know if we did any work on node deallocation?
<rvba> allenap: I don't think we did.
<roaksoax> allenap: there's no config for python-txtftp yet right?
<roaksoax> btw there's a broken symlink on trunk, in etc/ named -> ../run/named
<rvba> roaksoax: that's normal, ../run/named gets populated when the conf is created.
<roaksoax> rvba: ok, but that means shipping a broken link
<roaksoax> rvba: that should be clean IMHO
<rvba> roaksoax: 'make services/dns/@run' will populate it for instance.
<roaksoax> rvba: right, but that should be created on make rather than shipping a broken link on trunk... you shouldn't be shipping a link on trunk
<allenap> roaksoax: Yes, etc/pserv.yaml. It should Just Work for now, though not on the right port I think.
<rvba> roaksoax: why do you want to ship it?  I thought you'd ship only so selected files from etc/ ?
<rvba> s/so/some/
<roaksoax> allenap: right but that's started by pserv, not by twistd tftp :)
<roaksoax> rvba: it still in the source
<roaksoax> rvba: i ship selected files from binary while it is still in the source
<allenap> roaksoax: Yes, don't run twistd tftp :)
<roaksoax> allenap: ok then :)
<allenap> roaksoax: It's okay for it to be there, just don't arrange for it to start by default or anything.
<roaksoax> allenap: so I'll just install it then in PYTHONPATH
<allenap> roaksoax: Yeah, that's all we need.
<roaksoax> allenap: was wondering to see whether I ship add an upstart job or not
<allenap> roaksoax: No, sorry about that. I can sense you were excited at the prospect ;)
<rvba> roaksoax: I can create that link when running make indeed.  But why exactly do you think a broken link is that bad?
<roaksoax> allenap: hehe i just wanna get it over with :)
<roaksoax> rvba: AFAIK it is a bad idea to ship broken links on source tarballs
<roaksoax> rvba: i'm fine shipping it, I just think it would be better to have it generated and cleaned on make
<rvba> roaksoax: I definitely can do that (but I'd be happy to learn why it's so bad to ship broken links ;) ).
<rvba> Apart from the fact that the word 'broken' sounds bad in itself :).
<roaksoax> rvba: IMHO becuase it is prone to failure when it comes to builds. On the other hand, It creates a few issues wth tar I think
<roaksoax> when setting mtime or mode
<rvba> roaksoax: fair enough, I'll do it ;).
<rvba> roaksoax: fwiw that link is only there because we wanted to make clear that the config was generated.
<rvba> We could have generated the config directly in /etc/named but that would have been confusing.
<rvba> err etc/named
<roaksoax> rvba: right but you could add a message header saying its generated :)
<roaksoax> cause either way, that doesn't show on bzr, does it?
<rvba> roaksoax: run/* is ignored by bzr.  The link was committed in bzr.
<roaksoax> rvba: right, so you could also ignore etc/named and not commit it
<rvba> roaksoax: sure, but that would be a little bit weird.
<roaksoax> rvba: might be indeed...  but that file gets created and removed on distclean
<roaksoax> so it doesn't really belong to the branch
<roaksoax> IMHO
<rvba> True, it's just a bit confusing to have it in etc/named.  But I'll consider that.
<rvba> I mean I'll consider generating the config in etc/named directly.
<roaksoax> rvba: alright! I'm happy with whichever makes your life easier, though shipping the symlink is also weird for me!
<roaksoax> rvba: and I'm sure the MIR team would be "WTH is there a broken symlink in the code"
<rvba> roaksoax: all right :)
<roaksoax> :)
<roaksoax> rvba: thanks though!
<roaksoax> allenap: there seems to be an error in pserv
<roaksoax> after adding the config option for tftp
<roaksoax> allenap: yep, pserv doesn't start
<allenap> Oh rats.
<allenap> roaksoax: Can you grab the logs?
<roaksoax> allenap: there's no pserv log
<allenap> <surprised smiley>
<allenap> roaksoax: Ah, is this with the new python-tx-tftp package?
<roaksoax> allenap: yes
<roaksoax> allenap: no longer showed in: http://pastebin.ubuntu.com/1086510/
<roaksoax> allenap: but the file is installed as twisted pluging
<allenap> roaksoax: Okay, I forgot about this. The upstream, shylent, has reviewed most of my recent changes (favourably) but has not pulled them into his branch. I'll prod him about it.
<roaksoax> allenap: can you give me a patch
<allenap> Sure.
<allenap> roaksoax: http://paste.ubuntu.com/1086512/
<roaksoax> allenap: /usr/bin/twistd: Unknown command: maas-pserv
<roaksoax> allenap: is twisted not recognizing maas-pserv installed/present/available when it is installed in the right place
<allenap> roaksoax: I changed the pserv plugin code so that it wouldn't spew errors when it failed to initialise. It probably can't import something from python-tx-tftp and is breaking. When that patch is in place it /ought/ to work again.
<roaksoax> allenap: is not
<roaksoax> allenap: i patched it in /usr/share/pyshared/tftp/
<allenap> roaksoax: Okay, you could try adding a `raise` to the maas-pserv twisted plugin, so that the error is not suppressed.
<allenap> roaksoax: Unfortunately I have to go now :-/ Good luck in the meantime. Email the list if this is still not working at your EOD and we'll (red squad) take a look.
<roaksoax> rvba: does provisioning server and stuff add /usr/share/maas as part of the path?
<roaksoax> rvba: i'm having a pserv error due to apparently not being able to import
<roaksoax> rvba: http://pastebin.ubuntu.com/1086581/
#maas 2012-07-12
<jtv> Does anyone know what goes wrong in juju here, and how it might relate to MAAS?  I'm completely lost in juju-land.  http://askubuntu.com/questions/162255/does-juju-really-need-two-nodes
<rvba> roaksoax: the provisioning server doesn't add /usr/share/maas to the path.  Can you modify the PYTHONPATH before you run that command?
<allenap> rvba: Did you say that you'd had success with http://marcoceppi.com/2012/05/juju-maas-virtualbox/?
<rvba> allenap: no, I said it looked promising that's all :).
<marcoceppi> It's not the best way to experience MaaS unfortunately
<allenap> marcoceppi: Shamefully I haven't read it yet. I'm trying to help out with https://answers.launchpad.net/maas/+question/202414, but I don't have time (none of us do really) to try and reproduce the problem.
<marcoceppi> IMO The best way to test MaaS is to just spin up the OpenStack DevScript thing. VirtualBox -> OpenStack (physical hardware) differs in experience
<marcoceppi> rather, test MaaS prior to production deployment
<hazmat> is there any intent that maas supports additional constraints for 12.10?
<hazmat> re juju provider constraints
<hazmat> flacoste, Daviey ^
<roaksoax> rvba: howdy.. yeah I eventually figured it out :)
<roaksoax> jtv: juju requires a bootstrap node.. I guess smoser already clarified it for you
<smoser> roaksoax is up early.
<roaksoax> smoser: heh yeah :)
<jtv> roaksoax: never mind â I had to punt the question.
<roaksoax> jtv: hehe ok :)
<roaksoax> rvba: did you submit a patch for that?
<rvba> roaksoax: for what? The PYTHONPATH thingy?
<roaksoax> rvba: yeah
<rvba> roaksoax: no I didn't.
<roaksoax> rvba: where would be the best place to add it?
<roaksoax> rvba: cause it seems it fails for the tftp stuff but doesn't fail for anything else
<rvba> roaksoax: it should be done where the packages run that twisted thingy I think.
<rvba> package*
<roaksoax> allenap: could you please take care of that ^^ since you better understand this part of the code :)
<rvba> roaksoax: allenap will know better indeed.  But to me it looks like a packaging question.  I mean something that the package' script should set before running the daemon.
<roaksoax> rvba: right, so what worries me is that right before the tftp stuff was added, we didn't see celeryconfig import errors. As there is lots of other stuff that uses celeryconfig, such as the power stuff
<roaksoax> rvba: so this shouldn't not be failing to import celeryconfig
<roaksoax> err s/shouldn't not/shouldn't/
<rvba> roaksoax: but that's a new daemon so it seems normal to tweak PYTHONPATH before running it, same as what you've done before running celeryd.
<roaksoax> rvba: right but that daemon is run by pserv itself
<roaksoax> rvba: and, correct me if I'm wrong, that daemon being run inside shouldn't it have the path already available?
<rvba> roaksoax: well, pserv didn't have any dependency on celeryconfig previously.  Now it does because of the tftp stuff.
<roaksoax> rvba: right, but my point being is that pserv also handles the power stuff too right? which means it imports celeryconfig and doesn't fail
<rvba> roaksoax: no, the power stuff is handled by celeryd.
<rvba> MAAS talks to celeryd to run the power-related celery tasks.
<roaksoax> rvba: right, so my point being is this: http://pastebin.ubuntu.com/1087834/
<roaksoax> rvba: so If I understand correctly, you are saying that celery handles the power, while ftp is a daemon started by pserv?
<rvba> roaksoax: allenap will confirm this (he's the only one who's worked on tftp so far) but yes, that's what I think.
<roaksoax> rvba: there's no variable that contains /usr/share/maas right?
<rvba> roaksoax: definitely not.
<roaksoax> rvba: so this should be the fix: http://paste.ubuntu.com/1087846/ right?
<rvba> Only the packaging knows that thing will end up in /usr/share/maas.
<roaksoax> rvba: unless we have a varilable that defaults to it :)
<rvba> roaksoax: I think that this path modification operation should be done right before the process is started rather that in the code itself.
<rvba> roaksoax: It's the job of the caller to make sure that all the required stuff are present on the path.
<roaksoax> rvba: i think differently. I think if the daemon is run (pserv), everything that runs under it should know where the stuff it needs is located
<roaksoax> rvba: i should not need to tell it before running the daemon
<roaksoax> rvba: as in, this daemon should know where to look
<rvba> roaksoax: my point is that where things are located depends on the environment (dev environment, prod environment).  The process which runs the daemon has all the information to set up the environment properly.  It would duplicate the work to have the daemon itself try to guess where things it needs are location.
<rvba> located*
<roaksoax> rvba: I agree that it depends on the environment, however, even in such environments, we should not need to manually tell it the PATHS, but rather it should be automatically determined IMHO
<roaksoax> smoser: how would you handle something like this ^^
<rvba> roaksoax: look how we've done with the wsgi stuff: the caller (the wsgi script) was in charge of setting up the path.
 * smoser reads.
<roaksoax> rvba: i agree, but in this case you are starting a daemon under python itself, it does not have its own daemon
<roaksoax> rvba: that being said, given that that daemon is understed under another, then it should be able to know where everything is
<roaksoax> rvba: so for me it can be seen as a regression
<rvba> roaksoax: unless we didn't make celeryconfig.py available to pserv.  Because previously we didn't need to do that.  Now we do.
<roaksoax> rvba: right, so we need to make sure celery config is available for everyone that uses it without having to manually set the path
<roaksoax> rvba: it should rely on a place where everybody can use it, because that's the way how it is being used
<rvba> roaksoax: same as django's config, that contains MAAS specific information and should not be on the general path, it should only be added to the PYTHONPATH before we run pserv (or celeryd, but we already do that).
<roaksoax> rvba: what we do with celery, telling the pythonpath on upstart is a hack IMHO. Now, src/provisioningserver/tftp.py is the twisted app that needs to know where celeryd, so it is there where the path should be added
<roaksoax> rvba: at the end of the day, the thing is if someone installs from source, such as python setup.py install the app should be working without having to provide hacks for it
<roaksoax> rvba: so there should probably be a setting that tells where celeryconfig is
<smoser> i don't really understand the problem above completely. but in general, i think its better to have config (or command line arguments) to an application to tell it where stuff is.
<smoser> i really dont like relying on PYTHONPATH
<smoser> as environment is hard to manage (as it by default is inherited across forks)
<smoser> but again, i dont really understand the detail. bug something like http://paste.ubuntu.com/1087846/ doesn't seem like a general program.  it seems like part of maas.
<rvba> smoser: so you agree that the caller should pass on the configuration information.  Rather than having the code try to guess where things are.
<rvba> Whether we use PYTHONPATH or not is another story.
<roaksoax> rvba: so yes I agree there should be asetting for that. I also think it should try to determine where it relies automatically
<roaksoax> rvba: in the case of wsgi.py, that is seen as a config file
<roaksoax> rvba: i have seen wsgi.py files trying to guess where the PATH is
<roaksoax> rvba: so if the setting is empty, there should be either a default, or a way to try to determine it automatically
<roaksoax> rvba: based on known install locations
<rvba> roaksoax: I confess that seems much more complex and error-prone than having the caller (which knows everything about the environment) pass on the right config or set up the right PYTHONPATH.
<rvba> And let me add that it's what we've done so far: wsgi.py, the prod caller script, set it up with the prod path.
<roaksoax> rvba: right, but in this the caller script is maasps.py
<rvba> The dev script (services/webapp/run) set up it up with the dev PYTHONPATH
<rvba> sets*
<smoser> if we can, yeah, it makes sense to have default configs. and ideally an installed application isn't completely broken.
<smoser> and one installed by ubuntu should not have to be told where it is installed to
<smoser> (so that part of "automatic" i agree with)
<rvba> It doesn't make sense to me to hard code platform-specific path in the code itself.  But I'm no expert so I'm ok to be told to do otherwise.
<roaksoax> rvba: so could pserv.yaml contain this information then?
<jtv> I'm off, people.  See you tomorrow!
<roaksoax> rvba: but that's what happens in all software I've seen so far, you "hardcode" a location, but if a different installation location is selected, the software should know where it is
<rvba> roaksoax: that would work, because there is a pserv.yaml for the prod environment and another one for the dev environment.
<roaksoax> rvba: example of this is installing between different distributions. Some software might default to /usr/local/lib in RHEL for example, and in ubuntu we use /usr/lib/. So that software needs to know where its stuff ended up installing
<rvba> roaksoax: exactly, so something outside of the software should tell it where things are.  It's not the responsability of the software to try to guess the possible locations.
<roaksoax> rvba: I agree
<roaksoax> rvba: but IMHO, this case is different because its being run under PYTHONPATH "importing" a "python module"
<rvba> roaksoax: right, I admit that's a bit special.
<roaksoax> rvba: so we are in agreement then. I'd say pserv.yaml would probably be the best place to "change" the installation path then
<rvba> roaksoax: let's wait for allenap to come back and see what he thinks about that.  He's the one who decided to call the tftp stuff from within the code.
<roaksoax> rvba: ok
<allenap> Okay, what's up?
<rvba> roaksoax: that makes sense, although I would still prefer to have those path modifications made by the process launching the initial process.
<allenap> Shall I just read the scrollback?
<rvba> allenap: yes
 * rvba grabs a bite.
<roaksoax> rvba: right, that would be telling upstart where pythonpath is
<rvba> roaksoax: yep.
<roaksoax> rvba: which I certainly trying to avoid
<rvba> roaksoax: I can see that :)
<roaksoax> rvba: cause it really is a hack
<roaksoax> rvba: in the case of celery is a must do
<rvba> roaksoax: may I ask why this is considered a hack?
<roaksoax> rvba: I think that the daemon should run, and if it does not find a config, it should fail
<roaksoax> rvba: celeryd imports a config as running a python script, which makes us tell it where the config is
<roaksoax> the bad things is that we have to tweak the pythonpath
<roaksoax> in order for it to work
<roaksoax> we shouldn't really need to tweak it, but rather simply tell it where the config is
<rvba> roaksoax: indeed, but it seems to be rather common for python-based software to use python modules as configuration files (see Django, celery).
<roaksoax> rvba: it does, but nobody is perfect :)
<rvba> roaksoax: and that doesn't tell me why it's bad to tweak the pythonpath.  Where tweak = add one item to it to tell the software where it's config is.
<rvba> s/it's/its/
<rvba> Changing the pythonpath like this, in the context of a specific process seems pretty benign to me.
<rvba> But maybe I'm missing the big picture.
<roaksoax> rvba: but yeah, from my personal point of view, having to tweak pythonpath for it to find the config, is a hack. It would be much simpler to tell where a config is, such as yaml, and let celery code import tha varilables and make then available ... I however, don't know anmythjing about celery so I wouldn't know why they preferred doing it that way
<roaksoax> rvba: so, from my point of view, telling where pythonpath is similar to running a chroot
<roaksoax> or to running an applicaion in a chroot,
<roaksoax> but we are obviuoulsy not doing so
<rvba> roaksoax: agreed, using flat files (a la yaml) would be more clean.  But since we're dealing with framework which use python modules to store configuration options, we have to adapt to the way they work and tweak the pythonpath.
<roaksoax> rvba: indeed
<rvba> frameworks* even (Django + Celery)
<roaksoax> rvba: right, but in django, we basically tell wsgi where to start from where almost everything is is publicly available in pythonpath
<roaksoax> rvba: from "within" the application
<roaksoax> rvba: so we are adding a path for that particular "instance"
<roaksoax> rvba: while in celery, we are doing it "externally", from the upstart job
<rvba> I don't consider wsgi.py to be part of the application, it's really the equivalent of an upstart job from within apache.
<rvba> roaksoax: isn't an upstart job also a particular "instance"?
<smoser> rvba, if i was looking to grab maas trunk and try to use it
<smoser> is there any doc that covers that?
<smoser> i'll just run it on an instance, so i dont care if i have to install stuff as root or whatever, just want to get the full path working as much as possible.
<roaksoax> smoser: i have quantal maas working
<roaksoax> smoser: you should be able to use it. I'm looking to update it today after this stuff gets fixed
<rvba> smoser: that's really something that is unsupported, untested and undocumented.  The only way to run MAAS from source is to run what we call the dev instance, with local services and a test database but you won't be able to deal with real nodes.
<roaksoax> rvba: it is too
<smoser> rvba, ok. thats fine, but at least please realize that you just said "running this code is unsupported, untested and undocumented"
<smoser> i literally laughed out loud. and i try not to do that on irc.
<rvba> smoser: no, that's not what I said.
<rvba> smoser: I'm sure there is a way to do that but it will require fiddling with the config a bit.  But we've always used the packaged version of MAAS to try things out with real nodes.
<czajkowski> if anyone can help the user who has asked a question on AU that would be great. http://askubuntu.com/questions/162255/does-juju-really-need-two-nodes
<rvba> smoser: we've designed the dev environment to be completely isolated from the rest of the system, so it's contradictory with actually dealing with real nodes.
<roaksoax> allenap: any thoughts?
<allenap> roaksoax: I was otp; I'm just reading the scrollback now... and there's a *lot* of it.
<roaksoax> heheh
<roaksoax> rvba: where is it that twistd logged by default?
<allenap> roaksoax, rvba: I haven't read everything, but... the tftp server (pserv as a whole) doesn't need access to the celeryconfig module. We should move the config out of that file. I just did it that way because it was already there.
<allenap> Personally I *hate* celeryconfig and DJANGO_SETTINGS_MODULE, but we have to live with the things.
<allenap> I would like to define things like TFTPPATH in pserv.yaml, or a more general maas.yaml (does not exist), and then these config module aberrations can pull the config in from there.
<roaksoax> allenap: so tftppath.py will not import celeryconfig then?
<roaksoax> in the future?
<allenap> Also, pserv is all about Cobbler and, now, TFTP. The Cobbler stuff will go, and pserv will simply be a container for the TFTP server. We can also use it to host other Twisted services, but there aren't any others that need it right now.
<allenap> roaksoax: No, we should get rid of that.
<roaksoax> allenap: ok, that's what I was asking :). Now, if pserv is in place, I think the tftproot should rely in pserv.yaml
<roaksoax> the config option
<allenap> celeryconfig *should* die, but celeryd needs it. IMO, we should put only enough in there for celeryd to start, then put MAAS specific config elsewhere.
<allenap> roaksoax: Agreed.
<allenap> roaksoax: I'll fix that now; I assume it's blocking you?
<roaksoax> allenap: I'm gonna provide a temporary patch for it to work now, but will remove once your fix is in trunk :)
<allenap> Cool.
 * allenap gives up hope of doing QA today ;)
<roaksoax> rvba: btw.. I think we can ditch 1 of the IPMI options from the UI and just keep IPMI lan
<rvba> roaksoax: I've got no problem with that.  As you know, they were simply stolen from cobbler.  If there is a good reason to merge two of the options into one, I'm fine with it.
<roaksoax> rvba: ok cool :) I'll re-verify (not an easy task with no ipmi devices to play with_
<roaksoax> Daviey: do we have any lab with IPMI that I can play with?
<roaksoax> err
<roaksoax> rvba: so what do you think so far?
<roaksoax> rvba: http://paste.ubuntu.com/1088010/
<roaksoax> robbiew: howdy!! so ipmi worked like a charm then... was it using the fulll template or the minimized one?
<rvba> roaksoax: I need to step out bit a bit, I'll have a look when I'll be back... in ~40 minutes.
<roaksoax> sure thanks!
<robbiew> RoAkSoAx: full
<robbiew> but they didn't shutdown on a terminate-environment
<robbiew> whoops...destroy-environment
<roaksoax> robbiew: alright! I'll look into that
<robbiew> cool
<rvba> robbiew: I'm back.  That pastebin looks good to me.  I can give you a hand with writing the tests if you want.
<rvba> err, roaksoax
<robbiew> lol
<rvba> :)
<robbiew> too many r's
<rvba> yep
<roaksoax> rvba: i already wrote them, they seem to "work" :)
<roaksoax> but sure
<roaksoax> rvba: ok so in cobbler ipmilan uses fence_ipmilan while ipmi uses ipmitool directly
<roaksoax> rvba: fence_ipmilan requires ipmitool
<roaksoax> rvba: so I guess we could just stay with ipmitool
<rvba> roaksoax: do you know what fence_ipmilan adds to ipmitool?
<rvba> (I'm just curious)
<roaksoax> rvba: that's what I'm actually looking for
<roaksoax> rvba: i'm guessing it was just created to be used in RHCS, isntead of using ipmitool directly
<roaksoax> rvba: i don't think it adds anything significant
<roaksoax> rvba: i, however, am thinking that we might need to add a box too allow sending extra commands
<roaksoax> allenap: still around?
<allenap> roaksoax: Just back. What's up?
<roaksoax> allenap: i forgot :)
<allenap> Haha :)
<roaksoax> allenap: still around? I remembered :)
<roaksoax> allenap: so I won't forget... did the maintainer pulled your changes yet?
<roaksoax> python-tx-tftp
#maas 2012-07-13
<allenap> roaksoax: I doubt you're there, but you can get this later. No, he hasn't pulled the changes yet, but he did review some additional parts last night. I have a small amount of work to do to satisfy that, then he'll pull. Should be done today or by the beginning of next week at the latest.
<roaksoax> allenap: hehe alright, either way it is not usable
<roaksoax> yet
<roaksoax> allenap: let me know when you ditch the celeryconfig stuff
<roaksoax> rvba: howdy! so I figured it the ipmi stuff out
<roaksoax> rvba: the difference is the interface being in use
<allenap> roaksoax: Will do. It's actually requiring (in my head at least) quite a lot of change.
<roaksoax> ipmitool uses the OpenIPMI interface, while ipmilan uses fence_ipmilan which uses ipmitool's lan interface
<roaksoax> (besides the fact of course fence_ipmilan was created for clustering)
<roaksoax> allenap: ehe ok, just make sure it lands upstream before FF
<roaksoax> allenap: if not, we can just patch our source
<allenap> roaksoax: When is FF?
<roaksoax> rvba: Feature Freeze (/me just remembered you guys are not bound by the Ubuntu Release Schedule :) )
<rvba> roaksoax: do we want to keep the two power methods then?
<roaksoax> rvba: so my idea is this. (1.) 3 IPMI options, IPMI, IPMI-LAN, IPMI-LANPLUS, or (2.) 1 IPMI option, that has "Interface" option and is a combobox, or (3.) Interface is a text box,
<roaksoax> rvba: this obviously means that choosing the interface means adding additional parameters to the command
<rvba> roaksoax: then I would very much be in favor or 1.
<rvba> s/or/of/
<allenap> rvba: Tests pass.
<rvba> allenap: thanks.
<roaksoax> rvba: (2.) is IPMI Power Method, which as Interface Combobox with "OpenIPMI" "LAN" "LANPLUS"
<rvba> roaksoax: I mean it would require some JS code if we wanted to have different parameters depending on the value on the value of a combo box
<roaksoax> rvba: right, so we 1. duplicate template files (which will only differ on ~10 words - -I opne, -I lan, -I lanplus)
<roaksoax> or we add the different parameters
<roaksoax> some other way
<roaksoax> rvba: cause I think it makes no sense to duplicate the template file
<roaksoax> rvba: cause if that's so, then a textbox would be easier
<rvba> roaksoax: no need to duplicate the templates, we could use the inheritance feature of tempita.
<roaksoax> rvba: cool, can you give me an example of how this would be done?
<rvba> roaksoax: sure, hold on.
<rvba> roaksoax: so, here are your 3 templates: master (http://paste.ubuntu.com/1089798/), specific1 (http://paste.ubuntu.com/1089799/) and specific2 (http://paste.ubuntu.com/1089800/).
<rvba> roaksoax: if you render 'specific1' you'll get: http://paste.ubuntu.com/1089802/
<roaksoax> rvba: ok cool, I'll get it done and forward it your way for review
<roaksoax> thanks!
<rvba> roaksoax: cool
<roaksoax> rvba: how is the master referenced in the inherit? I'm guessing by telling it the path?
<rvba> roaksoax: yes
<roaksoax> rvba: and how does tempita now the path for the ttemplates?
<rvba> roaksoax: you can have a look at src/maasserver/preseed.py:load_preseed_template.  That's what we've done for the preseed templates which also uses 'inherit'.
<roaksoax> rvba: so I just realized we do not need the complexion of inheritance
<roaksoax> rvba: the only reason why we have various files is to satisfy cobbler, but since that's gonna be gone, we can just pass a parameter
<roaksoax> rvba: src/maasserver/power_parameters.py is only a UI thing right? I couldn't set a power_interface parameter there that would not shown on the UI, but would set a default when that parameter is selected
<rvba> roaksoax: it is a UI thing yes. (I'm otp btw.)
<Daviey> hola!
<roaksoax> Daviey: howdy! have you played with IPMI much?
<Daviey> roaksoax: yep
<roaksoax> Daviey: so doing ipmitool -H 1.1.1.1 -U a -P a power on is the same as doing ipmitool -I lan -H 1.1.1.1 <...etc>
<roaksoax> right?
<roaksoax> Daviey: for on/off/status commands does it make a difference using -I lan or -I lanplus?
<Daviey> roaksoax: err, no user / pass?
<Daviey> no.. but i tend to use lanplus for everything
<Daviey> another more complete alias is also chassis power on.
<roaksoax> Daviey: i'm just trying to figure out whether in MAAS there should only be 1 IPMI command, or IPMI, IPMI-LAN and IPMI-LANPLUS
<roaksoax> IPMI = ipmitool -H 1.2.3.4 -U a -P a chassis power <on/off>.
<roaksoax> IPMI-LAN = ipmitool -I lan -H 1.2.3.4 -U a -P a chassis power <on/off>
<roaksoax> IPMI-LANPLUS = ipmitool -I lanplus -H 1.2.3.4 -U a -P a chassis power <on/off>
<roaksoax> Daviey: does that make sense, or you think is not really necessary?
<Daviey> roaksoax: i don't think it really matters tbh
<Daviey> roaksoax: as i say, i've used lanplus for everything i think.. If that turns out to be an issue, we can change it
<Daviey> roaksoax: TBH, freeipmi still needs more focus imo.
<Daviey> the bmc discover tool of freeipmi is probably needed for the ephemeral environment anyway
<roaksoax> Daviey: right, adding the command to use is easy, so we can have a IPMI (ipmitool LANPLUS Interface) , IPMI (freeipmi)
<roaksoax> Daviey: etc etc
<Daviey> cool.
<Chocobo_> Hi all,  I have set up MAAS but every action I do on the web interface requires me to re-enter my user name and password.  Also some functions (adding ssh key, and deleting nodes) does not seem to work.  Has anyone seen this before?
<Chocobo_> hmmm, I tried a "maas flush" recreated the superuser account, but the same problem exists.
<Daviey> Chocobo_: no, never seen or heard of that before.
<Daviey> Chocobo_: Have you had similar issues before?
<Daviey> Sounds like you are not maintaining your http session.
#maas 2013-07-09
<AskUbuntu> simple MAAS setup in ubuntu 13.04 and virtual box | http://askubuntu.com/q/318032
<sputnik13> hello?
<sputnik13> anyone around?  I'm wondering if there's ways to use a hybrid virtual and real maas setup
<sputnik13> I know there's a way to do virtual-maas but can you include real physical nodes as well?
<sputnik13> or are they mutually exclusive
<melmoth> sputnik13, if the real node are on the same network/bridge tje vm are on, it should work.
<melmoth> i had some maas hosted in a vm, coping with other vms as node as well as real hardware one.
<roaksoax> sputnik13: maas in reality sees VM's and physical machines as a machine. The only difference is how will it control the power
<hazmat> roaksoax, around?
<roaksoax> hazmat: here!
<hazmat> roaksoax, awesome.. i'm trying to reset/debug a bespoke maas setup.
<hazmat> with juan..
<hazmat> if you've got a few m we're in a hangout
<roaksoax> hazmat: sure,
<hazmat> roaksoax, thanks.. i think i got it working.. all machines powered down minus juju bootstrapping
<hazmat> roaksoax, that github ticket was key i think
<hazmat> for the bot archive.. https://github.com/celery/celery/issues/984
#maas 2013-07-10
<hazmat> roaksoax, hmm followup.. the node that's bootstrapping in the cluster appears to be up (responds to pings) but not to ssh.. per the rsyslog output it hasn't done anything in the last 1hr, its reporting as status 6.. http://paste.ubuntu.com/5860134/ any ideas?
<roaksoax> hazmat: o/
<roaksoax> hazmat: sorry couldn't make it last night.
<roaksoax> hazmat: it seems that it might have not finished running cloud-init after install (after first boot)
<hazmat> roaksoax, it did eventually finish, just took a long while
<roaksoax> hazmat: ok cool then. SO they are back online then
<hazmat> roaksoax, yup. although 2 of 12 haven't seem to have pending agent states  that i'm investigating.
<roaksoax> hazmat: ok! cool. Let me know if you need me!
<hazmat> roaksoax, nope looks good, thanks for your help yesterday.
<roaksoax> :)
<hazmat> roaksoax, re those 2 machines that didn't make it, afaics there isn't any rsyslog info for them. the odd part is that i don't see anything in the celery logs for them either (ie . no powercycle tasks)
 * hazmat recycles them via juju
<hazmat> oh.. the celery log doesn't reference node uuids its acting upon but task ids perhaps
<sputnik13> is there any plan to support network configuration as part of maas?
<sputnik13> by this I mean network router/switch configuration
<hazmat> roaksoax, the issue was somehow the impi creds that maas had for those two machines were invalid
<roaksoax> hazmat: uhmmm
<roaksoax> hazmat: i know there ws a related bug but was fixed
<BeatsMusic> Have a quick question about maas
<BeatsMusic> bootstraps fine
<BeatsMusic> fails at connecting to bind
<paraglade> when I do a juju bootstrap I am being prompted for how the partitioning will be done at the server console.  is there a way I can get the bootstrap process to be non-interactive?
<roaksoax> paraglade: the installation should be non-interactive
<roaksoax> paraglade: did you change the preseed?
<paraglade> roaksoax: nope
<paraglade> roaksoax: would this happen if the node has multiple volumes or drives?
<roaksoax> paraglade: might be the reason.. but it shouldnt cause the preseed selects the first disk
<BeatsMusic> Anyone know what this error means ?
<BeatsMusic> 2013-07-10 23:13:22,215 ERROR SSH forwarding error: bind: Cannot assign requested address
<BeatsMusic> #juju
#maas 2013-07-11
<AskUbuntu> MAAS / JuJu zookeeper issue | http://askubuntu.com/q/319061
#maas 2013-07-13
<AskUbuntu> MAAS install iso download size? | http://askubuntu.com/q/319587
<AskUbuntu> Can I make the MAAS server Juju machine 0? | http://askubuntu.com/q/319618
#maas 2013-07-14
<AskUbuntu> What steps to do after PXE boot (Nodes are in ready state)? | http://askubuntu.com/q/319962
#maas 2014-07-07
<gmb> bigjools: I was going to pick up https://bugs.launchpad.net/maas/+bug/1338402 but then I saw your thread about IP address filtering and Django weirdnessâ¦ are you working on this bug already/?
<ubot5> Ubuntu bug 1338402 in MAAS "Static IP range can be changed with no checks that it would exclude currently allocated IPs" [Critical,Triaged]
<bigjools> gmb: I'm trying to fix Andreas' bug, not that one
<bigjools> I was thinking about that one on the side
<gmb> bigjools: Okay, cool.
<bigjools> needs a cursor query I think
<gmb> Sounds like it. Djangoâs magic is a distinct brand of weird sometimes.
<bigjools> select TRUE FROM blah HAVING MIN(min_range) AND MAX(max_range)   etc...
<gmb> Right.
<bigjools> so should get True/False depending on whether the min from existing addresses is outside the entered range
<bigjools> min/max
<bigjools> well that query as it stands is crap but you get the idea :)
<gmb> bigjools: Cool, thanks. Iâd got as far as âcursor queryâ in my head and then was thinking about having another cup of tea before starting coding :).
<bigjools> heh
<bigjools> needs an ORDER in there too
<bigjools> possibly... not sure if PG DTRT here
<bigjools> I have NFI why Django is screwing with that other filter thing
<bigjools> that's totally hatstand
<bigjools> rvba: so Django is trying to be "helpful" again
<rvba> bigjools: yeah, I just found where it's doneâ¦
<bigjools> rvba: there's loads of bugs filed in the django tracker about host()
<rvba> bigjools: in django/db/backends/postgresql_psycopg2/operations.py:DatabaseOperations
<rvba>     def field_cast_sql(self, db_type):
<bigjools> right
<rvba>         if db_type == 'inet':
<rvba>             return 'HOST(%s)'
<rvba>         return '%s'
<rvba> And GenericIPField = inet
<bigjools> cursor.... sigh
<bigjools> should be called a curser
<rvba> heh
<bigjools> because it gets used after you swear a lot at ORM bugs
<rvba> bigjools: there is a workaround
<rvba> n [2]: print StaticIPAddress.objects.filter(ip__lte='10.0.0.96').query
<rvba> SELECT "maasserver_staticipaddress"."id", "maasserver_staticipaddress"."created", "maasserver_staticipaddress"."updated", "maasserver_staticipaddress"."ip", "maasserver_staticipaddress"."alloc_type", "maasserver_staticipaddress"."user_id" FROM "maasserver_staticipaddress" WHERE "maasserver_staticipaddress"."ip" <= 10.0.0.96
<bigjools> what's the workaround?
<rvba> bigjools: it's a bit ugly:
<rvba> http://paste.ubuntu.com/7759034/
<bigjools> how did I guess that was coming
<rvba> I just took it from the bug report.
<bigjools> I'm going to use a cursor
<rvba> bigjools: HOST is used only if get_internal_type return GenericIPField
<bigjools> it's ugly, but not as ugly as that
<bigjools> right - but what else would break?
<rvba> The good thing with this workaround is that it's a one-off
<bigjools> o/ jtv
<bigjools> rvba: https://code.launchpad.net/~julian-edwards/maas/dup-static-ip-bug-1338452/+merge/225779
<rvba> bigjools: on it
<bigjools> TIA :)
<bigjools> thanks rvba
<bigjools> eating now, bbiab
<allenap> BT have just arrived!
<jtv> Who's willing to review the "identify NGI by name instead of network interface" API branch?  It's a large diff but only a few dozen actual lines changed: https://code.launchpad.net/~jtv/maas/api-ngi-name/+merge/225650
<bigjools> gmb: one more thing that bug should have said - clearing those fields while an IP is allocated is just as bad
<gmb> bigjools: I figured that based on what Raphers said, but yes.
<bigjools> gmb: tiptop
<rvba> allenap: here is a canonistack instance for you: 10.55.32.228
<rvba> (With a MAAS package on it)
<jtv> Also a slightly nontrivial lint branch: https://code.launchpad.net/~jtv/maas/lint-2014-07-07/+merge/225794
<rvba> jtv: I'll take it
<jtv> Thanks.
<jtv> Annoying lint.
<jtv> Just didn't have the energy to address it Friday.
<dimitern> bigjools, jtv, gmb, rvba, allenap, hey guys, we need to have a quick chat some time this week about networking in maas and juju, when will be a good time? (a couple of you for >1h g+ would be great)
<jtv> Maybe tomorrow 09:00 UTC?
<rvba> WFM
<rvba> allenap: Do not forget to create the symlink to /mnt before you import the images btw
<dimitern> rvba, jtv, that works for me too, I'll ask the others and send invites
<dimitern> thanks!
<jtv> ok
<rvba> allenap: well, you won't probably need that instance now that you've got a proper connection :)
<allenap> rvba: I need to stress test it :)
<jtv> rvba, have you seen a spurious test failure in maasserver.tests.test_dns.TestDNSConfigModifications.test_add_node_updates_zone?
<jtv> rndc gets a "connection refused."
<jtv> Unlucky port number?
<rvba> jtv: no, never seen that one
<jtv> It seems to be rare.
<blake_r> rvba: cleanup branch from the license key stuff
<blake_r> rvba: https://code.launchpad.net/~blake-rouse/maas/utils-osystems-cleanup/+merge/225828
<rvba> blake_r: Thanksâ¦ I'll have a look in a bitâ¦ I think allenap is working on this too, he might want to have a look as well.
<allenap> blake_r, rvba: Yeah, Iâll review that.
<blake_r> rvba: alot will change when rpc is done but wanted to get it in there
<allenap> blake_r: Fwiw, Iâm working on the RPC stuff for OperatingSystemRegistry.
<blake_r> allenap: cool, you be better at it than me!
<blake_r> allenap: https://code.launchpad.net/~blake-rouse/maas/test-os-preseed-templates/+merge/225838
<jpds> rsyslogd-3000: Could not open dynamic file '/var/log/maas/rsyslog/10-1-56-17.cloud/2014/07/07/messages' [state -3000] - discarding message
<jpds> Anyone know why that would be happening?
<gmb> rvba, allenap: ^^
<gmb> Looks like rsyslog hilarity but I havenât seen that happen first-hand
<rvba> jpds: never seen that oneâ¦ like gmb said, it seems something is wrong with rsyslog;  if this happens consistently, I'd suggest changing rsyslog's log level to see if you can get more information about the errorâ¦
<jpds> rvba: It's not creating any directories under /var/log/maas/rsyslog
<allenap> jpds: Check ownership of /var/log/maas/rsyslog and the user that rsyslog runs as. It might be that /var/log/maas/rsyslog has the wrong owner.
<jpds> allenap: Owned by maas:maas.
<allenap> jpds: Yeah, on my machine itâs owned by syslog:syslog.
<rvba> jtv: reviewing your discover-ipv6-interfaces branch now.
<jtv> Thanks.
<blake_r> allenap: jtv: rvba: gmb: can I get a review of this for 1.6 upgrade https://code.launchpad.net/~blake-rouse/maas/cluster-upgrade-boot-resources/+merge/225868
<allenap> blake_r: I have dinner now, but Iâll look at it in ~2 hours. Is that okay?
<blake_r> allenap: no rush, just wanted to inform you all
<allenap> blake_r: Iâd like to review it, and Iâm really happy youâve worked on it. I was puzzled earlier trying to figure out why loads of new things were being downloaded to the cache so I want to see what I missed.
<blake_r> allenap: i remember you all mentioning it on irc or email, that it was an issue, couldnt find a bug for it, so i reported a new one
<blake_r> allenap: it shouldn't modify the cache, might have just been downloading all of the new hwe kernels
#maas 2014-07-08
<jtv> dimitern: we have a scheduling conflict for a 08:00 UTC call.  Can we have it at 09:00 UTC like we said originally?
<dimitern> jtv, yes, I don't know what happened :/ I remember setting it for an hour later, will reschedule
<rvba> dimitern: thanks
<jtv> Thanks dimitern
<dimitern> jtv, rvba, if you refresh do you see it scheduled correctly this time?
<rvba> dimitern: yes
<jtv> Yes.
<dimitern> good :)
<jake6a> can someone help me with the installation of JuJu with MaaS ?
<jake6a> I have an actual Ubuntu machine setup, installed MaaS on it, trying to bootstrap juju but it returns with 409 CONFLICT error
<bigjools> hardware drivers are still not documented, are they?
<bigjools> jake6a: did you enlist any nodes to maas yet?  409 means maas can't find a suitable node to allocate to juju
<jake6a> I did not
<jake6a> I tried doing so in the MaaS web interface but they get stuck in "Commissioning"
<bigjools> what sort of nodes are you adding?
<bigjools> and power types?
<jake6a> I did a wake-on-lan
<jake6a> I'll tell you my setup
<jake6a> I'm using a Mac and I have another Ubuntu machine setup with Maas installed, I want to run a Juju-maas environment so I can run services like mysql and wordpress for example
<jake6a> I've installed Juju on the Mac and Maas on the Ubuntu machine
<bigjools> what are you going to use as nodes?
<jake6a> I was planning on using the Ubuntu machine
<bigjools> you can't do that, you installed maas on it
<jake6a> Is it even possible to use the same machine as a node to the Maas server?
<jake6a> I see
<jake6a> Ok then, can I install a VM Ubuntu on my mac, and act that as a node for example?
<bigjools> you need a machine with nothing on it, maas will control it entirely
<bigjools> yes, VMs are fine
<bigjools> there is a section in the documentation on how to set that up
<bigjools> please follow it carefully
<jake6a> Alright, I am installing the virtual machine now
<jake6a> Could you link me to that section please?
<bigjools> sure
<bigjools> http://maas.ubuntu.com/docs1.5/nodes.html#virtual-machine-nodes
<jake6a> So after adding that node, Juju bootstrap should work fine?
<bigjools> yes
<bigjools> as long as the node was commissioned
<bigjools> and goes READY
<bigjools> you'll need a second one to deploy a charm
<jake6a> So I'll need one more VM ?
<bigjools> as many VMs as you want charms deployed
<jake6a> I see
<jake6a> So for one charm setup, I will use
<jake6a> 1- Ubuntu server with Maas
<jake6a> 2- Ubuntu VM as a node
<jake6a> 3- Juju on Mac
<jake6a> correct?
<bigjools> you can run juju anywhere
<bigjools> well, the cmd line I mean, it then installs itself on the bootstrap node
<jake6a> Cool, I'll try this now, thanks a lot bigjools
<bigjools> welcome
<jake6a> I might be having some little trouble with the configurations though, is it okay if I report back?
<bigjools> in my own setup I run juju on the maas server
<bigjools> I won't be around, I'm leaving now, but someone may help
<jake6a> Alright, thanks a lot
<gmb> allenap, jtv, rvba: Can has review? https://code.launchpad.net/~gmb/maas/static-ip-sanity-checks/+merge/225935
<gmb> Oh, hang on
<gmb> conflicts
<allenap> gmb: Claimed!
<jtv> Drat.
<gmb> allenap: Ta. Conflicts fixed.
 * gmb -> lunch
 * jtv â different lunch
<jake6a> bigjools: still there?
<jpds> Why would MAAS suddenly start complaining about RPC information for a cluster controller not being available?
<jpds> Apparently re-enlisting the node makes everything work again.
<gmb> allenap: Have replied to your review. Thankee :)
<blake_r> allenap: rvba: here is the fix for the migration https://code.launchpad.net/~blake-rouse/maas/append-current-dir-for-boot-images-migration/+merge/225972
<allenap> blake_r: Iâm otp, but Iâll look when Iâm done.
<blake_r> allenap: cool
<rvba> blake_r: cool, I'll have a look.
<blake_r> rvba: thanks
<blake_r> rvba: sorry for the bad code, previously
<rvba> blake_r: no worries, it happens to everyone.
<rvba> blake_r: testing your fix now
<blake_r> rvba: is it working?
<rvba> blake_r: still importing the images with MAAS 1.5â¦
<blake_r> rvba: okay
<rvba> blake_r: after the upgrade, I'm seeing http://paste.ubuntu.com/7765995/ in celery.log
<blake_r> rvba: that was an issue with bigjools added subarches to maas.meta
<blake_r> rvba: need to handle that key missing
<rvba> This means the reporting of the images didn't happen. And thus we cannot QA your change properly.
<blake_r> Okay, I will update the branch to check for key. One sec
<rvba> I still think your branch is saneâ¦ but we need to get to a state where we can do a full QA.
<rvba> blake_r: can you explain why the key is missing?
<blake_r> rvba: because when bigjools add the supported_subarches column to the database, it needs to be reported every time the report_boot_images is called
<blake_r> rvba: in 1.5 that wasn't there
<rvba> I see
<blake_r> rvba: so for 1.6 he added a maas.meta file under boot-resource/current
<blake_r> rvba: that contains the subarches key
<rvba> bigjools: what about the upgrade path for this? ^
<blake_r> rvba: http://paste.ubuntu.com/7766045/
<blake_r> rvba: try that fix to see if ti fixes it
<blake_r> rvba: i can add it to my branch it it does
<rvba> Testing it nowâ¦
<rvba> blake_r: it fixed the crashâ¦
<blake_r> rvba: okay I will include it in my branch
<blake_r> rvba: let me add a test as well
<rvba> Cool; I cleared the BootImage table, let's see if it gets re-populated correctly when the parsing task runs.
<rvba> Yep, it worked okay.
<blake_r> Awesome
<rvba> blake_r: please add a comment in the code for the 'subarches = mapping.mapping[image]['subarches']' statement; why we need to do this is non-obvious.
<allenap> blake_r: The branch linked to https://bugs.launchpad.net/maas/+bug/1319143: is that really related to that bug?
<ubot5> Ubuntu bug 1319143 in MAAS "move supported operating system into cluster using RPC" [Critical,Triaged]
<blake_r> rvba: okay
<rvba> Ta
<blake_r> the boot-image-xinstall?
<blake_r> no it was linked to RPC os
<blake_r> it fixed an issue to not needing RPC for every curtin request
<blake_r> idk why it was moved
<allenap> blake_r: Do you know what bug number that other bug has? Iâll move it (because I want to steal bug 1319143).
<ubot5> bug 1319143 in MAAS "move supported operating system into cluster using RPC" [Critical,Triaged] https://launchpad.net/bugs/1319143
<blake_r> oh wait sorry, it is related to that bug
<blake_r> without that branch an RPC cal was going to be needed
<blake_r> allenap: can we get this one merged, https://code.launchpad.net/~blake-rouse/maas/license-key-views/+merge/224808
<blake_r> allenap: since your working on the PRC stuff
<blake_r> allenap: RPC*
<allenap> blake_r: Iâve added a comment saying I think itâs okay to land.
<blake_r> allenap: awesome thanks
<jose> hey guys, I have a maas created on a server, and then I try to add a node by enlisting it with ubiquity, but it just doesn't appear, any ideas on what may be going on?
<jose> like, the server turns off but I don't get the node on the maas
<newell> http://paste.ubuntu.com/7766897/
<newell> nevermind that...
<diffen_> Evning, im planning on installing ubuntu-maas and on top of that virtual box for different servers. I wonder if thats a good solution to have and if the hardware power from the computers are spread across the computers so if one hardware goes offline the virtual machine are not troubled by that.
#maas 2014-07-09
<bigjools> gmb: sorry dude, qa-bad. https://bugs.launchpad.net/maas/+bug/1338402
<ubot5> Ubuntu bug 1338402 in MAAS "Static IP range can be changed with no checks that it would exclude currently allocated IPs" [Critical,Fix committed]
<bigjools> well, qa-almost-good would be more accurate :)
<bigjools> gmb: also is this one actually in progress? https://bugs.launchpad.net/maas/+bug/1312844
<ubot5> Ubuntu bug 1312844 in MAAS "MAAS commissioning page shows distributions that are not available" [High,In progress]
<gmb> bigjools: That last one should be Fix Committed, I think. Iâll check.
<gmb> Will check out the QA issue now.
<gmb> bigjools: Thatâs very weird. The query clearly uses <= and >=â¦
 * gmb investigates
<jtv> gmb: the card about the find_nodegroup query not dealing with a mix of IPv4 and IPv6 addresses has your face on it, and has landed in the Archive.  But I don't see any fix to that query.  Do you know what happened?
<jtv> It went through Review and Done, but the code hasn't been touched for a month.  Did a branch disappear somehow?
<jtv> Or did two cards get confused?
<gmb> jtv: ISTR that in fact that card was a question masquerading as a statement (i.e. âDoes that query handle mixed stuff? IDKâ¦â) and that I wrote tests that prove that yes, it does. But I could be making that up.
<jtv> Ah.  And we got this overnight: http://paste.ubuntu.com/7769133/
<bigjools> gmb: yeah it's odd - easy to recreate
<bigjools> gmb: also the other bug has no branch on it so I was confused
<bigjools> it was in the QA lane on the board
<gmb> bigjools: Okay. Hereâs a fix for the first issue: over-use of >= and <= :) https://code.launchpad.net/~gmb/maas/static-ip-sanity-checks/+merge/226074
<bigjools> gmb: lol
<jtv> I don't see any test on find_nodegroup with mixed IPv4/IPv6 addresses... only a scenario test that runs once for IPv4, once for IPv6.
<bigjools> anyone fancy QAing the DB isolation level card?
<bigjools> it's been there too long
<bigjools> would like it OKed before release if you can
<bigjools> jtv: ^ ?
<jtv> I can try â will need to get my setup here working though.
<jtv> Although it has stood up well in practice.
<jtv> rharper basically QA'ed that one.
<rvba> allenap: since you're working on the Celery removalâ¦ Not sure what your plan is but if you could move the power-related tasks over to twisted, that would be great.
<jake6a> bigjools: you there?
<jake6a> Anybody know where should I run the "virsh" command for virtual machines/
<jake6a> ?
<jake6a> On the virtual machine (node) or on the Maas (server)?
<rvba> jake6a: on the MAAS server, you might find some interesting additional info on http://askubuntu.com/questions/292061/how-to-configure-maas-to-be-able-to-boot-virtual-machines
<jtv> Thanks for the review, gmb.
<breze411> Could anyone tell me how to log in to maas nodes physical console ? I need to stop networking to configure nic bonding but cannot figure what login to use for the console
<breze411> This is actually for maas nodes used by the juju
<roadmr> can maas be deployed using juju? or is that too "chicken-and-egg"?
<rbasak> roadmr: chicken and egg. But it has been considered. I still want to try and make it work one day.
<rbasak> It's be nice to be able to scale HA MAAS with Juju. But no, not possible right now.
<roadmr> rbasak: ok, makes sense. So the easiest way to deploy maas is to just manually install ubuntu server, then apt-get install maas, right?
<rbasak> roadmr: right. Or for MAAS + OpenStack on top of it, look at the cloud-installer package
<roadmr> rbasak: oh I'll look at that! I've usually just installed maas, then juju deployed all the openstack charms one by one. Will look at cloud-installer though!
<sp2940> i'm getting the error "One or more MAC addresses is invalid"; the node powers up and commissions fine -- get the maas login screen fine -- but then after about 30 seconds prints this error and powers off the server. I looked at the Python source and got a better idea of what's going on. Does anyone have any experience with this issue? Causes/remedies? Happens in both 12.04.4 LTS and 14.04 LTS.
<sp2940> still getting the "One or more MAC addresses is invalid"... Best I can guess is that something is conflicting with the dhcp server on the maas control node.
#maas 2014-07-10
<gmb> rvba, allenap, jtv, bigjools: Can has review plz https://code.launchpad.net/~gmb/maas/fix-get-maas-facing-server-address/+merge/226253
<allenap> gmb: Okeydoke.
<rvba> allenap: btw, before I forget, it would be great if the twisted replacements for celery tasks would give the same level of detail that we have with celery: "Task <task> name started" / "Task <task> completed in 3s."
<allenap> rvba: Okay, thatâs a good point.
<rvba> allenap: maybe the compatibility layer (that will use celery *or* twisted) can take care of that.
<rvba> bigjools: rarg, I forgot this: https://code.launchpad.net/~rvb/maas/add-doc-1.6-2/+merge/226256
<bigjools> allenap: need to talk to you about celery replacement work
<allenap> bigjools: Okeydoke.
<xnox> hey people! I have a simple idea.
<xnox> pxe-boot initramfs & kernel, that do NFS-root boot.
<xnox> to have my nodes disk-less.
<xnox> does maas-controller have nfs server, or should i provide that separately?
<xnox> next, I'd want to try NFS-root boot ubuntu-desktop iso image and preseed hand-off desktop install.
<xnox> i guess maas doesn't even need to know anything about nfsroot boot to install.
<xnox> it's just another pxe-boot with different files.
<bigjools> the maas ephemeral environment is already diskless, but it uses iscsi.
<bigjools> only server images have that built in AFAIK
<xnox> hm. i believe livecd desktop image should be capable of iscsi.
<xnox> bigjools: where can i read up on the maas ephemeral environment, and what is it used for?
<bigjools> well you don't want to use the ephemeral env for installed nodes, it's just that iscsi is availabe already if you poke the right images into tgt and set the kernel options on the booted node
<xnox> gotcha
<bigjools> I tried to use this to boot the xbmc image like that but it doesn't come with iscsi in the kernel
<allenap> xnox: We have discussed running up diskless nodes before. One thought we had was using Ceph, possibly negotiated via Cinder, so that iSCSI is also supported (and whatever else Cinder supports).
<allenap> xnox: With Ceph, at least, we could do copy-on-write to immediately provision a node.
<xnox> "Cinder is a programming library, designed to give the C++ language advanced visualization abilities. " ?
<xnox> i'm guessing you are talking about some other cinder.
<rvba> https://wiki.openstack.org/wiki/Cinder
<xnox> cool.
<allenap> xnox: It /might/ even be possible to get a node up and running using a network disk, while simultaneously pushing stuff to the local disk. Immediate provisioning, but ultimately using local disks.
<allenap> But Iâve not discussed that with anyone who might be able to say if itâs possible with current tech.
<xnox> sounds fun.
<xnox> for me, it's mostly about our kernel, graphics, desktop testing.
<xnox> tag machines with "ati", "nvidia", etc. And then provision them with one of the desktop installs and verify that desktop install media is correct + execute various tests (boot-testing, power testing, etc.)
<xnox> utah is currently used, and it does provision the machines / deploys tests / collects results.
<xnox> but the provision step is not as reliable as maas, nor as flexible.
<allenap> xnox: https://docs.google.com/a/canonical.com/document/d/1ux5-jSct0ZSCye3s4SHD739ABZV9Ycd8897mNgKbRX0/edit (sorry to other folk, itâs Canonical-only right now) is a doc we started over a year ago to talk about diskless provisioning with MAAS.
<allenap> xnox: blake_r has been doing some work on diskless booting for fun, https://code.launchpad.net/~blake-rouse/maas/diskless-boot/+merge/223553. Iâm not sure how close this is to production ready though.
<xnox> hm, current desktop images do not have support to install onto iscsi target. shame.
<xnox> I should probably add that.
<jhobbs_> Is there a good way to edit boot source selections in 1.6?
<jhobbs> i used the admin shell to edit the selections objects by hand
<roaksoax> jhobbs: you can point to a different config file
<roaksoax> newell: ^^
<newell> roaksoax, what did you want me to look at here?
<roaksoax> newell: what's the import command you used to point at different boot resources?
<roaksoax> i think that's what jhobbs is wanting to do
<jhobbs> will that replace the "grab all precise and trusty images" defaults?
<newell> let me paste my source.yaml
<newell> one sec
<roaksoax> jhobbs: yeah i think so
<roaksoax> newell: what's the command you using? maas-import-pxe-files --sources??
<jhobbs> yeah
<jhobbs> ok i know how to do that
<newell> --sources-file
<newell> http://paste.ubuntu.com/7776192/
<newell> jhobbs, ^^
<newell> something like that
<jhobbs> cool
<jhobbs> thanks
<allenap> blake_r: Got time for an easy review? https://code.launchpad.net/~allenap/maas/operating-system-get-release-title/+merge/226346
<blake_r> allenap: looking at it now
<allenap> blake_r: Ta. Iâll be back later; got to feed the kids now.
<newell> allenap, easy review for you when you get back: https://code.launchpad.net/~newell-jensen/maas/apiclient-get-flatten-sequence/+merge/226351
<newell> allenap, do I need another review or good to land it?
 * newell set it to approved 
<dpb1> Hi guys... anyone seen this before? (line 88) http://paste.ubuntu.com/7777233/
<dpb1> 2014-07-10 21:32:30 ERROR juju.provider.common bootstrap.go:119 bootstrap failed: refreshing addresses: gomaasapi: got error back from server: 401 OK (Nonce already used: 70320620)
<dogfoodhead> why does maas add 127.0.1.1 to /etc/hosts on every reboot?
<dogfoodhead> why not add the ip address allocated to the node. 127.0.1.1 does not play nicely with cdh5
<dogfoodhead> hello?
<dogfoodhead> which repository can I get the 1.6 version of maas?
<dogfoodhead> the documentation says to use "sudo add-apt-repository cloud-archive:tools" but this does not work on 14.04
#maas 2014-07-11
<dergrunepunkt> newbie question, how do I login to the nodes once they are  "ready"?
<dergrunepunkt> got it
<bigjools> ssh keys
<allenap> blake_r: Hi there. Can you take another quick look at https://code.launchpad.net/~allenap/maas/operating-system-get-release-title/+merge/226346 please? I need it for another branch.
<blake_r> allenap: sure
<blake_r> allenap: done
<allenap> blake_r: Thanks!
<blake_r> allenap: is there a RegionClient?
<blake_r> allenap: so I can call get_boot_sources
<allenap> blake_r: ClusterClientService has a getClient method. You need to get hold of the instance of that service thatâs running.
<blake_r> allenap: okay
<allenap> blake_r: In practice thatâs going to mean that you want to initiate your code from a service created in provisioningserver.plugin so that you get a reference back to the root service.
<allenap> blake_r: Iâm wondering if thereâs a way to get the root service from anywhere...
<blake_r> allenap: getClient shouldn;t it return a client that connects back to the region? why should it not be the root?
<allenap> blake_r: Yeah, it returns a client that talks to a region controller. Iâm trying to figure out how to get you an instance of ClusterClientService to call getClient on :)
<blake_r> allenap: oh... yeah I would need that first
<blake_r> allenap: nice to have like a decorator that passes it to the method
<allenap> blake_r: If your code is running from a service thatâs attached to the root service (see ProvisioningServiceMaker) then it can call getServiceNamed(ârpcâ).getClient()
<allenap> Sorry, service.getServiceNamed(â¦)
<blake_r> allenap: will UbuntuOS.get_supported_releases() be called from a service?
<allenap> blake_r: Ah, thatâs trickier!
<blake_r> allenap: great! :)
<allenap> blake_r: Have a nice weekend ;)
<blake_r> allenap: lol
<allenap> blake_r: I am investigating.
<blake_r> allenap: how close are you to landing RPC for os? might just wait got that to finish the ubuntu-releases-simplestreams
<allenap> blake_r: Iâm trying to land some of it now.
 * allenap has to go.
<blake_r> allenap: okay, have a good weekend
#maas 2015-07-06
<lathiat> Can anyone tell me if I can somehow login to a maas node running enlistment, to debug the enlistment not working?
<lathiat> ah found it, backdoor
<lathiat> Ah so my problem is maas is giving the DNS server for the region as it's primary interface, which goes through the router.. so the maas server is upset that the traffic is coming in and out different interfaces
<lathiat> tada
<mup> Bug #1471728 opened: MAAS web frontend hangs at Nodes listing if cluster not reachable <MAAS:New> <https://launchpad.net/bugs/1471728>
<mup> Bug #1471728 changed: MAAS web frontend hangs at Nodes listing if cluster not reachable <MAAS:New> <https://launchpad.net/bugs/1471728>
<mup> Bug #1471728 opened: MAAS web frontend hangs at Nodes listing if cluster not reachable <MAAS:New> <https://launchpad.net/bugs/1471728>
<mup> Bug #1471731 opened: McDivitt console not available after deployment <MAAS:New> <https://launchpad.net/bugs/1471731>
<mup> Bug #1471731 changed: McDivitt console not available after deployment <MAAS:New> <https://launchpad.net/bugs/1471731>
<mup> Bug #1471731 opened: McDivitt console not available after deployment <MAAS:New> <https://launchpad.net/bugs/1471731>
<ltrager> roaksoax_: morning
<roaksoax_> ltrager: morning
<mup> Bug #1471946 opened: Installing on vivid yields a cluster not running because /var/lib/maas/secret is not there yet <MAAS:New for andreserl> <MAAS 1.8:New for andreserl> <https://launchpad.net/bugs/1471946>
<bmorriso> I have a question about zones
<bmorriso> It seems this is used for physical separation -- to ensure you don't provision a host in the same dc/rack/chassis/etc?
<bmorriso> Is it possible to have a zone of a zone? So this chassis is in this rack, in this cage, in this DC? And I want MAAS to not deploy to a host that's in the same chassis, in the same rack, in the same DC...
<roaksoax> bmorriso: no you can't have a zone of a zone unfortunately
<roaksoax> bmorriso: but you can create tags
<bmorriso> Yeah, I wondered about leveraging tags.
<roaksoax> bmorriso: we would normally use tags for that kind of separation
<bmorriso> Fair enough. I'm OK with that. We're still evaluating MAAS and figuring out how to use it and how it fits in our environment.
<roaksoax> bmorriso: cool. Are you using 1.8 ?
<bmorriso> Just upgraded last week.
<bmorriso> Been using it since 1.6
<roaksoax> bmorriso: ah yeah, 1.6 is horrible :)
<bmorriso> Got the job done, but yeah...My gripes about 1.8 are largely UI/UX
<bmorriso> Also it seems pserv.log defaults to `/dev/null` o_O
<bmorriso> But otherwise, it's treated me well.
<roaksoax> bmorriso: not really. The log is now clusterd.log and regiond.log instead of pserv.log
<bmorriso> Oh, I was looking at a config the other night, it said '/dev/null`
<bmorriso> In 1.7 I had problems with pserv, so I was looking for that log in 1.8
<roaksoax> bmorriso: yeah we changed the config in 1.8. 1.9 will completely drop pserv.yaml, maas_cluster.yaml in favor of clusterd.conf and maas_local_settings.py in favor of regiond.conf
<bmorriso> Awesome. Looking forward to it.
<roaksoax> bmorriso: 1.9 will support both network and storage config as well
<bmorriso> Any intentions of giving Curtin's docs more love in 1.8.x/1.9?
<roaksoax> bmorriso: it is in the TODO. Definitely something we want to improve
<bmorriso> I've managed to hack around most of my problems with help from this channel. But it puts my coworkers off who are less adventurous.
<roaksoax> bmorriso: hehe, yeah curtin has really neat features but upstream (the maas team is not upstream of curtin) also lacks docs
<roaksoax> bmorriso: so we are definitely looking to improve that for sure
<roaksoax> bmorriso: and it is in the todo
<bmorriso> No doubt. A one-page (sort of not-really-public) README leaves a lot to be desired.
<roaksoax> indeed. But hopefully we can improve that this time
<bmorriso> I actually have in the works a curtin installer that clones our ansible repo and runs a playbook to further the provisioning process.
<wolverineav> 'Any intentions of giving Curtin's docs more love in 1.8.x/1.9?' +1 to that :)
<wolverineav> on a related note, I'm currently copying some scripts over using wget in curtin. it works fine. the next step is to 'chmod +x /path/to/script.sh' - where it complains /path/to/script.sh doesn't exist. is there something that I'm missing?
<wolverineav> I've tried to use the {{TARGET_MP}} and {{TARGET_MOUNT_POINT}} env variables, but its not available in the late_commands context
<catbus1> wolverineav: have you tried $TARGET_MOUNT_POINT?
<wolverineav> catbus1: let me give it a try
<wolverineav> ah, I seem to have hit a bug similar to the one seen before: https://bugs.launchpad.net/maas/+bug/1405998 my current maas.log: http://paste.ubuntu.com/11833449/
<wolverineav> # lsof -u maas | grep CLOSE_WAIT | wc -l  - the output shows 984
<wolverineav> so i restart maas related services like dhcpd, regiond, clusterd, bind9 and then try again. and it works.
<wolverineav> maas version is 1.8. should I create a bug? or it has already been handled in the trunk branch?
#maas 2015-07-07
<catbus1> kiko: ^^^
<catbus1> wolverineav: it's not 'fix released' so I would expect the bug still exists for 1.8. I think this bug probably should be targeted to 1.8 and 1.9 if the bug is valid for 1.8 and 1.9.
<wolverineav> catbus1: ok, that sounds good
<mup> Bug #1472116 opened: Juju failed to bootstrap MAAS with 500 INTERNAL SERVER ERROR / unknown error <1.8> <juju> <MAAS:New> <https://launchpad.net/bugs/1472116>
<mup> Bug #1472228 opened: maas-pserv still " Stop"  !!  <MAAS:New> <https://launchpad.net/bugs/1472228>
<mup> Bug #1472260 opened: MAAS picks wrong cluster-controller for curtin install <MAAS:New> <https://launchpad.net/bugs/1472260>
<mup> Bug #1472268 opened: Interface with sticky IP gets prioritized dynamic IP address as well  <MAAS:New> <https://launchpad.net/bugs/1472268>
<mup> Bug #1472268 changed: Interface with sticky IP gets prioritized dynamic IP address as well  <MAAS:New> <https://launchpad.net/bugs/1472268>
<mup> Bug #1472268 opened: Interface with sticky IP gets prioritized dynamic IP address as well  <MAAS:New> <https://launchpad.net/bugs/1472268>
<mup> Bug #1402042 opened: console= parameters need to be added before -- on kernel cmdline <curtin:Confirmed> <MAAS:Triaged> <MAAS 1.7:Triaged> <MAAS trunk:Triaged> <curtin (Ubuntu):Confirmed> <debian-installer-utils (Ubuntu):Fix Released> <maas (Ubuntu):New> <debian-installer-utils (Ubuntu
<mup> Precise):New> <maas (Ubuntu Precise):New> <curtin (Ubuntu Trusty):Confirmed> <debian-installer-utils (Ubuntu Trusty):New> <maas (Ubuntu Trusty):New> <curtin (Ubuntu Utopic):Won't Fix> <debian-installer-utils (Ubuntu Utopic):New> <maas (Ubuntu Utopic):New> <curtin (Ubuntu Vivid):Confirmed>
<mup> <debian-installer-utils (Ubuntu Vivid):New> <maas (Ubuntu Vivid):New> <curtin (Ubuntu Wily):Confirmed> <debian-installer-utils (Ubuntu Wily):Fix Released> <maas (Ubuntu Wily):New> <Debian:Fix Released> <https://launchpad.net/bugs/1402042>
<voidspace> rvba: ping
<rvba> voidspace: hi
<voidspace> rvba: hey, hi
<voidspace> rvba: I'm using the devices API, via gomaasapi, to create a device and then allocate an address for the device
<voidspace> rvba: so far so good
<voidspace> rvba: when I try to delete the device (on container destruction), via gomaasapi, I get an error 403
<rvba> voidspace: 403?  That's odd.
<voidspace> rvba: ah, and the error document (html!?) includes: CSRF verification failed. Request aborted
<voidspace> rvba: maybe CSRF hasn't been turned off for that api endpoint
<voidspace> this is using 1.9 dailybuilds
<rvba> voidspace: CSRF should be disabled for the entire APIâ¦ but let me have a look at the code to be sureâ¦
<voidspace> I'm double checking my usage of the api
<voidspace> rvba: my fault
<rvba> voidspace: ah! :)
<voidspace> rvba: I'm using "device" instead of "devices" as the api endpoint
<voidspace> interesting error though
<rvba> Indeed.
<voidspace>  /device/systemId
<voidspace> when it should be /devices/systemId/
<rvba> Right.
<voidspace> rvba: sorry for the noise
<rvba> no worries
<mup> Bug #1472338 opened: Failed to refresh power state and unhandled errors -  exceptions.OSError: [Errno 12] Cannot allocate memory <oil> <MAAS:New> <https://launchpad.net/bugs/1472338>
#maas 2015-07-08
<mup> Bug #1384279 changed: Enhancement Request Version and program data "About" <maas (Ubuntu):Expired> <https://launchpad.net/bugs/1384279>
<amirali> hi everyone
<amirali> maas 1.8 question > can anyone help ?
<amirali> ......
<amirali> Failed to query node's BMC
<gnuoy> I woke up this morning with a spring in my step ready to wield the mighty maas only to discover that it seems to have imported a broken image (http://paste.ubuntu.com/11840324/). So, 1) can I revert to an earlier image? 2) are there docs covering 1 that I've missed? 3) what should I file a bug against for the broken image?
<amirali> could anyone tell me about vmware powertype in maas 1.8
<amirali> hi RoAkSoAx
<amirali> are you there?
<mup> Bug #1472626 opened: MAAS should provide an easy way to add PPAs on a per-system or per-tag basis <MAAS:Triaged> <https://launchpad.net/bugs/1472626>
<mup> Bug #1472626 changed: MAAS should provide an easy way to add PPAs on a per-system or per-tag basis <MAAS:Triaged> <https://launchpad.net/bugs/1472626>
<mup> Bug #1472626 opened: MAAS should provide an easy way to add PPAs on a per-system or per-tag basis <MAAS:Triaged> <https://launchpad.net/bugs/1472626>
<gnuoy> Maas has updated the troublesome  image and all is peachy again.
<sto> How do I tell curtin to use GPT instead of MBR with MAAS? I have a 3TB disk and MAAS only uses 2TB because it is using MBR
<kiko> sto: I think newer versions of curtin handle that correctly, dpkg -l | grep curtin?
<sto> # dpkg -l | grep curtin                 ii  curtin-common                       0.1.0~bzr201-0ubuntu1~14.04.1         all          Library and tools for curtin installer     ii  python-curtin                       0.1.0~bzr201-0ubuntu1~14.04.1         all          Library and tools for curtin installer
<sto> kiko: ^
<mup> Bug #1472707 opened: Master Cluster fails to connect after importing wiley images  <hyperscale> <MAAS:New> <https://launchpad.net/bugs/1472707>
<kiko> hmm
<kiko> I think that's pretty recent in fact
<kiko> just a moment, otp
<mup> Bug #1472707 changed: Master Cluster fails to connect after importing wiley images  <hyperscale> <MAAS:New> <https://launchpad.net/bugs/1472707>
<mup> Bug #1472707 opened: Master Cluster fails to connect after importing wiley images  <hyperscale> <MAAS:New> <https://launchpad.net/bugs/1472707>
<oxkipo> Hi Im getting error used fallback datasource while turning on my node. Im on MAAS 1.8
<kiko> sto: so, I'm not not sure whether curtin supports gpt drives for x86
<kiko> sto: I am looking at the source code and I can see some gpt code, but it seems only used on ARM
<kiko> smoser, did I read the code wrong?
<smoser> i think so
<kiko> smoser, what calls partition_main()? is it maas?
<kiko> if so, does maas know how to tell curtin to use gpt?
<smoser> it can be told to do gpt, but it will only do it by default if it is booted uefi. i think.
<kiko>     if uefi_bootable:
<kiko>         return 'uefi'
<kiko>     if machine in ['aarch64']:
<kiko>         return 'gpt'
<kiko>     elif machine.startswith('ppc64'):
<kiko>         return 'prep'
<smoser> so uefi is gpt.
<kiko> okay
<kiko> sto: does UEFI boot mode work for you?
<kiko> smoser, is that mandatory, i.e. can you use GPT tables and BIOS?
<smoser> i think the answer is probably.
<smoser> so 2 ways to get gpt
<kiko> http://www.rodsbooks.com/gdisk/bios.html
<kiko> it sort of does
<smoser> a.) you can change the config provided by maas to curtin to include
<smoser>  block-meta:
<smoser>   format: gpt
<smoser> b.) you can just let it do what it does, and then convert it to gpt (i think).
<oxkipo> please may someone help me?
<smoser> oxkipo, cloud-init needs the maas server that it was instaled with to be present at each boot.
<kiko> oxkipo, you may need to provide some more information, as I didn't understand your question, but smoser is a good mind-reader :)
<smoser> but i think b i snot true.
<oxkipo> kiko at the end of booting the node after the ssh key im getting error used falback datasource
<kiko> I don't think you can simply convert to gpt
<smoser> i thought i did that... thought i made pt_mbr always leave room for a gpt secondary header at the end so you could convert from mbr to gpt using --mbrtogpt
<kiko> smoser, I think converting is easy if you have less than 4 partitions
<smoser> well, only sort of easy.
<smoser> for sto's case it will work.
<smoser> but if you your mbr partitoin runs to the end of the disk, then there is no where to put the secondary header for gpt.
<smoser> without writing on top of that filesystem
<smoser> but lucky for sto, he's got a full 1TB for that :)
<smoser> as the mbr partition only goes to 2TB of the 3TB
<kiko> yeah
<smoser> i should make curtin leave 34 sectors off the end of mbr partitioned disks.
<smoser> growpart does that now.
<mup> Bug #1472741 opened: No way to delete images as the maas user that I can see <MAAS:New> <https://launchpad.net/bugs/1472741>
<sto> smoser: I went the a. way and it worked ok
<sto> easier than changing partitions later
<sto> ;)
<sto> thanks
<smoser> well, changing is easy enough really.
<smoser> sgdisk --mbr2gpt , next reboot would pick it up
<kiko> smoser, and a 3rd way would be to configure UEFI boot?
<smoser> right.
<kiko> sto: would you be so kind as to ask an ask.ubuntu.com question? I'll try and edit into it what smoser replied
<smoser> in whic hcase you'll get gpt and the uefi partition
<kiko> yeah
 * kiko looks at sto
<sto> kiko: tomorrow i'll try to add the question
<sto> now i'm going afk ... ;)
<kiko> sto: c'mon!
<smoser> sto, kiko just made a change to curtin trunk so that it will create mbr partition tables leaving 33 sectors for secondary gpt.
<smoser> end result is that now it will do what i had thought it would do, and if you had a < 2TB disk that you installed to, you could boot
<smoser> then do: sgdisk --mbrtogpt /dev/sda
<smoser> and reboot
<smoser> and possibly then boot with gpt.
<smoser> also uploaded the change to growpart to have the same behavior.
<kiko> cool
<kiko> thanks!
#maas 2015-07-09
<amirali> "Unknown API endpoint: " what ths mean ????
<sto> kiko: http://askubuntu.com/questions/646278/how-to-ask-curtin-to-use-gpt-instead-of-mbr-with-maas
<sto> as promised .. ;)
<sto> Now another question... I'm deploying openstack with MAAS and Juju and I'm using LXC containers for some charms ... is there a way to make the MAAS DNS give a name to the containers... I'm mainly interested on the openstack-dashboard one
<sto> I guess the answer is that I can't do it: https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1274947
<sto> I was thinking about using an alias from another domain, but lxc containers does not seem to get a dns name... is that so?
<sto> it would be enough to get the instance id as a name
<oxkipo> Hi what power type do I have to use with virtualbox?
<oxkipo> please may someone help me?
<kiko> sto: I believe in 1.8 that is fixed
<kristian27> Hi how can I setup virsh for virtualbox?
<kristian27> please may someone help me?
<kristian27> please may someone help me?
<mup> Bug #1473069 opened: Inconsistency of determining IP addresses in MAAS environment between hosts and LXC containers <addressability> <lxc> <maas-provider> <network> <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1473069>
<mup> Bug #1473069 changed: Inconsistency of determining IP addresses in MAAS environment between hosts and LXC containers <addressability> <lxc> <maas-provider> <network> <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1473069>
<mup> Bug #1473069 opened: Inconsistency of determining IP addresses in MAAS environment between hosts and LXC containers <addressability> <lxc> <maas-provider> <network> <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1473069>
<smoser> hey.
<smoser> {"distro_series": ["'wily' is not a valid distro_series.  It should be one of: '', 'windows/win2012hvr2', 'ubuntu/precise', 'ubuntu/trusty', 'ubuntu/utopic', 'ubuntu/vivid', 'custom/rhel7'."]}failed to start
<smoser> why doesnt it like wily.
<smoser> the images tab shows wily in imported
<roaksoax> smoser: 1.8 ?
<smoser> i got it. updated bug too
<smoser> https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1457499
<smoser> we can/should feed maas whatever data it needs in the stream.
<roaksoax> smoser: right but the releases is built from distro-series IIRC
<roaksoax> smoser: but yeah the streams shoudlo tell us that
<mup> Bug #1457499 changed: MAAS UI showing Wily images as 'wily' instead of as '15.10' <MAAS:Invalid> <maas (Ubuntu):Invalid> <https://launchpad.net/bugs/1457499>
<mup> Bug #1473167 opened: deploying node re-enlists regiond.log shows 'Unable to determine purpose for node' <MAAS:New> <https://launchpad.net/bugs/1473167>
#maas 2015-07-10
<mup> Bug #1473254 opened: MAAS 1.8 installer docs are outdated <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1473254>
<mup> Bug #1413388 opened: upgrade of MAAS removes local config for bind and breaks DNS <dns> <MAAS:Fix Committed by mpontillo> <MAAS 1.7:Fix Committed by mpontillo> <MAAS 1.8:Fix Committed by mpontillo> <maas (Ubuntu):New> <https://launchpad.net/bugs/1413388>
<mup> Bug #1470585 opened: Can't set a list of forwarders (BIND config) <MAAS:Fix Committed by rvb> <MAAS 1.7.6:Fix Committed by rvb> <MAAS 1.8:Fix Committed by rvb> <maas
<mup> (Ubuntu):New> <maas (Ubuntu Trusty):New> <maas (Ubuntu Utopic):New> <maas (Ubuntu Vivid):New> <maas (Ubuntu Wily):New> <https://launchpad.net/bugs/1470585>
<mup> Bug #1413388 changed: [SRU] upgrade of MAAS removes local config for bind and breaks DNS <dns> <MAAS:Fix Committed by mpontillo> <MAAS 1.7:Fix Committed by mpontillo> <MAAS 1.8:Fix Committed by mpontillo> <maas (Ubuntu):Fix Released> <maas (Ubuntu Trusty):New> <maas (Ubuntu Utopic):New> <maas
<mup> (Ubuntu Vivid):New> <maas (Ubuntu Wily):Fix Released> <https://launchpad.net/bugs/1413388>
<mup> Bug #1470585 changed: [SRU] Can't set a list of forwarders (BIND config) <MAAS:Fix Committed by rvb> <MAAS 1.7.6:Fix Committed by rvb> <MAAS 1.8:Fix Committed by rvb> <maas (Ubuntu):Fix
<mup> Released> <maas (Ubuntu Trusty):New> <maas (Ubuntu Utopic):New> <maas (Ubuntu Vivid):New> <maas (Ubuntu Wily):Fix Released> <https://launchpad.net/bugs/1470585>
<sto> Quick question... how do I tell MAAS to use a local Ubuntu mirror signed with my own key (I'm using reprepro to generate the mirror) once the nodes are deployed with curtin?
<sto> I found this http://askubuntu.com/questions/144393/how-to-let-maas-cloud-init-client-select-internal-mirror
<sto> But it seems outdated, unless curtin uses the debian-installer preseed
<sto> Looking at curtin code looks like using
<sto>     # apt_mirrors:
<sto>     #  ubuntu_archive: http://local.archive/ubuntu
<sto>     #  ubuntu_security: http://local.archive/ubuntu
<sto> could work, but I need to add my repos gpg keys
<kiko> sto: the bug you were referring to, which is a dupe of https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1382190 is not exactly what you were talking about (DNS entries for LXC)
<kiko> sto: I am pretty sure 1.8 gives you DNS entries for containers after the work rvba did
<kiko> sto: damn, my scrollback lost the GPT hints smoser gave you! argh
<smoser> kiko, http://irclogs.ubuntu.com/2015/07/10/%23maas.html
<smoser> adjust the date in that string appropriately
<smoser> http://irclogs.ubuntu.com/2015/07/08/%23maas.html
<kiko> I found it in my bip logs!
<mup> Bug #1473473 opened: curtin_userdata needs the proxy listed for third party drivers <MAAS:New> <https://launchpad.net/bugs/1473473>
<kiko> smoser, in what file would the block-meta: stanza go in /etc/maas?
<kiko> http://askubuntu.com/questions/646278/how-to-ask-curtin-to-use-gpt-instead-of-mbr-with-maas/646839#646839
<smoser> kiko,  /etc/maas/preseeds/curtin_userdata
<kiko> thanks
<kiko> smoser, anywhere outside of an existing stanza?
<kiko> i.e. just adding to the file?
<kiko> sto: http://askubuntu.com/questions/646278/how-to-ask-curtin-to-use-gpt-instead-of-mbr-with-maas/646839 -- thanks!
<smoser> yeah, end is fine.
#maas 2015-07-11
<mup> Bug #1473625 opened: Installing MAAS using 15.04 server ISO (amd64) on remote machine via virt-manager results in black screen <amd64> <apport-bug> <vivid> <maas (Ubuntu):New> <https://launchpad.net/bugs/1473625>
#maas 2016-07-11
<mup> Bug #1600720 opened: Maas doesn't honor DNS settings for a subnet for DHCP <MAAS:New> <https://launchpad.net/bugs/1600720>
<smoser> nturner, bah. in #cloud-init ping harlowja to get help or submit a merge proposal for 2.6 support. we do want to have that. sorry that it is broken.
<smoser> nturner, but older cloud-inits *should* work with newer maas, as precise is still supported and it does not have the reporting stuff. not even sure if trusty does.
<setuid> Where is 'maas-rack-controller', which provides 'maas-rack'? Doesn't seem to be in ANY repo or ppa.
<setuid> I'm stuck on the install docs which require this step to get maas running
<setuid> https://maas.ubuntu.com/docs/rack-configuration.html
<roaksoax> setuid: nothing provides maas-rack
<roaksoax> setuid: maas-rackd is a daemon
<roaksoax> setuid: oh you mean the maas-rack binary
<setuid> Right, the docs say to install maas-rack-controller, which does not exist
<setuid> it provides the maas-rack binary to manage the rack
<roaksoax> setuid: then you are not using 2.0
<setuid> I feel like I'm going in circles
<roaksoax> setuid: or xenial
<setuid> Right, this is Trusty
<setuid> Not going to Xenial until I know this works on Trusty
<roaksoax> setuid: yeah, you are looking at trunk docs
<roaksoax> setuid: https://maas.ubuntu.com/docs/rack-configuration.html
<roaksoax> https://maas.ubuntu.com/docs2.0/rack-configuration.html
<roaksoax> https://maas.ubuntu.com/docs1.9/rack-configuration.html -> doesn't exist
<roaksoax> setuid: you wont be able to install MAAS 2.0 in trusty
<setuid> Let me back up... I've been trying for a solid 4 weeks (since 6/6) to get Openstack installed, ANY version of Openstack (tried icehouse, jujo, kilo, liberty and mitaka) on ANY version of Ubuntu, using ANY version of these tools (openstack-install, conjure-up, juju, etc.)
<setuid> So far, the entire scope of that matrix, has not resulted in a single successful install
<setuid> I've tried on 3 baremetal Intel boxes, VirtualBox, VMware Workstation, ESXi and Fusion on Mac
<roaksoax> setuid: if you are using trusty, you want MAAS 1.9 , with juju 1.25.X
<setuid> Yep, it's whatever comes with the default repos + supported ppas
<roaksoax> setuid: and if you are using autopilot, you /need/ MAAS 1.9/juju 1.25.x
<setuid> the docs are wrong, the packages have missing components, it's a mess
<setuid> I just found this, which I'm following now: http://dinosaursareforever.blogspot.com/2014/06/manually-deploying-openstack-with.html
<roaksoax> setuid: right, so in MAAS, at least, you are looking at the wrong place
<roaksoax> setuid: if you are in MAAS 1.9, you need to look at https://maas.ubuntu.com/docs1.9/
<roaksoax> setuid: you may find some of the docs being out-of-date (we are fixing that), but the important stuff is there
<roaksoax> setuid: also, you shouldn't need to "install-shared-secret"
<roaksoax> setuid: if you are using a single MAAS, if you are using a MAAS with multiple rack/cluster controller, then you will need it
<setuid> I have a single baremetal box upon which I need to install a working openstack, under 14.04. This machine also dual-boots 16.04, where I'll do the version of opensstack there also
<setuid> So, so, SOOOO many gaps in almost every single howto and doc out there, it's really discouraging
<setuid> You get to step 17, then things go off the rails and you're screwed
<setuid> Stuck at creating the maas_internet host, the first maas server... because it doesn't tell you how or where to boot the machine, so DOA right there.
<setuid> *sigh*
<cafaroo> Hi, I'm using maas 1.9.3 for deployment of a HP C7000 enclosure. Is it possible to add the c7000 as a chassis or is chassis something else? (Im having errors with ipmi on the blades since they reset all users everytime i shut the chassis down)
 * setuid facepalms
<roaksoax> setuid: fwiw: http://maas.io/get-started
<setuid> btdt
<setuid> that's not relevant to 14.04
<setuid> http://maas.ubuntu.com/docs1.9/
<setuid> that's going to get me somewhat close
<roaksoax> cafaroo: a chassis is like a "moonshot"
<roaksoax> setuid: http://maas.io/get-started -> 14.04
<setuid> but there's 19 different ways to install this and none of them are consistently documented, nor do they work... I've done about 150 separate installs/teardowns in the last 4 weeks on this
<roaksoax> setuid: did you see http://maas.io/get-started ?
<roaksoax> setuid: i wonder why are you trying to install a shared secret in a rack controller when you are installing MAAS 1.9 in trusty, that doesn't have rack controllers ?
<roaksoax> for example
<roaksoax> setuid: 1st. sudo apt-get install maas
<setuid> I'm not even remotely close to the shared secret part of anything
<roaksoax> that will pull maas-region-controller and maas-cluster-controller (in trusty, using 1.9 PPA)
<roaksoax> setuid: exactly, cause you dont even need it
<setuid> Let me tear this env down and start clean, again.
<setuid> I should script this, I've done it a hundred times now... apt-get remove --purge, apt-get autoremove, dpkg -P, etc. lather. rinse. repeat.
<roaksoax> setuid: also what you were foloowing says: "If you install your first Rack Controller on the same system as the Region Controller, as is the case when you install the full âmaasâ ubuntu package, it will be automatically accepted by default (but not yet configured, see below). Any other Rack Controllers you set up will show up automatically after they have been manually added to MAAS."
<roaksoax> if you read, "Any *other* Rack Controllers you set up..."
<setuid> At this point, getting a working maas where I can get to the web interface would be a big leap
<roaksoax> setuid: so, on 14.04: sudo add-apt-repository ppa:maas/stable
<roaksoax> setuid: sudo apt-get update
<roaksoax> sudo apt-get install maas
<roaksoax> sudo maas-region-admin createadmin
<setuid> I've had the web interface working -once-, but couldn't provision machines, because the 'Minimum kernel' would not accept any of the choices proided
<roaksoax> setuid: http://localhost:5240/MAAS
<setuid> yep, that bit is wrong
<setuid> nothing is ever listening on 5420, that's old doc
<setuid> s
<setuid> it's at https://public-ip/MAAS now
<roaksoax> setuid: 5240 is the default port
<roaksoax> setuid: /MAAS is apache *forwarding* to :5240
<setuid> Not with the maas that is in the stable ppa which installs on trusty, nope
<setuid> nothing is listening on 5420, so not sure how a web request would get a response on that port
<setuid> localhost or any other interface
<roaksoax> setuid: /maas-http.conf:    ProxyPass /MAAS/ws "ws://localhost:5240/MAAS/ws" disablereuse=on
<setuid> give me a moment, tearing the env down and reinstalling from scratch
<roaksoax> maas-http.conf:    ProxyPass /MAAS/ws "ws://localhost:5240/MAAS/ws" disablereuse=on
<roaksoax> maas-http.conf:    ProxyPass /MAAS/ http://localhost:5240/MAAS/
<roaksoax> maas-http.conf:    ProxyPass /MAAS http://localhost:5240/MAAS/
<cafaroo> roaksoax: okey so i guess it will not work with c7000 then. Going to find another solution. Thanks!
<roaksoax> cafaroo: i'm guessing that each blade on the c7000 should be seen as individual machines no ?
<kiko> cafaroo, what roaksoax said -- it should work
<kiko> cafaroo, you just can't use the "add chassis" functionality if we don't support it natively
<kiko> but the individual nodes can just be PXE booted individually and that's it
<cafaroo> Kiko: Thank you, i know, it works induvidually now but when I power down the chassis all the nodes get their user information wiped...
<cafaroo> So i thought maybe chassis could work since the enclousure always has the same username/pw
<cafaroo> But when i'm in production hopefully the chassis will never power down :)
<kiko> cafaroo, does the enclosure username/password work to access the blades via IPMI?
<kiko> cafaroo, if it does, you can use that account in the MAAS settings instead
<kiko> otherwise, the chassis normally lets you create users
<cafaroo> I'll try it with the default OA password, that will probably work!
<setuid> roaksoax, configured the two interfaces (had an error that the internal one conflicted with the public one, deleted both, reconfigured exactly the same, now no error), now importing images. This is as far as I've gone before, so let's see what happens next.
<cafaroo> kiko: Nope, OA does not pass its default username/password to the blades (perhaps a setting).
<Karan> Does Maas need client machine need a harddrive to boot?
<Karan> Does MAAS Client machine need a HDD to boot and run?
<cafaroo> Kiko: So finally I got the ilo passwords for each induvidual blade (48x) and im putting them in maas :)..
<cafaroo> Im getting a PXE error when I am relasing a node. It's when I have "Erase nodes' disks prior to releasing." enabled. When node pxe boots I get an error "Could not find kernel image: ubuntu/amd64/hwe-x/trusty/no-such-image/boot-kernel". Is this a bug or my setup?
<setuid> If I'm adding new nodes through MAAS, on a host that has ZERO nodes running, how will I know the MAC address before the node is created by MAAS and booted?
<setuid> Chicken and egg problem... "Provide us with the MAC address of a machine we haven't built and deployed yet."
<roaksoax> setuid: did you try to "auto-enlist" them ?
<roaksoax> setuid: typically, in most organizations (if not all) administrators already have a list of servers with mac address and relevant stuf
<roaksoax> setuid: anyway, just let them pxe boot from MAAS and they will automatically appear there
#maas 2016-07-12
<mup> Bug #1602093 opened: maas webui error updating subnet mtu when dhcp is configured <MAAS:New> <https://launchpad.net/bugs/1602093>
<mup> Bug #1602177 opened: used ip addresses on the webui subnet page is offscreen <MAAS:New> <https://launchpad.net/bugs/1602177>
<mup> Bug #1602190 opened: Filtering by hostnames is likely to break for large deployments <MAAS:New> <https://launchpad.net/bugs/1602190>
<mup> Bug #1602190 changed: Filtering by hostnames is likely to break for large deployments <MAAS:Won't Fix> <https://launchpad.net/bugs/1602190>
<mup> Bug #1602190 opened: Filtering by hostnames is likely to break for large deployments <MAAS:New> <https://launchpad.net/bugs/1602190>
<mup> Bug #1602190 changed: Filtering by hostnames is likely to break for large deployments <MAAS:Won't Fix> <https://launchpad.net/bugs/1602190>
<gQuigs> does anyone have more details on why xenial is broken for commissioning on maas 1.9.3? (https://bugs.launchpad.net/maas/+bug/1573072)
<gQuigs> or could it use more debugigng work?
<roaksoax> gQuigs: probably becuase xenial is python3 and the commissioning scripts dont run on python3
<roaksoax> gQuigs: that said, you shouldn't have xenial as commissioning option
<gQuigs> ah, ok
<gQuigs> thanks!
<gQuigs> that makes sense
<kiko> cafaroo, hmm, needs some investigation then
<kiko> cafaroo, bladernr may know something about the chassis
<mup> Bug #1498503 changed: Not all maas related services removed with apt-get purge <cdo-qa> <MAAS:Opinion by cgregan> <https://launchpad.net/bugs/1498503>
<mup> Bug #1602412 opened: [2.0rc2] Network model misconfigurations can silently break DHCP services <MAAS:Triaged> <https://launchpad.net/bugs/1602412>
<mup> Bug #1602413 opened: [trunk] Support for ephemeral boot shouldn't need to use hwe_kernel <MAAS:New> <https://launchpad.net/bugs/1602413>
<mup> Bug #1592915 changed: [2.0b6,arm64] maas installs to USB drive if it is present instead of SSD <MAAS:Triaged> <https://launchpad.net/bugs/1592915>
<terje> how is: maas admin nodes-group list
<terje> executed in 2.x?
#maas 2016-07-13
<roaksoax> terje: cluster controllers/node-groups are deprecated in 2.0. Now we have "rack controllers"
<mup> Bug #1602468 opened: [1.9] loading initial data for maasserver: maas-region-admin reports duplicate key error during package install <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1602468>
<mup> Bug #1602477 opened: [2.0b1, UI] MAAS changes the order of DNS servers in the WebUI. <MAAS:Triaged> <MAAS 2.0:Triaged> <MAAS trunk:Triaged> <https://launchpad.net/bugs/1602477>
<mup> Bug #1602482 opened: [2.0rc2] Incorrect DNS records <MAAS:New> <https://launchpad.net/bugs/1602482>
<mup> Bug #1602486 opened: [2.0rc1] Rack controller filtering messages out of syslog doesn't work <MAAS:New> <MAAS 2.0:New> <MAAS trunk:New> <https://launchpad.net/bugs/1602486>
<mup> Bug #1602487 opened: [2.0 RC1] Deploying node not powered on - Unable to change power state to 'on' for node krastin: another action is already in progress for that node. <oil> <MAAS:New> <https://launchpad.net/bugs/1602487>
<mup> Bug #1602486 changed: [2.0rc1] Rack controller filtering messages out of syslog doesn't work <MAAS:New> <MAAS 2.0:New> <MAAS trunk:New> <https://launchpad.net/bugs/1602486>
<mup> Bug #1602487 changed: [2.0 RC1] Deploying node not powered on - Unable to change power state to 'on' for node krastin: another action is already in progress for that node. <oil> <MAAS:New> <https://launchpad.net/bugs/1602487>
<mup> Bug #1599523 opened: [SRU] MAAS 2.0rc2 to Xenial <maas (Ubuntu):New> <https://launchpad.net/bugs/1599523>
<mup> Bug #1599523 changed: [SRU] MAAS 2.0rc2 to Xenial <maas (Ubuntu):New> <https://launchpad.net/bugs/1599523>
<mup> Bug #1602486 opened: [2.0rc1] Rack controller filtering messages out of syslog doesn't work <MAAS:New> <MAAS 2.0:New> <MAAS trunk:New> <https://launchpad.net/bugs/1602486>
<mup> Bug #1602487 opened: [2.0 RC1] Deploying node not powered on - Unable to change power state to 'on' for node krastin: another action is already in progress for that node. <oil> <MAAS:New> <https://launchpad.net/bugs/1602487>
<mup> Bug #1602488 opened: [2.1rc1] AMT: If I quickly deploy and quickly release a machine, it ends up powered on <MAAS:New> <MAAS 2.0:New> <MAAS trunk:New> <https://launchpad.net/bugs/1602488>
<mup> Bug #1599523 changed: [SRU] MAAS 2.0rc2 to Xenial <maas (Ubuntu):New> <https://launchpad.net/bugs/1599523>
<mup> Bug #1602488 changed: [2.1rc1] AMT: If I quickly deploy and quickly release a machine, it ends up powered on <MAAS:New> <MAAS 2.0:New> <MAAS trunk:New> <https://launchpad.net/bugs/1602488>
<mup> Bug #1599523 opened: [SRU] MAAS 2.0rc2 to Xenial <maas (Ubuntu):New> <https://launchpad.net/bugs/1599523>
<mup> Bug #1599523 opened: [SRU] MAAS 2.0rc2 to Xenial <maas (Ubuntu):New> <https://launchpad.net/bugs/1599523>
<mup> Bug #1599523 changed: [SRU] MAAS 2.0rc2 to Xenial <maas (Ubuntu):New> <https://launchpad.net/bugs/1599523>
<mup> Bug #1602488 opened: [2.1rc1] AMT: If I quickly deploy and quickly release a machine, it ends up powered on <MAAS:New> <MAAS 2.0:New> <MAAS trunk:New> <https://launchpad.net/bugs/1602488>
<mup> Bug #1572340 changed: PXE boot fails when two interfaces are managed <cdo-qa> <cdo-qa-blocker> <pxe> <MAAS:Invalid> <https://launchpad.net/bugs/1572340>
<mup> Bug #1591250 changed: 1.9.3 changelog information missing from maas.ubuntu.com/docs1.9/changelog.html <cdo-qa> <doc> <MAAS:Fix Released> <https://launchpad.net/bugs/1591250>
<mup> Bug #1599523 changed: [SRU] MAAS 2.0rc2 to Xenial <verification-needed> <maas (Ubuntu):Fix Released> <maas (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1599523>
<mup> Bug #1602721 opened: [2.0rc2] Can't get node-results via cli/api <MAAS:New> <MAAS 2.0:New> <MAAS trunk:New> <https://launchpad.net/bugs/1602721>
<setuid> Anyone here using sstreams-mirror?
<setuid> I'm trying to figure out how to get simplestreams to sync -both- amd64 and i386 in the same command. If I run them in two separate commands, passing each arch, the second pass wipes out the mirror ffrom the first pass
<roaksoax> setuid: in the filter you'd do something like amd64|i386 or similar
<roaksoax> can't remember of the top of my head
<roaksoax> smoser: ^^ do you ?
<smoser> setuid, 'arch~(i386|amd64)'
<setuid> I've tried all of the obvious array expansions, without luck
<smoser> you have to do regex.
<setuid> hrm, ok... I'll give that one a shot. Tried , : space, and others... pipe it is!
<smoser> its regex
<smoser> i didn't write that. talk to larry wall i think
<smoser> it was the simplist immediately powerful well defined operator
<setuid> right, wasn't easy to find the parsing bit of simplestreams.py for what pcre they were using
<setuid> one moment, giving that a shot now
<setuid> Looks like its working... now if I could only do release and daily in the same pass but I'll add a second line for that
<setuid> it's not picking up xenial, only precise and trusty, even though I see xenial in the repo I'm pointing to
<setuid> https://images.maas.io/ephemeral-v2/daily/
<mup> Bug #1602721 changed: [2.0rc2] Can't get node-results via cli/api <MAAS:New> <MAAS 2.0:New> <MAAS trunk:New> <https://launchpad.net/bugs/1602721>
<setuid> passing in:  'release~(xenial|trusty|precise)'
<mup> Bug #1602721 opened: [2.0rc2] Can't get node-results via cli/api <MAAS:New> <MAAS 2.0:New> <MAAS trunk:New> <https://launchpad.net/bugs/1602721>
<mup> Bug #1602721 changed: [2.0rc2] Can't get node-results via cli/api <MAAS:New> <MAAS 2.0:New> <MAAS trunk:New> <https://launchpad.net/bugs/1602721>
<mup> Bug #1602721 opened: [2.0rc2] Can't get node-results via cli/api <MAAS:New> <MAAS 2.0:New> <MAAS trunk:New> <https://launchpad.net/bugs/1602721>
<terje> thansk roaksoax
<terje> I have an idea that I'm trying to persue. Just wish to vet it here.
<terje> I'm installing xenial on baremetal and installing maas there. Then, using uvtool, I'm creating an xenial VM, where I'd like to install juju-core.
<terje> and bootstrap that instance of juju to my instance of maas.
<terje> does this idea make sense or is there perhaps a better way to do that?
<setuid> terje, functionally, they're different machines to juju, so it shouldn't ma... wait, you're going to use juju inside a maas-managed kvm instance, to update maas?
<setuid> Why not use the baremetal and install maas in a kvm instance, then use a second kvm instance to run juju
<setuid> that way, you can swap out your main maas kvm instance with another as needed for rolling upgrades/downgrades/updates/testing
<setuid> If maas is installed on your baremetal box, you're locked in
<setuid>  Unless I misunderstood your goal
<mup> Bug #1594991 opened: [2.0RC1] MAAS displays every power query on the summarized view of node event log <oil> <MAAS:Triaged> <MAAS 2.0:New> <MAAS trunk:Triaged> <https://launchpad.net/bugs/1594991>
<setuid> smoser, Weird, I am trying to sync the daily images, but it's only getting trusty and precise, despite adding yakkety and xenial to the sstream command... and I can see them in the directory, so they ARE there
<setuid> https://images.maas.io/ephemeral-v2/daily/xenial/
<setuid> command I'm using is:
<setuid> sudo /usr/bin/sstream-mirror --keyring=/usr/share/keyrings/ubuntu-cloudimage-keyring.gpg https://images.maas.io/ephemeral-v2/daily/ /maas/images/ephemeral-v2/daily/ 'arch~(amd64)' 'subarch~(generic|hwe-t)' 'release~(yakkety|xenial)' --max=1 --verbose
<smoser> setuid, if you add a -v i think it will tell you that it filtered them out
<smoser> but its filtering out becauase subarch is the "primary subarch"
<smoser> subarches (plural) is a comma delimited list of subarches that are supported.
<smoser> so actually, the easiest thing for you to do  is to *drop* the subarch~ entirely
<smoser> and it will dtrt
<setuid> ah!
<setuid> for both daily and releases, I bet... trying that now
<setuid> Goes from 2.8Gb to 17Gb
<terje> setuid: ok, that's a good idea.
<terje> baremetal, +2 uvt-kvm instances (maas, juju)
<terje> only, uvt-kvm wants to use the 'default' network in libvirt (192.168.122/24).
<terje> so my maas server won't see the pxe requestws
<terje> so, prolly that's not going to work. :/
<mup> Bug #1556137 changed: Juju 2.0: cannot connect to LXC container when deploying bundle with LXC container placement with maas 1.9.1 as provider <2.0-count> <oil> <juju-core:Invalid> <MAAS:Invalid> <https://launchpad.net/bugs/1556137>
<mup> Bug #1556137 opened: Juju 2.0: cannot connect to LXC container when deploying bundle with LXC container placement with maas 1.9.1 as provider <2.0-count> <oil> <juju-core:Invalid> <MAAS:Invalid> <https://launchpad.net/bugs/1556137>
<mup> Bug #1556137 changed: Juju 2.0: cannot connect to LXC container when deploying bundle with LXC container placement with maas 1.9.1 as provider <2.0-count> <oil> <juju-core:Invalid> <MAAS:Invalid> <https://launchpad.net/bugs/1556137>
<terje> Hi smoser, I see you worked on this issue: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1563296
<terje> Is the fix still to add /etc/cloud/cloud.cfg.d/99-snappy-disable-network-config.cfg ?
<terje> even in xenial?
<mup> Bug #1602846 opened: 502 proxy errors after upgrading to MAAS 2.0 rc2 <oil> <MAAS:New> <https://launchpad.net/bugs/1602846>
<mup> Bug #1602848 opened: Spurious failure in test_get_hostname_ip_mapping_returns_fqdn_and_other <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1602848>
<mup> Bug #1602850 opened: Update Maas 2.0 Documentation to include the "maas-rack support-dump" feature <MAAS:New> <https://launchpad.net/bugs/1602850>
<mattrae> hi, where is the django controller for the api call that returns nodes interfaces to cloud-init for curtin?
<mup> Bug #1598358 opened: Node is started but not deployed <oil> <oil-2.0> <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1598358>
#maas 2016-07-14
<smoser> yeah. cluod-init cannot at this point configure snappy networking.
<smoser> snappy is in control
<mup> Bug #1603040 opened: "Create a superuser account" section on "Installing MaaS" documentation is outdated <MAAS:New> <https://launchpad.net/bugs/1603040>
<mup> Bug #1603040 changed: "Create a superuser account" section on "Installing MaaS" documentation is outdated <MAAS:Won't Fix> <https://launchpad.net/bugs/1603040>
<yaMAn> hi, please how can I deploy generated image? i see it in images tab but it's not in drop down menu when deploying node. thanks
<romain1> hi there
<romain1> I'm looking for a way to PXE-boot other systems than Ubuntu with MaaS. Like OpenBSD or CumulusLinux for my network equipment. Is there a way to do so ?
<rbasak> MAAS can deploy Fedora and Windows I think, right? So adding support for other stuff should be possible I think.
<rbasak> (or was it CentOS?)
<brendand> rbasak, CentOS
<roaksoax> CentOS, Windows and some other OS's
<roaksoax> but for that you need cloud-init and curtin working on whatever distro you want to deploy
<romain1> rbasak: would be great to be able to boot "raw" images without neccessarilly tweaking them for maas
<mup> Bug #1603147 opened: [2.0rc2] Commissioning dropdown is grey and checkmarks are missing <MAAS:In Progress by blake-rouse> <MAAS 2.0:Triaged by blake-rouse> <https://launchpad.net/bugs/1603147>
<mup> Bug #1603156 opened: [CI] Regiond requires restarting after setting proxy <MAAS:New> <https://launchpad.net/bugs/1603156>
<mattrae> mpontillo: so far RC2 is solving our problem with interfaces not coming up properly. we haven't seen any failed deployment since updating
<mpontillo> mattrae: glad to hear it! thanks.
<mup> Bug #1603198 opened: [2.0rc2] maasserver.websockets.base.HandlerNoSuchMethodError: node_actions <MAAS:Incomplete> <https://launchpad.net/bugs/1603198>
<terje> hi, this page: https://maas.ubuntu.com/docs2.0/maascli.html
<terje> references this command line example: uuid=$(maas <profile> node-groups list | grep uuid | cut -d\" -f4)
<terje> however, running: maas <profile> node-groups list
<terje> produces an error
<terje> I'm looking for the correct 2.0 syntax
<mup> Bug #1603211 opened: maas command line example not updated for 2.0 <MAAS:New> <https://launchpad.net/bugs/1603211>
#maas 2016-07-15
<acovrig> Iâm trying to setup MAAS and can get a client to PXE-boot, but it hangs at the ubuntu login screen, what (if any) credentials work for it?
<roaksoax> terje: documentation is in progress
<roaksoax> terje: node-groups doesn't exist anymore, this has been replaced by rack controllers
<roaksoax> terje: maas <user> rack-controllers read
<mup> Bug #1603466 opened: [2.0rc2] Commissioning node with gateway_link_v4 set fails. <MAAS:Triaged> <MAAS 2.0:Triaged> <https://launchpad.net/bugs/1603466>
<mup> Bug #1603469 opened: [2.0 RC2] While Releasing Trusty node Web UI incorrectly displays Xenial 16.04 <oil> <MAAS:New> <https://launchpad.net/bugs/1603469>
<mup> Bug #1603477 opened: [2.0] node details page not updated when domain name is changed via the api <MAAS:New> <https://launchpad.net/bugs/1603477>
<mup> Bug #1603563 opened: [2.0 RC2] Multiple failures to release nodes <oil> <MAAS:New> <https://launchpad.net/bugs/1603563>
<mup> Bug #1603509 opened: DHCP activation behaves differently between browsers <MAAS:New> <https://launchpad.net/bugs/1603509>
#maas 2016-07-16
<mup> Bug #1603590 opened: [2.0] maas should allow gateways in the fe80::/64 network <MAAS:New> <MAAS 1.9:New> <MAAS 2.0:New> <MAAS trunk:New> <https://launchpad.net/bugs/1603590>
<cafaroo> Hi im having some problems with my HP GbE2c switch. When maas tries to pxe boot i get ARP-timeout. Just changed from a cisco switch that worked fine so i know there is some configuration in the switch that is faulty. I have without success tried to configure "port fast forwarding" and "fast uplink convergence". Sholud STP be on or off? Anyone with any ideas?
<capslockwizard> I have a question regarding cloud-init
<capslockwizard> After deploying using maas...
<capslockwizard> Is there a way get the nodes to read and execute custom cloud-init config files from the maas server?
<capslockwizard> ?
#maas 2017-07-10
<mwe11> pmautils: @documentation: I had to search within the source code to find out how to create md-raid (set raid level) via commandline. I tried "raid1", "RAID1", "1", "RAID-1" at the end I found out to simply set "raid1" :D
<mwe11> It would be nice to have 1. documentation and 2. increased error-messages
<mwe11> not only "raid-level parameter is wrong" but "raid-level parameter is wrong. It should be one of "raid-1", raid-5", [...]"
<mwe11> It's defined in /usr/lib/python3/dist-packages/maasserver/enum.py
<kklimonda> I'm trying to use MAAS 2.2 pods with virsh driver, but shortly after I restart regiond the Virsh option from the Pod Type disappears
<magicaltrout> hello folks
<magicaltrout> maas testing this week
<magicaltrout> Node commissioning failure - 'cloudinit' running config-ntp with frequency once-per-instance <- I see that, which I also see https://bugs.launchpad.net/maas/+bug/1629578 and https://askubuntu.com/questions/872971/maas-2-1-commissioning-failure-in-cloudinit
<magicaltrout> anyone got any clues
<magicaltrout> /usr/sbin/ntpd: error while loading shared libraries: libcap.so.2: cannot stat shared object: Permission denied
<magicaltrout> nm found https://bugs.launchpad.net/maas/+bug/1697209
<gimmic> Is there a way to force a rescan of the dhcp environment? I have maas thinking some IPs are allocated to nodes which have a different static allocation
<gimmic> maas is providing the dhcp as well
<gimmic> I assumed 'map subnet' would take care of it, but apparently not
<gimmic> I see I can use maas cli to delete the static allocated interface, but I'm not sure how to remove the 'discovered' one
<gimmic> I ended up deleting the associated interface entirely and re-creating it after marking the node 'broken'.
<gimmic> Would be nice if the subnet mapping did some reconciling. I suspect that is a bug/oversight
<gimmic> Yeah I'm going to have to find a better way to clean this up. The nodes are deployed with static addresses but have 'observed' dhcp leases listed
<gimmic> If I delete the interface I have to re-create it(and mark the node as broken etc)
<mup> Bug #1703403 opened: regiond workers can use too many postgres connections <MAAS:In Progress by blake-rouse> <MAAS 2.2:Triaged by blake-rouse> <https://launchpad.net/bugs/1703403>
<gimmic> Anyone have a good way to clean up the 'observed' ip allocations?
<mup> Bug #1703406 opened: MAAS fails to detect Huawei-based server's power type <MAAS:New> <https://launchpad.net/bugs/1703406>
<gimmic> Is there a reason you can't change a machine from state "failed deployment" to "rescue mode" directly?
<gimmic> I have to Failed deployment -> mark broken -> rescue mode
<gimmic> Just did an update from 2.2 to 2.2.1 now I'm seeing "failed to commission" and "failed to enter rescue mode"
<gimmic> gonna reboot maas :|
<mup> Bug #1703462 opened: rack controller rejected by region <cdo-qa> <cdo-qa-blocker> <MAAS:Incomplete> <https://launchpad.net/bugs/1703462>
#maas 2017-07-11
<mup> Bug #1703406 changed: MAAS fails to detect Huawei-based server's power type <MAAS:Incomplete> <https://launchpad.net/bugs/1703406>
<zeestrat> Ahoy, what's the recommended upgrade approach from 2.1 to 2.2 when you have 2 region controllers in HA and a couple of rack controllers? I don't see anything on https://docs.ubuntu.com/maas/2.2/en/manage-ha
<zeestrat> Any specific order things should be upgraded in?
<mup> Bug #1703535 opened: power error on some servers with status "new" <dell> <ipmi> <power> <MAAS:New> <https://launchpad.net/bugs/1703535>
<mwe11> according to the bug https://launchpad.net/bugs/1703535 : Is it possible to include it into the official release? From my point of view it's not a feature request but a bug report. I spent a couple of hours to fix it in my environment :-(
<mup> Bug #1703535 opened: power error on some servers with status "new" <dell> <ipmi> <power> <MAAS:New> <maas (Ubuntu):New> <https://launchpad.net/bugs/1703535>
<kklimonda> it seems there is no network integration for virsh pods, is it planned for 2.3+ ?
<roaksoax> kklimonda: not for 2.3
<mup> Bug #1274527 changed: MAAS doesn't put its DNS server in resolv.conf <micro-cluster> <MAAS:Invalid> <maas (Ubuntu):Invalid> <https://launchpad.net/bugs/1274527>
<mup> Bug #1703535 changed: power error on some servers with status "new" <dell> <ipmi> <power> <MAAS:Triaged by andreserl> <MAAS 2.2:Triaged> <https://launchpad.net/bugs/1703535>
<mup> Bug #1703535 changed: power error on some servers with status "new" <dell> <ipmi> <power> <MAAS:Triaged by andreserl> <MAAS 2.2:Triaged> <https://launchpad.net/bugs/1703535>
<gimmic> I had to increase the backoff wait times on IPMI while using idrac7 on r620's
<gimmic> otherwise the power commands fail when using the shared LOM
<gimmic> if using the dedicated drac, it is faster, but using the shared NIC1, it is slower
<dannf> roaksoax: we have a freeipmi in x,y,z-proposed to fix bmc detection on some arm64 systems. i've tested it on one x86 server and found no regressions. Is there a way to enable it in MAAS CI for a run for larger coverage?
 * dannf wonders if that's a q for cgregan
 * D4RKS1D3 hi!
<mup> Bug #1664822 opened: [2.2] MAAS IPMI autodiscover should enable IPMI-over-LAN if disabled <MAAS:In Progress by andreserl> <maas (Ubuntu):New> <https://launchpad.net/bugs/1664822>
<roaksoax> dannf: is it in xenial-proposed ?
<dannf> roaksoax: yeah
<mup> Bug #1703661 opened: No ability to update MAAS configuration to match updates made on node for future re-deployment <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1703661>
<mup> Bug #1690781 changed: Compose machine failure: Start tag expected, '<' not found, line 1, column 1 <MAAS:Fix Released by newell-jensen> <https://launchpad.net/bugs/1690781>
<mup> Bug #1693644 changed: Enlistment does not validate min_hwe_kernel <MAAS:Fix Released by ltrager> <https://launchpad.net/bugs/1693644>
<mup> Bug #1690781 opened: Compose machine failure: Start tag expected, '<' not found, line 1, column 1 <MAAS:Fix Released by newell-jensen> <https://launchpad.net/bugs/1690781>
<mup> Bug #1693644 opened: Enlistment does not validate min_hwe_kernel <MAAS:Fix Released by ltrager> <https://launchpad.net/bugs/1693644>
<mup> Bug #1690781 changed: Compose machine failure: Start tag expected, '<' not found, line 1, column 1 <MAAS:Fix Released by newell-jensen> <https://launchpad.net/bugs/1690781>
<mup> Bug #1693644 changed: Enlistment does not validate min_hwe_kernel <MAAS:Fix Released by ltrager> <https://launchpad.net/bugs/1693644>
<gimmic> Is there a reason we can't edit storage while a node is marked as broken?
<roaksoax> tai/win 3
<rfolco> Hi, can MAAS add/commission/deploy LXC containers as nodes, or just VMs ? In https://docs.ubuntu.com/maas/2.1/en/installconfig-install, it suggests local containers can emulate real servers: "MAAS nodes also run as local containers".
<roaksoax> rfolco: no it can't
<roaksoax> rfolco: you can run MAAS inside a container
<rfolco> roaksoax, and from inside that container it manages kvm guests as nodes, right? Can I add kvm guests from outside that container ?
<rfolco> vlan maybe?
<roaksoax> rfolco: yes, you can actually add a machine that has lkvm/libvirt in it, as a pod, and MAAS could create VM's on the fly
<roaksoax> rfolco: the limitation is that networking is not yet sully supported
<rfolco> roaksoax, thanks. I'll give it a try.
<mup> Bug #1703671 opened: MaaS unable to power on Intel S2600 servers via IPMI, ipmipower command works fine <MAAS:New> <https://launchpad.net/bugs/1703671>
<mup> Bug #1657577 changed: [UI] 2.1.3: Dashboard page crashes <oil> <MAAS:Triaged> <https://launchpad.net/bugs/1657577>
<mup> Bug #1703673 opened: Device discovery page is enormous, takes a long time to load <ux> <MAAS:Triaged> <https://launchpad.net/bugs/1703673>
<xygnal_> how do i set boot device automatically, when i can only modify it in ready state?
<xygnal_> too early for commission, too late for deploy
<mup> Bug #1703686 opened: Rack Controller disconnection <registration> <MAAS:Triaged> <MAAS 2.2:Triaged> <https://launchpad.net/bugs/1703686>
<mpontillo> xygnal_: I didn
<xygnal_> didnt what?
<mpontillo> xygnal_: *didn't think you could set the boot device; MAAS just records whichever interface it last saw booting from the network. we don't really have control over which interface decides to do that
<mpontillo> (sorry, fat fingers)
<xygnal_> not network. disk.
<mpontillo> xygnal_: ah, that I'm not sure about off the top of my head. blake_r would know (but I think he's sick today)
<mpontillo> xygnal_: but again I would wonder about the BIOS boot order and whether or not we can change that
<xygnal_> its the boot and root i am setting
<xygnal_> i think only root needs ready state
<xygnal_> sda is NOT out root disk
<xygnal_> our
<mup> Bug #1703671 changed: MaaS unable to power on Intel S2600 servers via IPMI, ipmipower command works fine <ipmi> <MAAS:New> <https://launchpad.net/bugs/1703671>
<mup> Bug #1703689 opened: [2.2.1] When deploying servers with VLAN using IPv6 alias ifdown fails with cannot find device <curtin:New> <MAAS:Incomplete> <https://launchpad.net/bugs/1703689>
#maas 2017-07-12
<mup> Bug #1703712 opened: [2.3] IP addresses not listed for devices when they are 'Dynamic' <MAAS:Triaged> <https://launchpad.net/bugs/1703712>
<mup> Bug #1703713 opened: [2.3] Devices don't have a link from the DNS page <MAAS:Triaged> <MAAS 2.2:Triaged> <https://launchpad.net/bugs/1703713>
<mup> Bug #1690154 changed: block-curtin-poweroff doesn't work <MAAS:Expired> <https://launchpad.net/bugs/1690154>
<mup> Bug #1690154 opened: block-curtin-poweroff doesn't work <MAAS:Expired> <https://launchpad.net/bugs/1690154>
<mup> Bug #1690154 changed: block-curtin-poweroff doesn't work <MAAS:Expired> <https://launchpad.net/bugs/1690154>
<magicaltrout> hello folks, maas question
<magicaltrout> I can commission a node
<magicaltrout> but then when I deploy it doesn't PXE boot
<magicaltrout> any idea where to prod around?
<magicaltrout> hmm does if I restart
<magicaltrout> maybe it comes to life too quickly
<magicaltrout> scrap that next question:
<magicaltrout> https://gist.github.com/buggtb/21517dda16ba6b91fd40ebe2ae3763c8
<magicaltrout> curtin fails miserably when deploying a server
<magicaltrout> not sure why though, the disk seems to exist earlier in the boot
<magicaltrout> weird if i keep looking at /dev just prior to curtin running
<magicaltrout> the partition vanishes
<magicaltrout> centos images install though
<magicaltrout> just not xenial hwe
<magicaltrout> hmm
<magicaltrout> disabling EFI seemed to fix that
<magicaltrout> now grub fails...
<roaksoax> magicaltrout: do you mean that when you deploy, the machine installs fine, reboots, but it never boots into the OS ?
<roaksoax> magicaltrout: or you mean this is due to the curtin issue you found above ?
<magicaltrout> still something curtin based roaksoax
<magicaltrout> i get this
<magicaltrout> https://gist.github.com/buggtb/c3406963c12646115891ad41c92c569f
<magicaltrout> but a manual install works fine. I guess it finds the mmc paritioning a bit funky
<roaksoax> magicaltrout: yeah, I'd suggest you file a bug on the curtin project specifying the versions of curtin/maas in use, with the output of maas <user> machines get-curtin-config <system_id>
<magicaltrout> thanks roaksoax will do, posted to maas-devel on the off chance someone has an idea as well
<xygnal> mpontillo: roaksoax: still waiting on info for how to set by boot & root device in MAAS without having to do it manually. (cannot set during commission or deploying states)
<xygnal> s/by/my
<xygnal> though I think it's just root device that needs 'ready' state
<mup> Bug #1703845 opened: rackd should lower recheck interval on disconnect <MAAS:In Progress by blake-rouse> <https://launchpad.net/bugs/1703845>
<mup> Bug #1703845 changed: rackd should lower recheck interval on disconnect <MAAS:In Progress by blake-rouse> <https://launchpad.net/bugs/1703845>
<mup> Bug #1703845 opened: rackd should lower recheck interval on disconnect <MAAS:In Progress by blake-rouse> <https://launchpad.net/bugs/1703845>
<gimmic> Is there an issue with running Landscape on the MAAS box?
<gimmic> magicaltrout: Try booting into rescue and running wipefs, then deploy to the box
<gimmic> curtin seems to handle existing partition data poorly
<gimmic> I had duplicate vgs due to reusing hard drives with existing partitions on the nodes
<gimmic> 'sudo wipefs -a /dev/sd* -f;sudo wipefs -a /dev/mapper/* -f'
<gimmic> cleared up my issues, nuke it from orbit..
<roaksoax> gimmic: are you sure you are in the latest version of curtin ?
<roaksoax> what curtin version are you using ?
<roaksoax> jhave you filed a bug ?
<gimmic>   Installed: 0.1.0~bzr505-0ubuntu1~16.04.1
<gimmic> was up-to-date at least as to when I was tshooting that last week
<dannf> Odd_Bloke: does your team generate the ephemeral images used by MAAS directly? if so, do you know if you strip kernel modules out during that process?
<dannf> (LP: #1702976 is why I ask)
<Odd_Bloke> dannf: We run the code that generates the image, but the MAAS team own that code.
<Odd_Bloke> So I don't know. :)
<dannf> Odd_Bloke: got a pointer to that code? is it still lp:maas-images?
<Odd_Bloke> dannf: It is, yeah.
<dannf> Odd_Bloke: ok, perfect. thanks!
<Odd_Bloke> :)
<dannf> roaksoax: ^
<dannf> i'm guessing this is what we need: https://code.launchpad.net/~dannf/maas-images/lp1702976/+merge/327307
<mup> Bug #1703895 opened: BMC static allocated addresses are not associated with nodes in subnet list <MAAS:New> <https://launchpad.net/bugs/1703895>
<dannf> fixed a typo, now: https://code.launchpad.net/~dannf/maas-images/lp1702976/+merge/327308
<roaksoax> dannf: we dont generate kernels, we grab them from the archive
<dannf> roaksoax: see my MP
<xygnal>  roaksoax any ideas about my root device dilemma?
<roaksoax> dannf: uhmmmm wtf! we should be using the initrd from the archive
<dannf> roaksoax: there isn't an initrd in the archive, it is generated at installtime.
<roaksoax> xygnal: sorry, i was following the conversation. Basically, you want to change / ?
<roaksoax> dannf: http://archive.ubuntu.com/ubuntu/dists/xenial/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/
<gimmic> xygnal: you can set boot devices via IPMI
<roaksoax> e.g.
<dannf> roaksoax: well, there's a d-i initrd - but that's not what you need here
<dannf> roaksoax: booting that woudl boot d-i
<xygnal> no no no.  I am trying to set the boot *and* root device in MAAS so that it installs on the correct disk (sda is NOT the correct disk)
<xygnal> boot is not the problem really, its root disk that refuses to go forward if the node is not in 'ready' state
<xygnal> that means I cannot set it during commission and I cannot set it during deploy... so... WHEN can I set it without having outside cron jobs to look?
<xygnal> I wrote an endpoint that looks up the correct disk and sets it in MAAS via the MAAS API.  Problem is, I cannot find a place in the build process within MAAS where it would be able to run.
<roaksoax> xygnal: sorry, otp. give me a sec
<dannf> roaksoax: thx for the MP approval! would you also be able to merge it, or do we need a separate ack?
<roaksoax> dannf: do you have landing rights ? if you do, go for it
<dannf> roaksoax: i don't
<ltrager> dannf: in meeting right now will land it after
<dannf> ltrager: thx!
<ltrager> dannf: on ARM64 does uname -m output 'arm64'?
<gimmic> I just maas installed 50 identical nodes.. and 4 of them use eth0 rather than eno1
<gimmic> I wonder why they would use the traditional interface naming when using 16.04
<dannf> ltrager: no
<dannf> ltrager: aarch64
<roaksoax> xygnal: you can make change sto storage in 'ready' state (e.g, like partitions, bcache, etc). You can make filesystem changes on 'allocated'
<roaksoax> xygnal: the machine can be ready and you may want to change the boot/root
<roaksoax> xygnal: also, is this EFI or legacy ?
<roaksoax> xygnal: if it is legacy you do care which disk is the disk the bios uses as boot, which is the disk that you will have to install /boot/
<xygnal> legacy
<xygnal> and yes they need to be the same disk, as all the rest of the disks need to e 100% safe for the clients to use and wipe
<xygnal> we use one particular model of SSD for OS and unfortunately it cannot be re-arranged to be the first disk.
<roaksoax> xygnal: right, so that seems like you would have to put /boot in the disk that the bios will boto from and /root on your ssd
<xygnal> we have not had to do that
<xygnal> we are able to change which disk is booted first in the BIO
<xygnal> I have been setting boot and root to sdm for example and that has been working
<xygnal> THAT is working fine. The problem is taht I cannot set this information during commission or deployment, which means I have to actually schedule it outside of MAAS.  Not optimal.
<gimmic> [Errno 13] Permission denied: '/sys/class/block/md127/md/sync_action'
<gimmic> I've come to the conclusion curtin is garbage
<gimmic> xygnal: there's several instances where it would be great to be able to plug in basic OS commands at stages of deployment (post commission, pre-deployment, post deployment)
<ltrager> dannf: I've created a new MP which only includes the driver on ARM64, can you take a look?
<ltrager> dannf: https://code.launchpad.net/~ltrager/maas-images/lp1702976/+merge/327329
<dannf> ltrager: see my comment about uname -m
<ltrager> dannf: yes I changed it to using aarch64 and confirmed it was included when I did a test build on my system
<dannf> ltrager: oh - so on an x86 system uname retruend aarch64 in an aarch64 root?
<ltrager> dannf: Yes, maas-image-builder uses qemu to emulate an ARM64 system during build
<dannf> ltrager: personally, i'd still prefer dpkg --print-architecture. uname -m bites in lots of places - say, if we were building armhf images outside of maas-image-builders on an arm64 host
<dannf> ltrager: but lemme reply in the MP FTR
<mup> Bug #1703984 opened: Commissioning fail with local ntp server <MAAS:Incomplete> <https://launchpad.net/bugs/1703984>
<mup> Bug #1703992 opened: [2.3] Device discovery shows duplicate entry for the same device <MAAS:Triaged> <https://launchpad.net/bugs/1703992>
<mup> Bug #1703992 changed: [2.3] Device discovery shows duplicate entry for the same device <MAAS:Triaged> <https://launchpad.net/bugs/1703992>
<mup> Bug #1648635 changed: [2.x] Commissioning fails due to low ipmi wait_time <ipmi> <papercut> <MAAS:Triaged> <https://launchpad.net/bugs/1648635>
<mup> Bug #1703992 opened: [2.3] Device discovery shows duplicate entry for the same device <MAAS:Triaged> <https://launchpad.net/bugs/1703992>
<mup> Bug #1648635 opened: [2.x] Commissioning fails due to low ipmi wait_time <ipmi> <papercut> <MAAS:Triaged> <https://launchpad.net/bugs/1648635>
<mup> Bug #1648635 changed: [2.x] Commissioning fails due to low ipmi wait_time <ipmi> <papercut> <MAAS:Triaged> <https://launchpad.net/bugs/1648635>
<agrebennikov> roaksoax, we can discuss it over here if you wish :)
<agrebennikov> will be much easier and faster
<agrebennikov> ltrager, regarding the bug you've just asked me about (commissioning)
<ltrager> agrebennikov: can you confirm that your machines do have access to the Ubuntu archives and can install lldpd and ntp?
<agrebennikov> just did
<agrebennikov> si yes, they download all the stuff
<agrebennikov> moreove
<agrebennikov> *over
<agrebennikov> sometimes I have my comissioning passed
<agrebennikov> as I mentioned in the description
<agrebennikov> it seems all the matter of how fast the time can snc with the internal ntp
<agrebennikov> the reason I'm so strict about it is that yesterday I spent about half a day struggling with ntp
<agrebennikov> and it turned out then before ntp sync happens I had all commands starting with "systemctl" failed with timeout
<agrebennikov> ltrager, ^^
<ltrager> agrebennikov: so it seems that interacting with systemd is taking a long time in your environment
<agrebennikov> when I set up correct ntp server - started working immediately
<agrebennikov> when it passes ntp sync - it is immediate response
<ltrager> agrebennikov: So it only fails when an unreachable NTP server is used?
<agrebennikov> it seems so
<agrebennikov> when it could never reach ntp - yes, I thought systemd is completely broken
<agrebennikov> then I changed ntp server to a reachable one
<agrebennikov> now I can pass commissioning from 2 or 3 attempt
<agrebennikov> when I log into the host during the commissioning I clearly see that the lldp is installed
<agrebennikov> but the service doesn't run
<agrebennikov> if I run it manually - works just fine
<agrebennikov> unfortunately I just got my env broken, my jumphost went down
<ltrager> agrebennikov: so do you need to be able to use MAAS in an environment that doesn't have access to an external NTP server?
<agrebennikov> but you guys can try on your own, as I said if you specify unreachable ntp server in settings and deny access to ntp.ubuntu.com
<agrebennikov> no, I'm not. Current ntp works just fine
<agrebennikov> I don't know how to explain it better :(
<agrebennikov> in the beginning server always wants to connect to ntp.ubuntu.com
<agrebennikov> until cloud init or whatever injects proper settings to ntp.conf
<ltrager> agrebennikov: okay I think I understand where the problem is. systemd has its own built in NTP client(timedatactl) which I believe is configured for ntp.ubuntu.com. cloud-init replaces it with ntp so this might be a bug in systemd. I'll experiment a bit
<agrebennikov> great
<agrebennikov> hopefully you'll find something :)
<agrebennikov> check this screenshot out: https://snag.gy/h3LrXj.jpg
<agrebennikov> yeah, it is systemd-timesync who is trying to connnect
<agrebennikov> (it is just screen leftovers from the broken host unfortunately)
<agrebennikov> ltrager, &^^
<ltrager> agrebennikov: I suspect its getting hung up on daemon-reload due to ntp trying to run again and holding up any commands to systemd.
<ltrager> agrebennikov: I need to confirm that and see if daemon-reload is still needed
<agrebennikov> well, yesterday I was trying stuff like "systemctl -l" and it didn't work eather
<agrebennikov> anyway, I'm heading off, hopefully will get my jumphost fixed in the morning. Please let me know if I need to try anything else tomorrow
<agrebennikov> thanks ltrager!
<ltrager> agrebennikov: np, I'll update the bug report with anything I find
#maas 2017-07-13
<mup> Bug #1704026 opened: [2.3] Strange error when registering external rack controller <MAAS:Triaged> <https://launchpad.net/bugs/1704026>
<mup> Bug #1704026 changed: [2.3] Strange error when registering external rack controller <ha> <MAAS:Triaged> <https://launchpad.net/bugs/1704026>
<mup> Bug #1704026 opened: [2.3] Strange error when registering external rack controller <MAAS:Triaged> <https://launchpad.net/bugs/1704026>
<mup> Bug #1704028 opened: [2.3] Registering a second region api causes strange traceback <MAAS:New> <https://launchpad.net/bugs/1704028>
<mup> Bug #1704028 changed: [2.3] Registering a second region api causes strange traceback <MAAS:New> <https://launchpad.net/bugs/1704028>
<mup> Bug #1704028 opened: [2.3] Registering a second region api causes strange traceback <MAAS:New> <https://launchpad.net/bugs/1704028>
<agrebennikov> ltrager, hello, did you have a chance to play around the issue we discussed yesterday?
<roaksoax> agrebennikov: he is investigating
<mup> Bug #1704176 opened: [2.3] django.core.exceptions.ValidationError: ['xenial has no kernels available.'] <MAAS:Triaged> <https://launchpad.net/bugs/1704176>
<mup> Bug #1664822 changed: [2.2] MAAS IPMI autodiscover should enable IPMI-over-LAN if disabled <MAAS:Fix Committed by andreserl> <MAAS 2.2:Triaged by andreserl> <https://launchpad.net/bugs/1664822>
<agrebennikov> great, thanks roaksoax
<ltrager> agrebennikov: So in my environment I blocked all network access and configured commissioning to use a proxy for apt so packages could still be installed
<ltrager> agrebennikov: that worked fine I'm trying to break DNS for everything but the archives to see if thats it
<ltrager> agrebennikov, roaksoax: So I disabled DNS and only allowed access to the archive via a proxy and commissioning and ntp testing all work fine, no systemd slow downs
<agrebennikov> ltrager, what do you see in the syslog in the node?
<agrebennikov> I mean complaints from systemd-tymesync regarding ntp.ubuntu.com
<ltrager> agrebennikov: I actually don't have entries for ntp.ubuntu.com, on the settings page can you see if 'Use external NTP servers only' is checked?
<agrebennikov> yes, I did that
<agrebennikov> but even with that I have lots of complaints specifically from systemd-timesync
<agrebennikov> which still wants to connect to ntp.ubuntu
<ltrager> agrebennikov: are you using the latest images from http://images.maas.io/?
<agrebennikov> I assume so since from what I understand it checks for new images constantly
<agrebennikov> and I see it in the log of either region or rack controller
<ltrager> agrebennikov: okay I was just checking if you were using mirrored images
<agrebennikov> I'm going to rebuild my maas node right now since the entire kvm host with that vm was destroyed
<agrebennikov> unfortunately...
<agrebennikov> so I'll have fresh brand new installation in a couple of hours
<agrebennikov> with the latest images
<agrebennikov> and if I still observe same issue I'll try to gather the logs from it
<ltrager> agrebennikov: ok if you run into the issue again could you try to install strace and run strace systemctl daemon-reload
<agrebennikov> the problem is that the issue happens during the commissioning only
<agrebennikov> once it failed and the tyme is synced - it works finr
<agrebennikov> *fine
<agrebennikov> but I'll try
<mup> Bug #1704212 opened: MAAS marks node 'Deployed' before sshd is up <cdo-qa> <cloud-init:New> <MAAS:New> <https://launchpad.net/bugs/1704212>
<agrebennikov> ltrager, will try my best once I got my jumphost back
<agrebennikov> hopefully in an hour or so
#maas 2017-07-14
<mup> Bug #1704243 opened: Failed to change the boot order to PXE - session timeout <MAAS:Incomplete> <https://launchpad.net/bugs/1704243>
<drecute> Hi. I need help apply a patch again 2.1.5 release
<pmatulis> drecute, what patch?
<drecute> @pmatulis https://code.launchpad.net/~andreserl/maas/+git/maas/+merge/327339
<drecute> we're on 2.1.5 and experiencing this issue: https://bugs.launchpad.net/maas/+bug/1704243
<pmatulis> drecute, it's going to be a while before that makes it to 2.1. but other people will know better. also, i do believe that 2.2 supersedes 2.1. so it could be that 2.1 will not be patched b/c it's not supported
<drecute> You're right that 2.1 won't be patched. But the patch isn't working for 2.2 yet. https://bugs.launchpad.net/maas/+bug/1609496
<drecute> Only 2.3.0. Not sure about the stability of that yet
<pmatulis> it will probably be backported to 2.2 soon enough
<drecute> Do you know someone working on it? Probably I can help
<pmatulis> drecute, how can you help on it?
<drecute> by testing?
<pmatulis> drecute, right ok
<roaksoax> drecute: you can apply the same patch from 2.3 to your installation, that code hasn;t changed since 2.1 maybe even 2.2
<roaksoax> drecute: the release to include that fix will be 2.2.2
<drecute> ok will do. wish me luck
<drecute> I'm using this resource, https://help.ubuntu.com/community/UpdatingADeb
<roaksoax> drecute: is your issue the same as https://bugs.launchpad.net/maas/+bug/1704243 ? I mean, you also get the errors 'session timeout' ?
<drecute> I hope I'm on the right track?
<roaksoax> drecute: do you know how to apply patches manually ?
<drecute> roaksoax: correct
<drecute> yes I do.
<drecute> roaksoax: Yes. That's my issue. I reported it
<roaksoax> drecute: ok gotcha, you can apply the patch manually and test it
<roaksoax> drecute: sudo vim /usr/lib/python3/dist-packages/provisioningserver/drivers/power/ipmi.py
<roaksoax> drecute: make the change manually, save the file
<roaksoax> sudo maas-rackd restart
<roaksoax> and that should be it
<drecute> I'm just changing the timeout to (30, 120, 600) right?
<roaksoax> drecute:  wait_time = (4, 8, 16, 32) -> change it to that so you can test the official patch
<drecute> On 2.1. Dont have maas-rackd?
<drecute> but have maas-rack
<roaksoax> it does, it should
<drecute_> roaksoax: Sorry. got disconnected. didn't get your last message
<drecute_> roaksoax: sudo service maas-rackd restart
<drecute_> worked. boss-kodiak: Status transition from DEPLOYING to DEPLOYED
<drecute_> Thanks
<drecute_> You rock roaksoax
<mup> Bug #1704444 opened: [2.2] MAAS API returns 500 internal server error instead of raising actual error <cdo-qa> <MAAS:Triaged> <MAAS 2.2:Triaged> <https://launchpad.net/bugs/1704444>
<roaksoax> drecute_: awesome!
<roaksoax> drecute_: it will be released as part of 2.2.2
<drecute_> sweet
<mup> Bug #1704444 changed: [2.2] MAAS API returns 500 internal server error instead of raising actual error <cdo-qa> <MAAS:Triaged> <MAAS 2.2:Triaged> <https://launchpad.net/bugs/1704444>
<mup> Bug #1702438 changed: [2.2] No way to specify protocol when adding a VMware chassis <cpe> <cpe-sa> <MAAS:Won't Fix> <https://launchpad.net/bugs/1702438>
<mup> Bug #1704243 changed: Failed to change the boot order to PXE - session timeout <MAAS:Incomplete> <https://launchpad.net/bugs/1704243>
<mup> Bug #1704444 opened: [2.2] MAAS API returns 500 internal server error instead of raising actual error <cdo-qa> <MAAS:Triaged> <MAAS 2.2:Triaged> <https://launchpad.net/bugs/1704444>
<mup> Bug #1702438 opened: [2.2] No way to specify protocol when adding a VMware chassis <cpe> <cpe-sa> <MAAS:Won't Fix> <https://launchpad.net/bugs/1702438>
<mup> Bug #1704243 opened: Failed to change the boot order to PXE - session timeout <MAAS:Incomplete> <https://launchpad.net/bugs/1704243>
<mup> Bug #1702438 changed: [2.2] No way to specify protocol when adding a VMware chassis <cpe> <cpe-sa> <MAAS:Won't Fix> <https://launchpad.net/bugs/1702438>
<mup> Bug #1704243 changed: Failed to change the boot order to PXE - session timeout <MAAS:Incomplete> <https://launchpad.net/bugs/1704243>
<mup> Bug #1704483 opened: IPMI fails to power up node on commision Ubuntu 16.04 <MAAS:New> <https://launchpad.net/bugs/1704483>
<mup> Bug #1704489 opened: nonce has already been used error when adding a machine <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1704489>
<mup> Bug #1704501 opened: can't change which fabric a vlan belongs to <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1704501>
<mup> Bug #1704501 changed: can't change which fabric a vlan belongs to <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1704501>
<mup> Bug #1704501 opened: can't change which fabric a vlan belongs to <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1704501>
#maas 2017-07-15
<mup> Bug #1704517 opened: Deploy status of 2 nodes <MAAS:New> <https://launchpad.net/bugs/1704517>
<mup> Bug #1649501 changed: No rack controllers can access the BMC of node <maas (Ubuntu):Expired> <https://launchpad.net/bugs/1649501>
<mup> Bug #1649501 opened: No rack controllers can access the BMC of node <maas (Ubuntu):Expired> <https://launchpad.net/bugs/1649501>
<mup> Bug #1649501 changed: No rack controllers can access the BMC of node <maas (Ubuntu):Expired> <https://launchpad.net/bugs/1649501>
<mup> Bug #1704538 opened: package maas-region-controller 2.2.0+bzr6054-0ubuntu2~17.04.1 failed to install/upgrade: subprocess installed pre-removal script returned
<mup> error exit status 1 <amd64> <apport-package> <need-duplicate-check> <package-from-proposed> <zesty> <maas (Ubuntu):New> <https://launchpad.net/bugs/1704538>
<Deep_> Hi
<Deep_> Hi
<mup> Bug #1704538 changed: package maas-region-controller 2.2.0+bzr6054-0ubuntu2~17.04.1 failed to install/upgrade: subprocess installed pre-removal script returned error exit status 1 <amd64> <apport-package> <package-from-proposed> <zesty> <maas (Ubuntu):Won't Fix> <https://launchpad.net/bugs/1704538>
#maas 2018-07-09
<mup> Bug #1780728 opened: [2.5] Pod usage graphs do not reflect overcommit quota <MAAS:Triaged> <https://launchpad.net/bugs/1780728>
<mup> Bug #1780728 changed: [2.5] Pod usage graphs do not reflect overcommit quota <MAAS:Triaged> <https://launchpad.net/bugs/1780728>
<mup> Bug #1780728 opened: [2.5] Pod usage graphs do not reflect overcommit quota <MAAS:Triaged> <https://launchpad.net/bugs/1780728>
<adham> hello everyone, do anyone why would maas no longer power on/off kvm machines?
#maas 2018-07-10
<mup> Bug #1779970 changed: Cannot find cloud-init datasource error when adding a node through a new rackd controller <MAAS:Invalid> <https://launchpad.net/bugs/1779970>
<sentinel-prime> *crickets*
#maas 2018-07-11
<mup> Bug #1781241 opened: rack controller remained in degraded state <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1781241>
<mup> Bug #1781275 opened: fio does not report metrics when run on bionic <MAAS:Triaged> <MAAS 2.4:Triaged> <https://launchpad.net/bugs/1781275>
<mup> Bug #1781275 changed: fio does not report metrics when run on bionic <MAAS:Triaged> <MAAS 2.4:Triaged> <https://launchpad.net/bugs/1781275>
<mup> Bug #1781275 opened: fio does not report metrics when run on bionic <MAAS:Triaged> <MAAS 2.4:Triaged> <https://launchpad.net/bugs/1781275>
#maas 2018-07-12
<mup> Bug #1781361 opened: Updating 'service_set' of rack controller using API <MAAS:New> <https://launchpad.net/bugs/1781361>
<mup> Bug #1781361 changed: Updating 'service_set' of rack controller using API <MAAS:Invalid> <https://launchpad.net/bugs/1781361>
<mup> Bug #1781464 opened: [2.5] When running unit tests, MAAS log should be printed to the console <MAAS:Triaged> <https://launchpad.net/bugs/1781464>
<xygnal_> we cant seem to run recent centos images without cloud-init failing to finish/check into maas.
<xygnal_> did anything change? old images seem to work
<mup> Bug #1772616 changed: Duplicate MAC or hostname causes MAAS to confuse rack controllers <sts> <MAAS:Opinion> <https://launchpad.net/bugs/1772616>
<mup> Bug #1772616 opened: Duplicate MAC or hostname causes MAAS to confuse rack controllers <sts> <MAAS:Opinion> <https://launchpad.net/bugs/1772616>
<mup> Bug #1772616 changed: Duplicate MAC or hostname causes MAAS to confuse rack controllers <sts> <MAAS:Opinion> <https://launchpad.net/bugs/1772616>
<roaksoax> xygnal_: what cloud-init version is that ?
<roaksoax> xygnal_: are these the maas provided images ?
<roaksoax> xygnal_: also, did you ever transition to 2.4 ?
<xygnal_> yes we are 2.4.  that is when the problem started.
<roaksoax> xygnal_: i woudl check that /etc/maas/rackd.conf points to the right IP first
<xygnal_> not untouched cents image, but based off it with no modifications to cloud init.
<xygnal_> that would cause old images to deploy but not new ones?
<roaksoax> xygnal_: no not really. Unless the new images are missing a driver or something along the lines
<roaksoax> xygnal_: but that said, looking at our CI jobs
<roaksoax> xygnal_: i can confirm that the last centos test run was 11 hours ago, and no issues
<xygnal_> just checked.  ip is correct.
<xygnal_> we also caught the new image trying to connect to the internet for centos repos we did NOT add ourselves
<xygnal_> which we had not witnessed before
<xygnal_> whh
<xygnal_> which could never work, firewall
<xygnal_> what do maas built in proxy settings cover and not cover?
<mup> Bug #1771885 opened: bionic: static maas missing search domain in systemd-resolve configuration <bionic> <network> <cloud-init:Won't Fix> <juju:Fix Released by ecjones> <juju 2.3:Fix Released by ecjones> <MAAS:New> <MAAS 2.3:New> <MAAS 2.4:New> <https://launchpad.net/bugs/1771885>
<roaksoax> xygnal_: the built in proxy is just a caching proxy really
#maas 2018-07-13
<mup> Bug #1781598 opened: [2.4] Subnets tab is too slow <performance> <MAAS:Triaged> <https://launchpad.net/bugs/1781598>
<xygnal_> roaksoax:   it seems the built-in centos images are not having this problem with finishing deployment, but our custom ones are.
<xygnal_> what curtin version is needed for 2.4, and has anything in curtin changed that requires us to change *our* custom userdata file?
<xygnal_> roaksoax: one of the problem we saw was that it was runing yum commands in the chroot installer, and stalling.  would UI proxy settings cause those to go through the squid proxy?
<roaksoax> xygnal_: iirc, we dont sent any rpm specific config when deploying centos
<mup> Bug #1781662 opened: [2.5] Unable to upgrade from 2.5 when apache2 is already installed <MAAS:New> <https://launchpad.net/bugs/1781662>
<mup> Bug #1781666 opened: [2.5] Rack controller install leaves nginx running on <MAAS:New> <https://launchpad.net/bugs/1781666>
#maas 2018-07-14
<KingJ> Is there any way to get MAAS to handle multi-homed routing on provisioned clients? My nodes have several interfaces as part of an Openstack deployment, but I need them to reply on the same interface as incoming packets. Currently, even if traffic comes in on a certain interface, it'll go out on a different one that the default route is attached to.
<KingJ> https://bugs.launchpad.net/maas/+bug/1597541 covers roughly my scenario and was fixed a while back, but i'm not seeing it taking effect in 2.4.
<KingJ> For example, in my case i've got two subnets configured with a default route, and one with a static route. The provisioned machine only has a single routing table across all NICs and as a result routing is inconsistent.
#maas 2018-07-15
<mup> Bug #1771418 changed: Commissioning VMs get stuck in 'Testing' <cdo-qa> <foundations-engine> <MAAS:Expired> <https://launchpad.net/bugs/1771418>
#maas 2019-07-11
<seffyroff> roaksoax, i updated the ticket I opened on the issue
<seffyroff> https://bugs.launchpad.net/maas/+bug/1836089
<roaksoax> seffyroff: i've replied on your discourse post
<roaksoax> seffyroff: you should attach rackd.log while the machine pxe's
<seffyroff> ok sure thing.  And thanks for replying :)
<seffyroff> logs attached
<seffyroff> https://bugs.launchpad.net/maas/+bug/1836089
<seffyroff> and to be clear the machine I'm attempting to pxeboot is metal, not VM.  and it is not EFI
<bitfehler> hi everyone! I am trying to deploy a Debian image with MAAS. I had it working perfectly fine with 2.4 (the default bionic package). Now I tried with 2.6 (from maas stable ppa), and I can't get it to work anymore. Curtin seems to be overwriting the apt sources in the target image, which i do not want.
<bitfehler> i tried messing with /etc/maas/preseeds/curtin_userdata_custom (that made it work with 2.4) and /etc/maas/preseeds/curtin_userdata (just in case), but it didn't help
<bitfehler> i am not sure how to get exect seed data for curtin as rendered by maas, when i requests the URL i see in the logs like "/MAAS/metadata/curtin/2012-03-01/user-data", i get "Not authenticated as a known node." when trying to curl it
<bitfehler> if anyone has any pointers, i'd much appreciate it. also happy to post specific output
<bitfehler> basically curtin is running apt-get update in the target system and it fails because it tries to retrieve package URLs like "http://archive.ubuntu.com/ubuntu stretch InRelease"
<bitfehler> disabled the curthooks stage for now guess i'll have to do my own postprocessing Â¯\_(ã)_/Â¯
#maas 2019-07-12
<ivve> hey guys, i just upgraded to maas 2.6 from 2.5. dhcp relay just stopped working via vlans, anyone else experienced this?
<ivve> tried on a second maas and same thing happend
<ltrager> ivve: I haven't seen that. Please open a bug at https://bugs.launchpad.net/maas and include details of your network topology and MAAS logs
#maas 2020-07-06
<mup> Bug #1886524 opened: /var/lib/libvirt/maas-images is left behind after dpkg purge <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1886524>
<mup> Bug #1886524 changed: /var/lib/libvirt/maas-images is left behind after dpkg purge <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1886524>
<mup> Bug #1886524 opened: /var/lib/libvirt/maas-images is left behind after dpkg purge <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1886524>
#maas 2020-07-07
<mup> Bug #1886671 opened: Deployment fails when iLO virtual NIC is enabled <MAAS:New> <https://launchpad.net/bugs/1886671>
<mup> Bug #1886671 changed: Deployment fails when iLO virtual NIC is enabled <MAAS:New> <https://launchpad.net/bugs/1886671>
<mup> Bug #1886671 opened: Deployment fails when iLO virtual NIC is enabled <MAAS:New> <https://launchpad.net/bugs/1886671>
#maas 2020-07-08
<mup> Bug #1886849 opened: DNS SOA query returns nobody.example.com <MAAS:New> <https://launchpad.net/bugs/1886849>
<mup> Bug #1886850 opened: [feature] MAAS should encrypt the BMC credentials <MAAS:New> <https://launchpad.net/bugs/1886850>
<mup> Bug #1886866 opened: UI reports incorrect status for enlisting nodes <MAAS:New> <https://launchpad.net/bugs/1886866>
<mup> Bug #1886866 changed: UI reports incorrect status for enlisting nodes <MAAS:New> <https://launchpad.net/bugs/1886866>
<mup> Bug #1886866 opened: UI reports incorrect status for enlisting nodes <MAAS:New> <https://launchpad.net/bugs/1886866>
<mup> Bug #1886866 changed: UI reports incorrect status for enlisting nodes <MAAS:New> <https://launchpad.net/bugs/1886866>
<mup> Bug #1886866 opened: UI reports incorrect status for enlisting nodes <MAAS:New> <https://launchpad.net/bugs/1886866>
#maas 2020-07-09
<mup> Bug #1886972 opened: Non admin user is incorrectly informed image is configured as the commissioning release but it is unavailable in the configured streams <MAAS:New> <https://launchpad.net/bugs/1886972>
<mup> Bug #1886994 opened: Bionic/Focal VMs get the same machine-id <sts> <MAAS:New> <systemd:New> <https://launchpad.net/bugs/1886994>
<mup> Bug #1886994 changed: Bionic/Focal VMs get the same machine-id <sts> <MAAS:New> <systemd:New> <https://launchpad.net/bugs/1886994>
<mup> Bug #1886994 opened: Bionic/Focal VMs get the same machine-id <sts> <MAAS:New> <systemd:New> <https://launchpad.net/bugs/1886994>
<mup> Bug #1886994 changed: Bionic/Focal VMs get the same machine-id <sts> <MAAS:Won't Fix> <https://launchpad.net/bugs/1886994>
<mup> Bug #1886994 opened: Bionic/Focal VMs get the same machine-id <sts> <MAAS:Won't Fix> <https://launchpad.net/bugs/1886994>
<mup> Bug #1886994 changed: Bionic/Focal VMs get the same machine-id <sts> <MAAS:Won't Fix> <https://launchpad.net/bugs/1886994>
<mup> Bug #1886994 opened: Bionic/Focal VMs get the same machine-id <sts> <MAAS:Won't Fix> <https://launchpad.net/bugs/1886994>
<mup> Bug #1886994 changed: Bionic/Focal VMs get the same machine-id <sts> <MAAS:Won't Fix> <https://launchpad.net/bugs/1886994>
<mup> Bug #1887096 opened: not able to install MAAS from snap on ppc64le <MAAS:New> <The Ubuntu-power-systems project:New> <https://launchpad.net/bugs/1887096>
#maas 2020-07-10
<mup> Bug #1887104 opened: CERTIFICATE_VERIFY_FAILED will occur when using 'maas configauth' with snap env <sts> <MAAS:New> <https://launchpad.net/bugs/1887104>
<mup> Bug #1887104 changed: CERTIFICATE_VERIFY_FAILED will occur when using 'maas configauth' with snap env <sts> <MAAS:New> <https://launchpad.net/bugs/1887104>
<mup> Bug #1887104 opened: CERTIFICATE_VERIFY_FAILED will occur when using 'maas configauth' with snap env <sts> <MAAS:New> <https://launchpad.net/bugs/1887104>
<mup> Bug #1887104 changed: CERTIFICATE_VERIFY_FAILED will occur when using 'maas configauth' with snap env <sts> <MAAS:New> <https://launchpad.net/bugs/1887104>
<mup> Bug #1887104 opened: CERTIFICATE_VERIFY_FAILED will occur when using 'maas configauth' with snap env <sts> <MAAS:New> <https://launchpad.net/bugs/1887104>
<mup> Bug #1887104 changed: CERTIFICATE_VERIFY_FAILED will occur when using 'maas configauth' with snap env <sts> <MAAS:New> <https://launchpad.net/bugs/1887104>
<mup> Bug #1887104 opened: CERTIFICATE_VERIFY_FAILED will occur when using 'maas configauth' with snap env <sts> <MAAS:New> <https://launchpad.net/bugs/1887104>
<mup> Bug #1472626 opened: MAAS should provide an easy way to add PPAs on a per-system or per-tag basis <wishlist> <MAAS:Confirmed> <https://launchpad.net/bugs/1472626>
#maas 2020-07-11
<mup> Bug #1863323 changed: MAAS did not detect any storage devices during commissioning <tests> <MAAS:Expired> <https://launchpad.net/bugs/1863323>
<mup> Bug #1873962 changed: Machines can have inconsistent testing status <MAAS:Expired> <https://launchpad.net/bugs/1873962>
<mup> Bug #1863323 opened: MAAS did not detect any storage devices during commissioning <tests> <MAAS:Expired> <https://launchpad.net/bugs/1863323>
<mup> Bug #1873962 opened: Machines can have inconsistent testing status <MAAS:Expired> <https://launchpad.net/bugs/1873962>
<mup> Bug #1863323 changed: MAAS did not detect any storage devices during commissioning <tests> <MAAS:Expired> <https://launchpad.net/bugs/1863323>
<mup> Bug #1873962 changed: Machines can have inconsistent testing status <MAAS:Expired> <https://launchpad.net/bugs/1873962>
<mup> Bug #1887250 opened: LXD machine failed testing <lxd> <MAAS:New> <https://launchpad.net/bugs/1887250>
