#maas 2012-07-02 <roaksoax> rvba: howdy! <rvba> Hello roaksoax. <roaksoax> rvba: I was wondering, how's the progress on functionality <roaksoax> with celery <roaksoax> and stuff <roaksoax> what's currently being used, not being used <rvba> roaksoax: we're really in mid-air. None of the celery stuff (to replace cobbler) has bben tested yet. The preseed generation is done. The TFTP stuff, the DHCP stuff and the DNS are in the works as we speak. <roaksoax> rvba: ok, so it is safe to say it is still using cobbler <rvba> roaksoax: yes. <roaksoax> rvba: alright then, I'll try to get a quantal upload now then. thanks for the info <rvba> Welcome. <allenap> roaksoax: Hi there. Do you fancy packaging another Python lib? It's a simple one, it doesn't even have a setup.py. https://github.com/shylent/python-tx-tftp <roaksoax> allenap: sure <allenap> roaksoax: For 12.04.1 we can probably ship it as part of maas, instead of as a separate package, if that's a problem. <allenap> roaksoax: Thank you! <roaksoax> allenap: ah yeah we are gonna have to discuss all of that for precise backports <allenap> roaksoax: When do we need to have that discussion? <roaksoax> allenap: dunno, but I meant in general terms that the backport of maas to precise will need to be discussed eventually <roaksoax> allenap: as I don't yet know whether it iwll be a SRU or backport, etc <allenap> roaksoax: Okay. Maybe that can wait until Julian is back ;) <roaksoax> allenap: yeah I guess that will come from Daviey though <allenap> roaksoax: Ah, right, got you. <roaksoax> rvba: have you seen this? http://pastebin.ubuntu.com/1071439/ <roaksoax> rvba: that's archive version of maas in qunatal <rvba> roaksoax: looks like something I fixed last week: django.middleware.csrf.CsrfResponseMiddleware is not supported anymore. <roaksoax> rvba: alright, so this means we do need a newer released in archives asap <rvba> roaksoax: maybe CsrfResponseMiddleware is still referenced from a config file. <roaksoax> rvba: that's the maas veron currentlu in archives (same version as precise) <rvba> roaksoax: I removed the reference to CsrfResponseMiddleware in src/maas/settings.py at revision 695. <roaksoax> rvba: alright, we should be good then <rvba> The last package I checked on Quantal had no such problem. <roaksoax> rvba: right, but i'm talking about the package in quantal archives, which is the same we have in precise release <roaksoax> which is bzr408 i think <rvba> Ah, I see. <roaksoax> rvba: btw.. we have yui3 in the archives, the Debian maintainer managed to upload it last week <rvba> roaksoax: \o/ * roaksoax just waiting for it to build to upload a new maas rev to quantal <roaksoax> Daviey: ok so yui3 is in the archives! Contributed to Debian Maintainer and he was able to uplaod it to Debian last week and it got synced this morning <roaksoax> Daviey: i'll upload maas now and will file the MIR's for the component mismatches <Daviey> roaksoax: awesome!! #maas 2012-07-03 <roaksoax> Daviey: howdy! So I was wondering if something about the backporting/SRU'ing of MAAS has been discussed yet? <Daviey> roaksoax: no, still a little early <roaksoax> Daviey: right, but my point being is that we are introducing dependencies that are not even in precise's archive <roaksoax> Daviey: so was just wondering if a plan was drafted to deal with that <roaksoax> we can't simply be shipping more stuff with MAAS source <roaksoax> IMHO <allenap> Daviey: In the fullness of time, is the plan to do ephemeral (via iSCSI) boot, and allow ubiquity to install from that? <rvba> Daviey: looks like the default apparmor profile will prevent named to read the files in /var/cache/maas/bind don't you think? I was trying to run a stupid (read with minimal configuration) dns server on a non standard port as a non-privileged <rvba> user and then I realized apparmor won't allow that. <rvba> Daviey: do you have any idea how to circumvent that problem? <Daviey> allenap: we won't be using ubiquity this cycle <allenap> Daviey: For 13.04 perhaps? <Daviey> rvba: just use the bind location for now.. <Daviey> allenap: right <allenap> Ta. <rvba> Daviey: that means we can't run a stupid bind instance as part of the dev environment, or even in a fixture :(. <Daviey> arse <Daviey> rvba: join #ubuntu-hardened <rvba> We can live with it, but it reduce our ability to test things. <rvba> reduces* <allenap> Daviey, rvba: Does the apparmor profile apply if running bind as a different user? (/me has never used apparmor). <rvba> allenap: definitely does. <rvba> allenap: the profile is linked to the executable. <allenap> Grumble. <allenap> rvba: It'll allow any file under /etc/bind and /var/cache/bind, so perhaps use /var/cache/bind/maas instead of /var/cache/maas/bind? <rvba> allenap: Daviey says maybe we can have a named.d directory. But in the mean time, you're right, we will use /var/cache/bind/maas I think. #maas 2012-07-04 <allenap> czajkowski: Hello! Do you include askubuntu questions in the round-robin? <czajkowski> allenap: I do usualy, there are 2 there and I've asked Daviey to help there as one is there since June and unanswered which originally went on a round robin once. <allenap> czajkowski: Cool, ta. <czajkowski> allenap: but LP questions is usually what Julian does and he's not here this week so wanted them looked at <czajkowski> allenap: http://askubuntu.com/questions/tagged/maas lists all the tagged maas ones. <allenap> czajkowski: Ah ha, right, I'm meant to be doing things in his stead. I assumed you'd be handing out LP questions too. Sorry about that. <czajkowski> allenap: no worries, just there are 3 in LP, and there are 3 of you so figured that was easier this week <czajkowski> allenap: https://answers.launchpad.net/maas 3 open, you rvba and jtv got one each. <jtv> czajkowski: not the ones you emailed about? <czajkowski> jtv: those are the ones I mailed about . <jtv> Ah OK #maas 2012-07-05 <czajkowski> rvba: morning <rvba> \o czajkowski <czajkowski> rvba: I have one more Q in for you. I suspect more will come in over the next 2 days and the others will get another one each. https://answers.launchpad.net/maas/+question/202282 <rvba> czajkowski: k. <rbasak> I got a failure on "make test": http://paste.ubuntu.com/1076131/ - fixed by installing libpq-dev as specified by the error. This needs to be added to HACKING.txt I presume? <rbasak> BTW, the detail in HACKING.txt is awesome and just saved me tons of time. I really appreciate it being there. Every upstream should have something so detailed. <rvba> rbasak: thanks for reporting that. I'll fix HACKING.txt. <rbasak> np <jtv> Daviey: can you help us out with a dev question? We're dealing with approaches to updating DNS zone files for changing node IPs, and we're just not sure what the uses and requirements are. <jtv> roaksoax or smoser maybe? <Daviey> jtv: ok <Daviey> jtv: Can you state the problem? <jtv> The problem is that we're trying to implement the âupdate DNS based on the latest IP address information for the nodesâ story but we don't know what those DNS updates are needed for. <jtv> Which leaves us without criteria for evaluating solutions. <jtv> The particular point we're stuck on is the latency/robustness/throughput tradeoff: how soon do we need DNS to be updated, and how important is that? <Daviey> jtv: Hmm <jtv> And of course if we don't know why we need this at all, then things suddenly become very easy indeed. :) <Daviey> well, it's actually not super-quick-urgent stuff. The metadata service provides the hostname, which overrides the local hostname.. which would normally be set at install time <Daviey> The issue arises mostly when one node tries to talk to another node. <Daviey> jtv: Writing out a base A record zone file, loading it into bind, go home. <Daviey> also-notifying the slaves might be a little too much.. <jtv> You mean notifying the DNS slaves? <Daviey> yeah <Daviey> in the named.local you can put, also-notify X.X.X.X, X.X.X.X, X.X.X.X; for each zone, and it will ping the slaves for an update <Daviey> but that can be cron'd from the slaves to just update regulary <jtv> Daviey: so this is half-a-minute stuff rather than half-a-second stuff? <Daviey> jtv: oh, most certainly <jtv> Wow, that certainly puts things in a different light. Thanks! <Daviey> jtv: it's not uncommon for this to take 15 mins. <jtv> Well crucially, you're saying that's not a big problem? :-) <Daviey> when people talk about 'DNS propagation' they either mean the TTL to expire on clients OR the time it takes to push out to the slave DNS servers <jtv> Yes, we figured that bit out â the missing bit was what kind of service was actually required. <jtv> I'm writing it up now, before they kick me out of this coffee shop. Thanks again! <Daviey> jtv: Yeah, crucially the node knows about it's self via meta-data service <Daviey> It's other nodes contacting that node at speed, which could be problematic <jtv> That's the bit we need to know about though. <Daviey> but i can't imagine going from dns name change -> production service in under 60s <jtv> Putting a number on it is good. Thanks. <jtv> Really have to stop here! <Daviey> o/ <rbasak> For faster stuff, there are dynamic DNS updates. Perhaps cloud-init could do them? <jtv> nn people! <jtv> rbasak: too late. :-P The question wasn't how we can do this cleverly. Clever is often bad! The question was what was required. * jtv really is off now. <rbasak> I generally see "avoid race conditions" as an automatic requirement, because they almost always come back to bite. <allenap> rbasak: +1 ... if you want to comment, I've CC'd jtv's follow-on from this discussion to private-canonical-maas, with my response. * rbasak looks <rbasak> allenap: thanks. I don't think I have anything more to add. Speed of deployment with juju was my concern also. <allenap> rbasak: Cool. <rbasak> anyway I'm just a bystander :) <pmatulis> is there a non-devel m/l for maas? <allenap> rbasak: No you're not! A lot of this we're building for your ARM stuff :) <rbasak> :) <rbasak> Yes for ARM, but not for DNS! <allenap> Ah, fair enough. * allenap writes "ARM does not need DNS" in feature document. <rbasak> BTW, you'll be pleased to hear the the test suite almost completely smoothly on ARM. <allenap> \o/ <rbasak> Oh, you mean I didn't tell you about how ARM servers do DNS differently? :-P <allenap> rbasak: It'll be QA that breaks hard on ARM. <allenap> rbasak: With Yellow Pages, right? <rbasak> I was kidding. It's exactly the same <rbasak> You can use yp if you want <allenap> Do not want. <rbasak> Userland is pretty much all the same on ARM. Just minor porting issues. And Java issues. <roaksoax> Daviey: the DNS *is* important <roaksoax> Daviey: juju accesses the nodes based on hostnames <roaksoax> if juju can't resolve to a hostanem, then uju doesn't work <Daviey> roaksoax: right, i'm saying that if it doesn't happen within the first 60 seconds of a node being commissioned.. it's pretty safe. <Daviey> it won't make the world fall apart if i add a node, and it's not resolvable within the first 60 seconds. <Daviey> I can't imagine juju will be usable within that time. <roaksoax> Daviey: right, as long as juju can handle it we should be fine <roaksoax> Daviey: anyways, did you see the missing file if I remove the sphinx-issue tracker dep? <roaksoax> smoser: where's your bug about the oauth issues? <Daviey> roaksoax: i didn't see it no.. is it all good and gone? <roaksoax> Daviey: if I remove the build-dep, then this file is missing for python-celery-doc: /usr/share/doc/python-celery-doc/html/_static/issuetracker.css <Daviey> roaksoax: I think that is safe.. <roaksoax> Daviey: alright then, I'll ditch the Dep then <Daviey> roaksoax: wait 2 <roaksoax> Daviey: sure:) <Daviey> roaksoax: did you check that issuetracker.css isn't referenced in the new docs? <Daviey> I think that is added to the html files at build time, but haven't confirmed <roaksoax> Daviey: i'm rebuilding the packages to confirm. * roaksoax hates having a crappy network <roaksoax> Daviey: ye it seems it doesn't get referenced <roaksoax> Daviey: so we should be good to remove it <roaksoax> Daviey: so I'll go ahead with it <roaksoax> Daviey: do you agree? http://paste.ubuntu.com/1076635/ <Daviey> roaksoax: yep <Daviey> roaksoax: you checked the generated docs don't include the issuetracker.css? <roaksoax> Daviey: yep: (a) Current one: http://paste.ubuntu.com/1076673/ (b) patched one: http://pastebin.ubuntu.com/1076676/ <Daviey> roaksoax: cool! <Daviey> go go go <roaksoax> Daviey: lol, haven't heard the gogogo! since I last played Counter Strike few years back lol <Daviey> roaksoax: Contact Front, Wait out. <roaksoax> lol <Daviey> roaksoax / smoser: Can you work out what changes need to be done to use the ephemeral environment for enlistment. I'm expecting little more than adding a few entries to the kernel cmd line for cloud-init to do the enlistment. <Daviey> (still maintaining seperate cd based enlistment) <roaksoax> Daviey: it would be similar to the boot image really <roaksoax> Daviey: run a script on boot to try to enlist <Daviey> roaksoax: right, but the key is making cloud-init be the handler <Daviey> roaksoax: so cloud-init invokes maas-enlist <roaksoax> Daviey: yeah so should be even simpler then <roaksoax> Daviey: cloud-init should simply invoke maas-enlist with the arguments needed and that's it <Daviey> roaksoax: Then MAAS just needs the default preseed change, should be trivial <Daviey> roaksoax: right.. i can't imagineit's super complicated <roaksoax> Daviey: shouldn' <roaksoax> Daviey: shouldn't be. I guess it would just need to be different meta-data <Daviey> roaksoax: well, the meta-data cpuld be provided from the kernel cmd line <roaksoax> Daviey: yeah, but we either provide a different URL for where to get the meta-data, or we modify the meta-data in the process <roaksoax> Daviey: err, I think we would just need to ,provide enlistment meta-data <roaksoax> Daviey: has it being thought of making enlistment+comissioning one single step? <Daviey> roaksoax: That is the next thing :) <Daviey> roaksoax: so.. a kernel cmd line 'metadata service' is just as valid as a http one <roaksoax> Daviey: right, so that means you want to send the metadata in the kernel command line then? <Daviey> roaksoax: yep <roaksoax> Daviey: wouldn't it be easier to have the metadata in the MAAS server and just send a URL where to be obtained from? <Daviey> roaksoax: Added complexity IMO. <Daviey> The metadata currently detects what metadata data to supply based on oauth credentials <Daviey> As this is a new node, there are no creds <Daviey> So... That requires additional upstream work <Daviey> Note, that the metadata url still have to be provided via kernel cmd line.. So it's an extra leap for no sound reason IMO <roaksoax> Daviey: right, but it is simpler to provide a URL than metadata through the kernel command line. Either way, we only need to pass MAAS server IP address basically <roaksoax> Daviey: and the hostname that the image obtains <roaksoax> Daviey: from the DNS server <roaksoax> if there's one <roaksoax> from DNS or DHCP <Daviey> roaksoax: hmm yeah <ahasenack> hi, is there a way to release a node back into the pool via the maas UI? <ahasenack> I see only "delete" which might be relevant, but it's greyed/disabled <dpb___> Hi all -- how do I release a maas node? <roaksoax> ahasenack: there's none, that's done via juju <ahasenack> roaksoax: you mean it's done via the api <roaksoax> ahasenack: or the api <ahasenack> ok <ahasenack> roaksoax: if I do a "cobbler system remove", maas might crash? <ahasenack> that is the equivalent of "delete" probably, which is grayed out for a reason <roaksoax> ahasenack: removing from cobbler is deleting a system in maas, deleting it in cobbler might be harmful to maas <ahasenack> roaksoax: ok <ahasenack> roaksoax: there is no command-line api tool for maaas, right? <roaksoax> ahasenack: that's in progress <ahasenack> ok <roaksoax> ahasenack: you want to set back to ready a node that's been allocated? <ahasenack> roaksoax: yes <roaksoax> ahasenack: how was it allocated in the first place? <ahasenack> roaksoax: just booting and accepting it in the maas ui <roaksoax> ahasenack: that leaves the node in Ready state <roaksoax> 1. first boot -> enlist <roaksoax> 2. 2nd boot -> commission <roaksoax> that leaves the node in Ready state <ahasenack> hm, it said it was allocated to "ubuntu", my user <roaksoax> allocated state means that you used juju deploy/juju bootstrap, <ahasenack> no juju involved <roaksoax> uhmmm * roaksoax checks <ahasenack> I could have done some weird things the first time, just poking around <roaksoax> IIRC ready state is the state when it has been commissioned <ahasenack> but that wasn't the point anyway, just wanted to know how to put it back in the pool <ahasenack> and the answer is "using the same tool that allocated it in the first place" <ahasenack> roaksoax: thanks <roaksoax> yw #maas 2012-07-06 <rbasak> jtv: around? <rbasak> jtv: never mind I think I'm OK <jtv> Hi rbasak <jtv> Yes, I'm around. <jtv> Call in 10 minutes though. <rbasak> jtv: it was a path issue. HACKING.txt says to run sudo ./scripts/maas-import-isos etc, but those scripts now expect a "maas" comamnd to be in the path. Adding to the local environment doesn't work since sudo doesn't pass it, but sudo PATH=... ./scripts/mass-... worked for me. <jtv> rbasak: I'll update the HACKING.txt to mention that, thanks. <ehw> hey, guys -- is there a maas / juju specific mailing list? <melmoth> after playing with an environment, i destroy it; create a new maas key, and juju boostrap <melmoth> now, i reboot the node where zookeper is supposed to be installed, but it s not reprovisionned; no pxe boot reply from the maas server <melmoth> it boot on the system already on disk. i can ssh to it, but juju status does not work: <melmoth> http://pastebin.com/73jNXbuc <melmoth> looks to me zookeper is not "working" (i know nothing about zookeper). How can i get back a juju environment without having to reinstall my whole maas server ? <smoser> Daviey, roaksoax reading above. <smoser> i think that i disagree with the "kernel command line metadata service" <smoser> you can seed some stuff from the kernel command line, but the kernel command line is not idea for passing complex data of any sort. <smoser> (but there is some stuff in cloud-init that could work). <smoser> i'd rather suggest we use the same basic mechanism that is included now. <Daviey> smoser: Okay, whatever you suggest.. note, it's only a url that needs to be passed <smoser> the to-be-enlisted node boots with 'url=http://maas/some/default' <smoser> right <smoser> ? <smoser> i hope to ahve that changd to 'cloud-config-url=http://maas/some/enlist' or something <smoser> then that carries payload of really what to do. <Daviey> smoser: the extra network hop seems worth it? <rvba> Daviey: roaksoax We just fixed a Critical bug in MAAS' 1.0 branch. Would it be possible for you guys to make release a new version of the package in precise? <rvba> https://bugs.launchpad.net/maas/+bug/1021382 <ubot5> Ubuntu bug 1021382 in MAAS "The COMMISSIONING_SCRIPT setting uses a relative path." [Critical,Fix committed] <rvba> s/make release/release/ <rvba> allenap: no news from Daviey/roaksoax, I'll talk to them on Monday morning first thing. * rvba creates a card. <allenap> rvba: Cool. <Daviey> i'm here.. but can't talk <Daviey> yes, we can do that <rvba> All right then. <roaksoax> rvba: i'm here what <roaksoax> s up? <roaksoax> rvba: oh just saw.. it didn't hightlight me :) <rvba> roaksoax: We fixed a Critical bug in MAAS 1.0. <roaksoax> rvba: could you open a bug in LP andassign it to me ? <rvba> roaksoax: sure. <roaksoax> rvba: has this fix also been pushed to quantal? <roaksoax> err, trunk? <rvba> roaksoax: yes, see the two branches linked to the bug: https://bugs.launchpad.net/maas/+bug/1021382 <ubot5> Ubuntu bug 1021382 in MAAS "The COMMISSIONING_SCRIPT setting uses a relative path." [Critical,Fix committed] <rvba> roaksoax: do you really need another bug filed? maybe I could just assign that bug to you? <roaksoax> rvba: just did. I added a <roaksoax> rvba: just did. I added a "Also affects distribution" <rvba> Ah, right. <adam_g> using MAAS + Juju, where would provider errors be logged on the MAAS side? <roaksoax> adam_g: should be on /var/log/maas/maas.log <roaksoax> win 6 * robbiew has aquired 10 IPMI cards for our microserver kit....bam! <roaksoax> robbiew: \o <roaksoax> robbiew: \o/ <roaksoax> too bad I don't have them to play with them :( <robbiew> heh...me neither <robbiew> waiting on shipment to arrive from negronjl :P #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 (930)970-5854 -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 gregory37@example.net> <allenap> roaksoax: Where did you find that? <roaksoax> allenap: launchpad/// <roaksoax> allenap: 31. By shylent <gregory37@example.net> 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
{'channel': 'maas', 'month': 7}