#maas 2013-04-22
<bigjools> roaksoax: did you see https://code.launchpad.net/~allenap/maas/remove-ipmi-optimisation/+merge/160146
<roaksoax> bigjools: yeah... did you see this: http://pastebin.ubuntu.com/5594094/
<roaksoax> bigjools: i just upgraded a machine from quantal t raring and seeing that error
<bigjools> looking
<bigjools> roaksoax: is that with the latest power fix?
<roaksoax> bigjools: i believe so yes
<bigjools> they tested it in the lab
<bigjools> and it was ok
<bigjools> so - confused
<roaksoax> i'm gonna revert it and see what happens
<bigjools> where are you running that?
<roaksoax> bigjools: this is virsh btw, not ipmi
<roaksoax> in a lab
<roaksoax> bigjools: maybe this is the issue: http://bazaar.launchpad.net/~maas-maintainers/maas/trunk/revision/1456
<bigjools> roaksoax: why is ipmi set as the power type for a VM?
<roaksoax> bigjools: is not ipmi, it is virsh
<bigjools> roaksoax: that revno is not a problem, it is doing the right thing
<bigjools> so you have a failure in the virsh script
<bigjools> it needs to be debugged
<roaksoax> bigjools: yeah the virsh script hasn't really changed, so it shouldn't fail
<bigjools> sorry - I didn't realise you were talking about virsh all of a sudden :)
<roaksoax> hehe
<bigjools> roaksoax: it was probably failing before and we didn't know
<roaksoax> yeah this is our virtual-maas
<bigjools> now we know
<bigjools> roaksoax: could just be exit status on script
<roaksoax> bigjools: i'm thinking that it might be not having access to virsh
<roaksoax> that's what I'm thinking
<bigjools> the same code works with ipmi and friends
<bigjools> we never tested virsh very much as it's not "metal" :)
<bigjools> and now you're using it a lot more
<roaksoax> bigjools: ok apparently is virsh issue
<bigjools> phew
<roaksoax> i mean not having permission for virsh
<roaksoax> but that's strange since there's a sudoers file for it
<bigjools> roaksoax: we could do with more info printed in that error
<roaksoax> indeed
<roaksoax> bigjools: http://paste.ubuntu.com/5594116/ --> tha obviously doesn't fail - this does: http://pastebin.ubuntu.com/5594122/
<roaksoax> bigjools: so probably permissions
<bigjools> roaksoax: agreed
<roaksoax> i'll investigate tomorrow im off now
<bigjools> roaksoax: cheers
<mwhudson> bigjools: good morning
<bigjools> wotcha mwhudson
<mwhudson> bigjools: i installed maas on calxeda the other day
<mwhudson> bigjools: mostly it worked fine but i got a bit confused about a few things
<bigjools> understandable :)
<mwhudson> bigjools: the biggest one was that juju defaults to asking for an amd64 node for bootstrap
<mwhudson> and it took me a long time to figure out this was why it wasn't getting an instance
<bigjools> that's not very nice if it, why should it care I wonder
<bigjools> of it*
<bigjools> which juju?
<mwhudson> py
<bigjools> weird then
<bigjools> does the Go version work on ARM? :)
<mwhudson> i ended up adding logging statements to the maas api server to print out the arguments...
<mwhudson> which was a bit sad-making
<mwhudson> bigjools: i don't think so
<bigjools> :/
<mwhudson> bigjools: the other thing i wanted to bug you about was that ages ago you said that maas would soon gain the ability to splat a tarball onto disk rather than running debian-installer
<mwhudson> bigjools: did that happen?
<bigjools> mwhudson: it's WIP.  roaksoax and smoser are working on the installer, the MAAS changes are done though.
<mwhudson> ok
<mwhudson> is there a blueprint i can subscribe to or anything?
<bigjools> hmmm not on my list
#maas 2013-04-23
<mwhudson> bigjools: oh, the other thing that was confusing me was whether i should set the nodes to pxe or disk boot by default
<bigjools> mwhudson: always pxe
<mwhudson> or if it doesn't matter and maas always runs "chassis bootdev $arg" as appropriate anyway
<mwhudson> ok
<bigjools> maas will make the node DTRT
<mwhudson> bigjools: does maas work to deploy quantal on arm server do you know?
<mwhudson> i got some error when i tried, but well, i was doing all sort of things i didn't understand at that point
<mwhudson> bigjools: also will i be happier with packages from quantal(-updates) or the daily or stable ppa?
<bigjools> mwhudson: PPA is better right now but there's and SRU imminent
<bigjools> an*
<mwhudson> this ppa? https://launchpad.net/~maas-maintainers/+archive/dailybuilds/+packages
<bigjools> yes
<mwhudson> ta
<bigjools> also raring is better
<mwhudson> oh ok
<bigjools> it has a few more features
<bigjools> I don't know about deploying quantal on arm, I'd talk to rbasak
<mwhudson> i don't know how to install raring on highbank...
<bigjools> do you need to install the server on arm?
<bigjools> you can run it on x86 and deploy to arm
<mwhudson> hm
<mwhudson> for now it's probably easier to install on arm
<mwhudson> http://ports.ubuntu.com/dists/raring/main/installer-armhf/current/images/generic/netboot/ looks promising
<lifeless> mwhudson: whatchya working on?
<mwhudson> lifeless: arm server stuff
<mwhudson> benchmarking, in particular
<lifeless> mwhudson: ah, so automated bare metal setups ?
<mwhudson> yeah
<mwhudson> and deployment of services that one might want to benchmark
<lifeless> mwhudson: this a linaro thing?
<mwhudson> yep
<Matrix3000> anyone able to explain why dhcp doesn't work on clients after install maas-dhcp
<Matrix3000> can't get them to PXE boot, when everything is permitted
<Matrix3000> there are no other dhcp servers on the network
<Matrix3000> where should dhcp be finding the config file
<Matrix3000> anyone here that can explain the dhcp pxe boot issues, installed maas-dhcp, still nothing broadcasted
<roaksoax> Matrix3000: Did you configure maas to provide DHCP?
<Matrix3000> how do I specify that
<Matrix3000> cause on 12.04 implementation it was fairly automatic, but in 12.10 doesn't look to be
<roaksoax> Matrix3000: go to the web UI and modify the settings there fro a cluster controller
<roaksoax> you'll be able to add it
<Matrix3000> ok will try in a minute
<roaksoax> bigjools: let me know when around
<Matrix3000> roaksaox: that did not help, but i found where to change it
<Matrix3000> still not gettign any dhcp sent to it
 * mwhudson is installing maas for the third time in the last 3 working days...
<mwhudson> (this time for sure!)
<bigjools> \o/
<bigjools> yo roaksoax
<mwhudson> although h,,
<mwhudson> hmm
<mwhudson> i thought i'd be clever and install it in a raring container on a precise host
<mwhudson> but i guess i'll need to do something cleverer to make sure that pserv can get tftp traffic
<lifeless> naaaaat
<mwhudson> that's the problem rather than the solution isn't it?
<bigjools> there's your problem - don't try and be clever :)
<mwhudson> i guerss
<bigjools> accept the matrix
<roaksoax> bigjools: o/
<roaksoax> bigjools: hey so I was thinking ... we should just go for a migration path fro the SRU
<bigjools> roaksoax: how would you see that working?
<roaksoax> bigjools: if in upgrade from the precise version we have DNS/DHCP configured, configure it in MAAS itself
<bigjools> roaksoax: you would have to parse the dhcpd.conf
<roaksoax> bigjools: i can get the info from debconf i think :)
<bigjools> I am not sure this effort is worth the hassle
<roaksoax> if precise still does that (can't even remember :) )
<roaksoax> bigjools: i know, but its the only way it will get accepted
<roaksoax> at least from his perspective
<bigjools> roaksoax: grarrrrr.  remind me of the bug number again?
<roaksoax> https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1109283
<ubot5> Launchpad bug 1109283 in maas (Ubuntu Quantal) "[SRU] maas to Quantal and Precise" [Undecided,Fix committed]
<bigjools> ta
#maas 2013-04-24
<mwhudson> whuh
<mwhudson> maas-cluster-celery is failing to start for me
<mwhudson>     sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue)
<mwhudson> OSError: [Errno 13] Permission denied
<mwhudson> [2013-04-24 02:13:58,398: INFO/MainProcess] process shutting down
<bigjools> wha
<mwhudson> dailybuilds ppa installed on precise
<mwhudson> seems to be inside celery's start up code :(
<mwhudson> python -c "import multiprocessing.queues; multiprocessing.queues.SimpleQueue()" fails the same way
<mwhudson> hm, seems to be /run/shm permissions
 * mwhudson tries rebooting the server (needs doing anyway)
<mwhudson> ok that fixed it
<mwhudson> bigjools: argh
<bigjools> ruh roh
<mwhudson> bigjools: pserv doesn't appear to be serving a pxelinux.0 file
<bigjools> did you import images?
<mwhudson> yes
<mwhudson> but i had that celery oddness
<bigjools> arm is a bit different here
<mwhudson> so maybe something didn't happen that shoulda orta
<bigjools> mebbe
<mwhudson> the "region controller doesn't know about images" went away eventually though
<mwhudson> re run the import pxe script?
<bigjools> mmmm if that's gone then it;s imported them
<bigjools> but some of it could have failed
<bigjools> did you run it manually or use the UI?
<mwhudson> manually
<mwhudson> oh
<mwhudson> right, so the symptom i have of this is that the automatic pxe boot fails in uboot
<mwhudson> if i set ipaddr and serverip and run pxe get; pxe boot it works and the node gets commissioned
<bigjools> trying to remember how arm works ...
<mwhudson> so it's really just pxelinux.0 not being there that trips it up
<bigjools> it ignores that though, I thought?
<mwhudson> mwhudson@lava-leg01:~$ tftp localhost
<mwhudson> tftp> get pxelinux.0
<mwhudson> Received 26837 bytes in 0.0 seconds
<mwhudson> what
<mwhudson> adsadasdasdsada
<bigjools> it just uses the location of it as a base directory for eveything else
<mwhudson> right
<mwhudson> but if it returns file not found it complains
<bigjools> ok
<bigjools> but you can get it as you just showed :)
<mwhudson> i can /now/
<bigjools> however, the tftp server is sensitive to where the request comes from
<mwhudson> probably because i re-ran maas-import-pxe-files
<mwhudson>         exceptions.AssertionError: No PXE template found in '/usr/lib/python2.7/dist-packages/provisioningserver/pxe'!
<mwhudson> now i get that ^
<bigjools> vart da furk
<mwhudson> oh
<mwhudson> i think this is https://bugs.launchpad.net/maas/+bug/1064212
<ubot5> Launchpad bug 1064212 in MAAS "If a machine is booted manually when in status "declared", TFTP server tracebacks" [Low,Triaged]
<mwhudson> it's booting ok now
<bigjools> could be yes
<bigjools> maas has to know it's required to boot
<bigjools> ideally we'd send something that shuts it down again
<mwhudson> ok nodes are declaring themselves now
<bigjools> yay
<mwhudson> and now i can't get juju to work :)
<mwhudson> (juju-go this time)
<AskUbuntu> How to cat the `MAAS Key` of a user via `maas shell`? | http://askubuntu.com/q/284939
<rvba> Hi mgz, would you mind having a quick look at this when you'll get a chance: https://code.launchpad.net/~rvb/maas/empty-tag-bug-131232/+merge/160672 ?
<rvba> I just want to know if it seems sane to you because you know that code probably better than I do.
<mgz> rvba: sure
<rvba> ta
<allenap> roaksoax: Have you seen https://bugs.launchpad.net/maas/+bug/1172303? Do you know if this is just a difference between the packaging in quantal and raring?
<ubot5> Launchpad bug 1172303 in MAAS "MAAS_URL on maas_cluster.conf is quoted on quantal but not quoted on raring" [Undecided,New]
<roaksoax> allenap: i think is packaging.. IIRC matsubara made a change recently and that might have changed the behavior
<roaksoax> allenap: this might be the cause: http://bazaar.launchpad.net/~maas-maintainers/maas/packaging/revision/173
<roaksoax> matsubara: ^^
<roaksoax> allenap: yeah that's what has changed
<roaksoax> matsubara: your fix broke something :)
<roaksoax> allenap: we want it quoted right?
<roaksoax> allenap: this would fix it: http://paste.ubuntu.com/5598853/
<allenap> roaksoax: What branch is used for the raring package then, if not that one?
<allenap> roaksoax: That change in r173 looks like it's adding the quotes that the integration test is expecting to find, but it's odd that they're in quantal but not raring. I would have expected the other way round if anything.
<roaksoax> allenap: that's the branch that's being used. I think the reason why its not being seen on quantal is because the affected change is in the SRU , with is in -proposed and not in -updates
<roaksoax> allenap: so matsubara miught be comparing to that
<roaksoax> allenap: oh hold on, what's on -updates doe snot have maas_url
<roaksoax> allenap: so something has changed then
<roaksoax> allenap: ont he dpkg-reconfigure it seems that the quotes never get added
<allenap> matsubara: ^ I have to go now, but perhaps that'll lead to the root problem. Thanks roaksoax.
<matsubara> thanks allenap and roaksoax
<roaksoax> matsubara: i think this is the appropriate fix: http://paste.ubuntu.com/5598853/
<roaksoax> matsubara: manually applying this fix gives me: http://pastebin.ubuntu.com/5598866/
<matsubara> roaksoax, cool. so I just need to merge propose that against lp:~maas-maintainers/maas/packaging  and packaging.quantal?
<roaksoax> matsubara: and precise.sru
<roaksoax> rvba: still around?
<matsubara> roaksoax, ah ok. I'll mp it
<allenap> roaksoax: I'm not sure that's the right fix. That changes the quotes from single to double, but the test is looking for single quotes, and the failure is that there are no quotes at all.
 * allenap really goes.
<roaksoax> allenap: http://pastebin.ubuntu.com/5598887/
<roaksoax> allenap: yeah, so we should standarize and make the test not look for single quotes, but look for double quotes
<roaksoax> because that's how everything is being done
<matsubara> roaksoax, ok. I'll update the tests as well
<roaksoax> allenap: the initial change was driven becuase a test was broken due to a leading whitespace
<roaksoax> so we never noticed that there were no quotes in the first place
<roaksoax> which would have been providing the above fix instead of the commited fix
<matsubara> roaksoax, https://code.launchpad.net/~matsubara/maas/fix-MAAS_URL-quotes/+merge/160722 https://code.launchpad.net/~matsubara/maas/fix-MAAS_URL-quotes-quantal/+merge/160723  https://code.launchpad.net/~matsubara/maas/fix-MAAS_URL-quotes-precise/+merge/160725
<matsubara> I need to go for a dentist appointment and should be back in ~1h
#maas 2013-04-25
<mwhudson> argh
<mwhudson> this doesn't look good
<mwhudson> Bytes transferred = 70 (46 hex)
<mwhudson> Config file found
<mwhudson> Ignoring unknown command:   SAY
<mwhudson> Ignoring unknown command:   LOCALBOOT
<mwhudson> 1:      local
<mwhudson> No kernel given, skipping local
<mwhudson> ??
<mwhudson> oops, mischan :)
<mwhudson> bigjools: have you heard anything about the pxe command "localboot" not being recognized on arm servers?
#maas 2013-04-26
<bigjools> mwhudson: I have done very little testing on arm (read: none, personally), as rbasak was managing that side of things.
<mwhudson> bigjools: i figured out the problem
<mwhudson> bigjools: and filed a bug
<bigjools> cool
<mwhudson> bigjools: sorry for the noise
<bigjools> no problem
<bigjools> in terms of crap I see on IRC, this is *not* noise :)
<mwhudson> :)
<bigjools> roaksoax: we added an api helper to help with the sru migration thing you and I talked about: https://code.launchpad.net/~rvb/maas/api-update-cluster/+merge/160641
<lifeless> &^*&$*%$\
<lifeless> ^- noise
<bigjools> lifeless: bless you
<bigjools> mwhudson: are you using raring or quantal, or perhaps both?
<mwhudson> bigjools: precise
<bigjools> argh
<mwhudson> at least, maas is installed on precise
<bigjools> from the PPA, please say from the PPA
<mwhudson> yes, from the ppa
<mwhudson> 1.2+bzr1373+dfsg-0+1374+170~ppa0~precise1
<mwhudson> if you want to tell me how to get my raring lxc an ip address on the lan...
<bigjools> does lxc not have bridged networking?  I know nothing about lxc...
<mwhudson> not in an easy to set up form it seems
<mwhudson> just nat
<mwhudson> it's probably not hard if you know what you're doing
<lifeless> mwhudson: there is a bridge device
<lifeless> mwhudson: lxcbr or some such; you can just configure lxc to use a different bridge
<lifeless> mwhudson: and put *that bridge* onto the LAN via /e/n/i + brtools.
<mwhudson> lifeless: ok, most of the howtos around on the internet seem to involve editing the config of eth0 and that scares me a bit
<lifeless> mwhudson: note that when you do this, your own lan config needs to move to the bridge
<mwhudson> because the server is in the uk and i am not
<mwhudson> ah right
<mwhudson> see abouve :)
<lifeless> mwhudson: right, and?
<mwhudson> well, i just don't want to break the hosts lan config
<lifeless> fair enough
<mwhudson> i'll see about getting serial console access and then play with it
<lifeless> you could futz around with nat rules but thats way harder
<mwhudson> yeah that doesn't appear
<mwhudson> *appeal
<rvba> rbasak: Hi Robie, would you mind having a look at bug 1172966 at your earliest convenience?  I'm pretty surprised to see that bug because, as I say in my comment, we've tested installation on ARM nodes everyday.
<ubot5> bug 1172966 in MAAS trunk "SAY command in config.local.template breaks local boot on highbank" [High,Fix committed] https://launchpad.net/bugs/1172966
<rbasak> rvba: ack - I've responded in the bug
<rvba> ta
<rvba> rbasak: is there a way to log inside the node and get the info about the U-Boot version?  Because for some reason, I cannot connect to the machines using ipmitool.
<rbasak> rvba: I'm not aware of any way to do that, sorry. There might be a special wasy that Rob Herring would know, but I don't know it.
<rbasak> rvba: if you can't connect with ipmitool, perhaps there is already something connected and logging the serial output?
<rvba> rbasak: something like a rsyslogd on the MAAS server?
<rbasak> rvba: in the lab I developed it on, I set up conserver to keep an ipmitool running, so everything got logged to /var/log/conserver. Not sure about what's going ione in the MAAS QA lab though
<rvba> rbasak: I don't think there is anything like that in the QA lab.
<AskUbuntu> When will Raring make it to "Released" status in MAAS? | http://askubuntu.com/q/285960
<jlondon> Howdy. I asked a while back if there was a way to have different partition schemes for different servers in MaaS. Is this possible?
<AskUbuntu> How do you actually configure DHCP in MaaS? | http://askubuntu.com/q/286175
#maas 2013-04-27
<roaksoax> q/win 2
#maas 2013-04-28
<paravis> Hello! Anyone awake? I have a simple question ...
#maas 2014-04-21
<bread555> Does anyone know where to disable the maas-test functionality? Due to my config, I don't really need remote power up/off so just need to prevent maas from not installing due to hardward configurations
<qhartman> I have a MAAS isntallation running, but nodes are failing to be commissioned
<qhartman> When I get to the commissioning step, they power up (WOL) and seem t o start commissioning, but then shut down right as the process seems to get going. Googling has failed me.
<qhartman> Any suggestions for where to look on the server for some logs that point me in the right direction?
<qhartman> I get a string of "Success" messages and then what looks like some service start status messages, then shutdown. Not sure what happens last, it shuts down too quick to really read
<qhartman> Oh, it's also noteworthy that it complains aboutno ipmi user slots being available right before the string of "success" messages. Since it got past that I thought it might not be a fatal error
<qhartman> but I suppose some power control stuff might be happening incorrectly as a result and that might be what's killing the nodes before the install can really go
<qhartman> ok, another one I've found is that I need to change the interface that etherwake uses to turn up nodes
<qhartman> I've found /etc/maas/templates/ether_wake.template and made the appropriate change there (added "-i eth1"), but how do I make that change live? MAAS seems to be ignoring it.
<qhartman> turns out I needed to add an ssh key to the MAAS system, to enable the start button, and that's when the installation actually happens
<qhartman> That's not called out in the docs anywhere that I've seen, fwiw
#maas 2014-04-22
<rvba> bladernr_: Hum, that's interestingâ¦ I'll try recreating thisâ¦
<rvba> Hi jtv and thanks for the reviewâ¦ reading you essay now :).
<rvba> your*
<rvba> jtv: Weird, https://code.launchpad.net/~jtv/maas/lint-2014-04-21/+merge/216578 is not landingâ¦
<jtv> rvba: I had a case like that the other night... lemme see if that landed.
<jtv> (Didn't look then because it was just lint)
<jtv> Nope, not landed!
<rvba> bladernr_: I cannot reproduce your problem: see paste.ubuntu.com/7305538/
<rvba> allenap: forgot to ask you.  Did you start working on producing the documentation for the power parameters as you said you would?
<rvba> I'm asking because it's quite essential if we want to let maas-test take arbitrary power parameters.
<allenap> rvba: No, I didnât. I ended up working on house stuff about 16-18 hours a day for several days instead. I was more exhausted than I have ever been :)
<rvba> allenap: no worries.  But I had to ask.  Are you still planning on getting that done?
<allenap> rvba: Iâd like to, but if youâre at a loose end and you want to do it, go for it. Tbh, I have to concentrate on planning for Austin for the next week or so.
<rvba> allenap: all right.  I guess I'll take of it then.
<rvba> take care*
<jtv> rvba: did you come up with an answer to the pop quiz?
<rvba> jtv: not yetâ¦ I need to think about itâ¦ this is obviously a trick question :)
<jtv> Obviously.  :)
<rvba> gmb: if you still have that setup, could you please check what's up with our lander (and maybe tear it down and start another if push comes to shove)?  None of the approved branches are landing on trunk.
<gmb> rvba: Sure thing.
<rvba> Ta
<gmb> Bear with me.
<gmb> rvba: Hmm. Tarmac got stuck. Looking into it now.
<gmb> rvba: running tarmac manually now, then it should get back to normal. Looks like it got stuck on the 18th and hasnât done anything useful since.
<gmb> Wow. Holymegatestfailure Batman!
<jtv> gmb: that test failure looks like the old "the API client package is installed when it shouldn't be."
<gmb> jtv: Mmm, could be; looks like all the branches are failing in the same way.
<gmb> jtv: Iâll wait for tarmac to finish puking.
<gmb> And then sort it out.
<jtv> Yeah.  It's what happens when you switch from developing maas to working on maas-test, and back again.
<gmb> Blech.
 * gmb wonders if we should have a make target that checks for a lack of the API client package and bails out early.
<gmb> If the tests are just going to fail anywayâ¦
<jtv> I think Gavin did something like that recently.
<gmb> Aha.
<gmb> allenap: ^^??
 * allenap reads
<jtv> See required-packages/forbidden
<gmb> Eeenteresting.
<jtv> Ah, but not in there.
<allenap> Yes, thatâs the one.
<gmb> Strangely enough, the api client package is not installed.
<jtv> There was another one like that I think.
<gmb> Oooh, hang onâ¦
 * jtv hangs on
<gmb> Thereâs cruft left in the copy of maas-trunk that tarmac has.
<gmb> I wonder if thatâs the causeâ¦
<gmb> Must have been left behind by the stuck tarmac run.
<gmb> Hmm.
 * gmb cleans up, runs tarmac again
<gmb> Hmm. Nope, still kaboomey
 * gmb might just kill the machine and start a new one.
<jtv> It's the Cloud Wayâ¢.
<gmb> Yeah.
<gmb> FWIW, looks like everythingâs failing with âAttributeError: 'functools.partial' object has no attribute '__module__ââ
<gmb> Maybe not everytingâ¦ thereâs a lot of noise.
<bladernr_> rvba: not sure what to tell you... I completely deleted everything (rm -rf ./boot-resources/* and re-synced using the bootresources.yaml (after commenting out everything I didn't need) and I ended up with both RC and Release images... I got that both before and after clearing the boot-resources dir.
<bladernr_> rvba: I can try again, but it takes me several hours due to living on a slowish DSL line
<rvba> bladernr_: can you paste your bootresources.yaml?  And tell me which version of MAAS you're using?
<rvba> bladernr_: I'm testing things on canonistack, where it takes less than 10 minutes to sync a couple of images.
<bladernr_> rvba: http://paste.ubuntu.com/7307356/
<bladernr_> should all be in there
<bladernr_> the only changes I made to bootresources.yaml was to comment out the older stuff because I only need images for Saucy and Trutsy
<bladernr_> Trusty even
<rvba> bladernr_: you don't have 'labels' defined for any of your selections.  The default value is '*' which means: take all the labels you find.
<rvba> That's your problem.
<bladernr_> that's the way the package installed it.  When I did the upgrade from Saucy, I told it to install the new packaged version of bootresources.yaml
<rvba> Okay, this an upgrade bug then.
<bladernr_> So I ended up with bootresources.yaml (new) and bootresources.yaml.dpkg-old (my original)
<bladernr_> where would I add "labels" to my current file then?
<bladernr_> under sources: labels: release ??
<bladernr_> ^^ at the top along with the keyring and path declarations?
<rvba> bladernr_: paste.ubuntu.com/7307395/
<bladernr_> ahhh... ok.
<bladernr_> that was going to be my next question, actually... is it possible to specify per release, so I could have lables: -release for 14.04 and -daily or whatever for 14.04.1 then?
<bladernr_> thanks, I'll fix mine and restart the import and see what happens.
<rvba> This is all based on simplestreams' data and, AFAIK, there is no separate stream for 14.04.1.  So the answer would be 'no.'  You might want to double check that with Smoser though.
<smoser> bladernr_, what do you think that 14.04.1 means ?
<smoser> i'm not being pedantic, its an important piece of information .
<bladernr_> well, I would think that 14.04.1 is not 14.04 (ISOs should be different)
<bladernr_> from a cert standpoint, we don't do package upgrades, we do installs from daily or release ISOs, so 14.04 ISOs != 14.04.1 ISOs and BOTH are install options
<bladernr_> using 12.04 for example, when we'd do a cert, we'd start with 12.04.1 and test, then install 12.04.2 and test, then 12.04.3 and test and so forth
<bladernr_> that MAY change with 14.04, assuming there won't be two different fully supported kernels like we ahve in 12.04, but I don't know how that's going to work yet
<smoser> right. so 14.04.1 is 2 things, that are actually completely disjoint.
<smoser> a.) a media release of a point in time snapshot of the archive.ubuntu.com
<smoser> b.) a selection of different default kernel.
<bladernr_> c.) any hardware enablement work up to that point that isn't backported (either in software bits or kernel bits)
<bladernr_> AIUI, there will be no backported hardware enablement, (I coudl be wrong)
<smoser> what is 'b' that is not 'c' ?
<smoser> for 'a', maas has no way to do address this. changes in simplestreams wont help that. you need a time machine or something like snapshot.debian.org .
<bladernr_> software bits, not kernel bits... so possible to have something like... newly packaged RAID config tools based on 14.04.1 kernel but incompatible for some reason with 14.04 kernel
<smoser> not really.
<smoser> thos would just be packages in the archive.
<bladernr_> fair point.
<smoser> for 'b', we have that addressed now.
<smoser> in 14.04.1 time frame, you will see a
<smoser> com.ubuntu.maas:v2:boot:14.04:amd64:hwe-u
<smoser> entry appear in http://maas.ubuntu.com/images/ephemeral-v2/releases/streams/v1/com.ubuntu.maas:v2:download.sjson
<smoser> it will also be labeled "release"
<bladernr_> cool
<smoser> but will have "subarch" as "hwe-u".
<smoser> you can see that right now with 12.04 things.
<smoser> there is hwe-p, hwe-q, hwe-r ...
<bladernr_> ok.  to be honest, I would like to get away from how we were doing testing (multiple ISO images) anyway... and the HWE kernel thing is more a regression testing / SRU testing thing than cert... so that will work fine
<bladernr_> IMO
<bladernr_> If course, people who get paid more than I do may think otherwise :)
<jtv> gmb: any luck with that lander?
<jtv> smoser: can you think of a reason why uec2roottar might print "finished. wrote to [etc]" but still return nonzero?
<jtv> Looks highly implausible, no?
<jtv> I'm trying to figure out why that was the last stderr output I got from it, around the time that the maas logs show the command failing.
<jtv> Ahhhhh, it's not uec2roottar that failed.
<jtv> It's my attempt to "sudo chown" what I think is the output file.
<jtv> Why on earth would that fail?
<jtv> "sudo chown maas:maas <root-tgz-file>"
<jtv> Ahhhh
<jtv> sudoers.
<gmb> jtv: I started a new one but because of the way theyâre configured OOTB I canât SSH to itâ¦ So, no.
<jtv> :(
<smoser> jtv, you may be able to just create the expectecd target file with the perms.
<smoser> maybe
<smoser> prior to calling it.
<smoser> i dont like that, but as a work around it might work.
<jtv> Six of one...  It might make more sense to have a wrapper that does both, and give sudo rights to run that script.
<jtv> Instead of sudo rights to run uec2roottar followed by chown.
<jtv> Anyway, I'm out.  Good night!
<roaksoax> /q/win 10
<bigtree> What files do I need to delete to download the newest images? I am starting MaaS and on my nodes I am seeing the development branch of trusty being installed.
<magicrobotmonkey> soo my nodes not booting, it keeps hanging on cannot connect to iSCSI daemon. Is there a log on the server I can see?
<allenap> rvba: Is it deliberate that the remote API docs are only generated for trunk, wrt https://maas.ubuntu.com/
<allenap> ?
<qhartman> Anyone have pointers to docs for running up nodes that are multi-homed? My hardware keeps coming up with only the management interface (eth0) configured. Even if eth1 would come up via dhcp I'd be happy. Is the right thing to adjust the pre-seed file?
<qhartman> If that's the case, I assume that there is some analogue for the fastpath installer?
<ser_> Hi! After installing MAAS from Ubuntu Server 14.04 boot media can't get the web address.Didn't ask  web address that will be used to the web interface. What is the problem?
<qhartman> it should be whatever the IP of the server for your MAAS installation
<qhartman> specifically http://maas-server-ip/MAAS
<ser_> Thank you
#maas 2014-04-23
<bigjools> qhartman: yes, preseed adjustment is the way to go, for now at least.
<bigjools> allenap: I think there is a caching proxy in the way somewhere which doesn't have the new layout
<bigjools> jtv: http://paste.ubuntu.com/7311567/
<jtv> So you're getting it too?  I'm not.
<jtv> Though let me try trunk.
<jtv> Whoops, yes, lots of errors!
<jtv> Eenteresting.
<bigjools> ah
<bigjools> apparently
<bigjools> functools.wraps expects the callable being wrapped to have a __module__ attribute
<jtv> Hey.
<jtv> I'm getting this in my branch.
<jtv> Of which I ran the tests endlessly yesterday without these failures.
<bigjools> I am getting this in trunk
<jtv> So... package update?
<bigjools> I expect a django update broke things
<jtv> Yes, I'm getting it in trunk too.  Thing is, I wasn't getting this yesterday, and it's not a code change.
<bigjools> of which there was just one
 * bigjools looks at the django change
<bigjools> jtv: yep I reckon this is a regression in the security update
 * bigjools files bug
<jtv> Might I recommend a priority on the high side?
<bigjools> jtv: https://bugs.launchpad.net/ubuntu/+source/python-django/+bug/1311433
<ubot5> Launchpad bug 1311433 in python-django (Ubuntu) "REGRESSION: AttributeError: 'functools.partial' object has no attribute '__module__' " [Undecided,New]
<bigjools> can you confirm it :)
<jtv> I registered my being affected by it.
<jtv> Hope that's what you mean.
<bigjools> change the status
<bigjools> well it does that automatically I think
<jtv> I didn't think the Confirmed status did much, except maybe make triagers think the bug doesn't need attention.
<jtv> Oh, it's Confirmed now.
<bigjools> jtv: this is very serious, maas no longer runs at all in trusty
<bigjools> jtv: ok we can fix this locally
<bigjools> jtv: https://code.djangoproject.com/ticket/22486
<ubot5> Django bug 22486 in Core (URLs) "urlresolvers.reverse() security fix (1.5.6) breaks when a view is a partial" [Normal,New]
<bigjools> I'll file a maas bug
<jtv> I wonder where we're doing the partial thing.
<jtv> src/maasserver/views/combo.py?
<jtv> get_combo_view is the only thing (outside of tests) that looks to me like it might be doing this.
<bigjools> jtv: can you do me a favour and see if this patch fixes things? https://github.com/prestontimmons/django/commit/b63ae5c60619a257ad57cf6043e71f681283e47b
<jtv> Looking..
<jtv> I was just trying a patch of my own.
<bigjools> it's a patch to django though
<bigjools> security team will apply it if we confirm it works
<jtv> Ah.  Meanwhile I seem to have a working patch to maas.
<bigjools> jtv: ah!
<jtv> bigjools: my test run is not done yet, but this simple maas fix seems to work around the problem at least for us: http://paste.ubuntu.com/7311704/
<bigjools> jtv: land it so it unblocks the lander at least
<jtv> I'll start a VM to try the django patch.
<jtv> Aye-aye sir.
<jtv> Got a maas bug number?
<bigjools> jtv: same number, I added a maas task
<jtv> OK
<mdeslaur> jtv: any news?
<jtv> mdeslaur: about what?
<jtv> the bug?
<jtv> I'm landing a workaround in maas.
<mdeslaur> jtv: yeah, the upstream patch
<mdeslaur> I'm building security regression fixes with the commit from the upstream bug
<jtv> I'm still setting up for the attempt.
<jtv> By the way, you wouldn't happen to know a way to get a plain diff from that github page?
<mdeslaur> jtv: add ".patch" to the end of the url
<jtv> Ah, of course!  Why didn't I figure that out myself!
<jtv> </sarc>
<jtv> Thanks.  :)
<mdeslaur> yeah, super-intuitive
<mdeslaur> I just uploaded a fixed package for trusty here: https://launchpad.net/~ubuntu-security-proposed/+archive/ppa/+packages
<mdeslaur> and will upload for the other releases in a few minutes
<jtv> Are you saying I could just use that package instead of applying the diff?
<mdeslaur> jtv: yes
<jtv> Great, thanks!
<mdeslaur> and I would like to know if it fixes maas before I push them out ASAP
<jtv> Yes, of course...  I'm setting up to establish that.
<mdeslaur> jtv: cool, thanks
<jtv> mdeslaur: for maas, the proposed update fixes the failures!
<mdeslaur> jtv: awesome, thanks for testing!
<mdeslaur> I'll release them right away
<jtv> (Although of course independently from that, I already landed a workaround in maas)
<jtv> Thanks.  This has bitten us pretty hard, so glad to see it being resolved for everyone.
<bigjools> thanks mdeslaur
<bigjools> and thanks for testing jtv
<jtv> Still seeing _some_ test failures with the new package, but let me see what they are first.
<jtv> May be unrelated.
<mdeslaur> bigjools, jtv: thanks!
<jtv> xargs: env: terminated by signal 9
<jtv> That's something we've seen before... probably unrelated.
<mdeslaur> I'll make sure we add maas to our django testing going forward
<jtv> I'm investigating.
<bigjools> mdeslaur: \o/
<jtv> Found the cause of those other test errors: VM ran out of memory.  Not an issue.
<mdeslaur> jtv: thanks
<rvba> gmb: did you get to the bottom of the "AttributeError: 'functools.partial' object has no attribute '__module__'" failure?
<rvba> (Hi gmb, btw :))
<rvba> jtv: ^
<rvba> I'm asking because I'm seeing that locally nowâ¦ and I saw that the python-django package has been updatedâ¦
<bigjools> rvba: I did
<bigjools> django fail
<rvba> Yeah, I just saw the fixes.
<bigjools> update again
<rvba> What a mess.
<bigjools> yes :)
<gmb> Bbiam
<jtv> Who's up for what I hope will be a simple review?  https://code.launchpad.net/~jtv/maas/env-context-manager/+merge/216840
<rvba> jtv: I'll take it
<jtv> Merci beaucoup.
<rvba> Pas de problÃ¨me.
<alfs> I'm having some strange mirroring problems.
<alfs> http://archive.ubuntu.com/ubuntu/ is fine
<alfs> http://ftp.se.debian.org/ubuntu/  does not work
<alfs> The installer claims the archive is broken, and syslogs says 403 forbidden when accessing http://ftp.se.debian.org/ubuntu/
<alfs> http://ftp.se.debian.org/ubuntu/dists/trusty/Release
<alfs> but it works fine outside the installer.
<alfs> Trying to access it from the interrupted installation shell, but the kvm/keymapping does not allow me typing slashes... trying to find some workaround
<jtv> Could it be a problem with a proxy somewhere inbetween?
<alfs> dont think there are any. However, when I dump traffic on the gw/router, I see e.g. icmp packets to the mirror when I ping, but no web requests.
<alfs> Seems it's not a mirror problem. Same error with e.g. ftp.uk.debian.org/ubuntu and others.
<alfs> *digging for proxies*
<melmoth> hola ! now that trusty is out, i guess i can just apt-get install maas and juju-core and all the tools without having to add any ppa or are ppa still relevant ?
<lazyPower> melmoth: i'm not using any ppa's and my MAAS cluster works a treat. (i'm using kvm virtualization, ymmv if on bare metal)
<magicrobotmonkey> anyone have any tips for debugging the pxelinux.0 that comes with MAAS? Cobblers works fine, but with MAAS it barfs on some iSCSI stuff
<magicrobotmonkey> i think it may be using the wrong interface
<melmoth> lazyPower, nodes will be kvm vm too , it s just for playing :-)
<melmoth> actually, even the maas box is a kvm vm.
<lazyPower> ah, i went the other way around with that and kept the region controller on bare metal so i could reach the aas nodes from outside my network.
<lazyPower> bridging into the VM was a bit of a heady process
<magicrobotmonkey> im install maas-cluster-controller on a brand new trusty install and the apache restart is bailing due to missing crochet module
<rvba> magicrobotmonkey: looks like a packaging bug.  Please report a bug with all the details and we will get back to you ASAP.
<magicrobotmonkey> ok ty
<qhartman> so, I'm setting up a multi-homed MAAS cluster, and the routes and DNS on the nodes that come up are all sorts of wrong.
<qhartman> I'm wanting to treat the MAAS-side as a management network, and as such isn't bridged / routed onto the main network.
<qhartman> but the MAAS config tool doesn't want to let me make the DHCP changes that I think need to be made to make this work.
<qhartman> since the external interfaces (which are internet connected) are managed by a different DHCP
<qhartman> so, what's the right way to do this sort of setup?
<qhartman> I'm sure I could hand-jam it, but that seems counter to the point of MAAS.
<qhartman> or should I have my MAAS controller setup to bridge between the networks and have the nodes see the outside world that way?
<lazyPower> qhartman: i setup a bridge device on the region controller - but my maas nodes are kvm machines and not bare metal.
<lazyPower> its kind of dependent on your network topology
<qhartman> right
<qhartman> yeah, I've setup my controller to do forwarding now as well. We'll see if this actually fixes the Juju problem.
<qhartman> I'm nuking the other machine I was working on and starting with a fresh node
<magicrobotmonkey> is there a strategy for importing pxe files from a host that can't reach the internet?
<magicrobotmonkey> the region controller can
<lazyPower> magicrobotmonkey: you should only need to import the pxe files on your region controller. I'm fairly certain that hands off the files to the zone controllers.
<lazyPower> i could be wrong though - needs citation
<magicrobotmonkey> hmm it doesnt seem like the docs say that
<magicrobotmonkey> but it turns out i have some network issues to resolve first anyways
<magicrobotmonkey> how do you login to a maas-cluster-controller from the cli?
<allenap> jhobbs: Hi there. Have you had a look at the âHWE streamsâ thing?
<jhobbs> allenap: a little bit, I wrote a doc on some of it https://docs.google.com/a/canonical.com/document/d/1CJlIu2wapKJgDl-MXmvK_RseqBHeWJQ6S-gJzn0bh34/edit#heading=h.eeybgo5224oo
<allenap> jhobbs: Nifty, Iâll read that before the meeting.
#maas 2014-04-24
<jtv> This is annoying.  I'm trying to Q/A my uec2roottar rewrite, but something else is broken.
<jtv> Could not find kernel image: amd64/generic/trusty/release/boot-kernel
<jtv> I think it's an architecture mismatch: i386/amd64
<jtv> Silly of me.  Can't set a node's architecture with default enlistment.
<jtv> rvba: might not be completely crazy to start a DownloadProgressHandler.
<rvba> jtv: that's what I thought.  The thing is that the documentation for this API method is so detailed that it drives people to try and use that method :)
<jtv> On the other hand, the design notes had to go _somewhere_.  :)
<rvba> heh
<jtv> If we just provide a GET to download progress, that wouldn't be very user-friendly but at least API users could get stuff done.
<rvba> Indeed.
<jtv> And it would get the implementation ball rolling: so much easier to say how it should be _better_ than how it should _be_.  :)
<rvba> Also, isn't the import script supposed to do the reporting (using the report_download_progress method)?
<rvba> Wasn't that the plan?
<rvba> jtv: something else I wanted your opinion about:  When users upgrade from Saucy, the new entries in bootresources.yaml don't have a 'label' constraint.  As a result, multiple images can be imported (for instance 'rc'/'release')â¦ shouldn't we add a labels=['release'] constraint?  This would be better in sync with what the old config (from which we're migrating) was doing.
<rvba> Not sure if it's worth a bug/fixing.  Especially considering the upcoming work on getting rid of bootresources.yaml.
<jtv> rvba: maybe wait until we know what we really want, there?  Otherwise we keep modifying and creating this massive history of different default settings.
<rvba> jtv: yeah.  But let's keep that problem in mind then.
<jtv> Absolutely.
<jtv> gmb, this one's for you: https://code.launchpad.net/~jtv/maas/test-1310844/+merge/217006
<gmb> jtv: On it, ta
<rvba> bigjools: can you please vote on https://code.launchpad.net/~rvb/maas/add-power-params-doc/+merge/216894 ?
<rvba> jtv: reviewing your 'python-to-python-imports' branch now
<rvba> allenap: I filed https://bugs.launchpad.net/maas/+bug/1312085
<ubot5> Launchpad bug 1312085 in MAAS "No documentation for the CLI" [High,Triaged]
<rvba> allenap: care to vote on https://code.launchpad.net/~rvb/maas/add-power-params-doc/+merge/216894 ?
<allenap> rvba: Okay, Iâm finishing something off right now, then Iâll do it.
<rvba> allenap: ta, it's definitely not urgent.
<alfs> ran into an interesting issue with usb keys and large rams.
<alfs> The machine has 24 GB ram, and I use a 8 GB usb stick for deployment.
<alfs> the rootfs gets about 1 GB, and the rest is allocated for swapspace - and e.g. juju bootstrap fails due to insufficient disk space.
<alfs> is there some easy way to skip swap altogether, or do I need a customized preseed?
<Teduardo> if using MaaS to build/maintain a distributed system, lets use for example openstack. when a new openstack release comes out, can MaaS sensibly handle the upgrade as well?
<Teduardo> (maas/juju)
<magicrobotmonkey> I'm getting PXE-E11 ARP Timeout when booting a potential node
<melmoth> what is the purpose of the new "Network" menu in trusty maas ?
<melmoth> i did not have such a one before using the ppa version of maas in precise. what am i suppose to put there ?
<rvba> melmoth: maas.ubuntu.com/docs1.5/networks.html
<melmoth> ok, so if all my nodes are on the same net as the nic i assigned to the  cluster controller , and dont use other network, i dont need to use this form, right ?
<rvba> melmoth: correct
<melmoth> good. thanks.
<magicrobotmonkey> my node came to the maas-enlisting-node login: prompt
<magicrobotmonkey> am I supposed to do something now?
<rvba> magicrobotmonkey: no, this should be temporary (i.e. until your node enlists itself).  After a while your node should be powered down by MAAS.
<magicrobotmonkey> oh there it goes
<magicrobotmonkey> things are happening!
<magicrobotmonkey> cool it showed up in the nodes
<magicrobotmonkey> this is much better than scraping the switch for mac addresses
<magicrobotmonkey> when i hit "commision node" where should I look for a log of whats going on?
<alfs> console output
<alfs> I find is the best. Sometimes the commissioning or running hangs, and the console is the best place to see this
<magicrobotmonkey> yea ok
<magicrobotmonkey> does the commisioning configure ipmi locally? because I've been unable to use ipmitool on these boxes but maas did it somehow
<alfs> It adds it's own user
<alfs> in the commissioning stage
<magicrobotmonkey> ah cool
<magicrobotmonkey> thats pretty slick
<alfs> still no luck with partitioning. Is there some other source for the partition layout than /etc/maas/preseeds/preseed_master?
<alfs> I know my edits are working, e.g. changing from ext4 to ext3, but partman-auto/expert_recipe and partman-auto/choose_recipe just does not bite.
<rvba> alfs: that's weird, there is nothing that should override changes in /etc/maas/preseeds/preseed_master.
<alfs> Hm.. I commented everything regarding partman in the preseed, and then it (as intended) stops at the partitioning stage
<alfs> However I cannot get past iscsi config, i.e. I choose iscsi, finish, and then get thrown back to iscsi config.
<alfs> No option to configure, and if I finish partitioning it (of course) has no root fs defined
<alfs> perhaps due to the partman early-command not being run to define the disks.. enabling that and trying again
<alfs> seems there was a small typo in the expert_recipe, causing it to be ignored, seems to be working now.
<magicrobotmonkey> heh yea i think i had a problem like that at one point
<magicrobotmonkey> do maas nodes use a proxy by default?
<magicrobotmonkey> an apt proxy, that is
<Isid0r0> Hey, Does anyone know how to add the new "trusty" disto to an existing MAAS installation? I see it downloaded the OS's but it isn't registering in the settings page as a deployable distro
<alfs> magicrobotmonkey: Yes, the maas server has squid-deb-proxy installed
<magicrobotmonkey> cool
<magicrobotmonkey> thats super handy
<alfs> make sure you use the official archive, otherwise you get bad mirror hangs
<alfs> or {cc}.archive.ubuntu.com at least
#maas 2014-04-25
<Guest11359> smoser: When I get my filesystem all set up, where do I write the fstab file?
<basicer> ie where does state['fstab'] point ?
<jtv> gmb: as mentioned on the call yesterday, I've been continuing the cleanup on the import code.
<jtv> Or did I mention it the day before?  One forgets.
<jtv> Anyway, I have a branch in the works that may clarify a few things that you've been figuring out.
<melmoth> hmm, with trusty, i try to perform the same sort of install i used to do before... I can bootstrap all right, but deployn a simple charm such as mysql fail. no machine is being picked up
<melmoth> http://pastebin.ubuntu.com/7329138/
<jtv> melmoth: looks like it's more of a juju problem than a maas problem.  It _may_ turn out to be a maas problem, but you may be best off asking in #juju about finding the errors' root cause.
<melmoth> hmmm, i wonder if it s a good idea to say "local:precise/mysql" when i m using default trusty
<melmoth> i ll try to deploy stuff drom local:trusty/ and ask on #juju if it still fail.
<jtv> Ah, I hadn't noticed the "precise."  :)
<jtv> allenap, could you help me debug a problem building in the daily PPA?
<jtv> I requested a daily/trusty build, and it failed to upload because a package with the same version but different contents was already in  the PPA.
<jtv> This has happened before, but I don't recall why.  The revision should contain the current revision of the packaging branch, right?
<jtv> Correction: The *version* should contain the current revision of the packaging branch, right?
<jtv> Hmm... it built from packaging r272, but my packaging branch had landed as r273.  Is this an 1.5/1.6 problem?
<rvba> allenap: you might want to have a look at the comment I added on bug 1305102 https://bugs.launchpad.net/maas/+bug/1305102/comments/5
<ubot5> Launchpad bug 1305102 in MAAS "celeryd 100% cpu when large dhcpd lease file" [Critical,Triaged]
<jtv> rvba: maybe you have any ideas about ^ ?
<jtv> I got an upload error from the daily trusty PPA.
<rvba> lookingâ¦
<jtv> Maybe I should just try again, but I don't want to exhaust my daily attempts.  :)
<rvba> jtv: did you use a recipe to build the package?
<rvba> jtv: maas-maintainers/+recipe/maas-daily-trusty build the *1.5* branch?
<rvba> (i.e. not trunk)
<rvba> s/branch?/branch!/
<jtv> Ah!  That's the recipe I used.
<jtv> And yet, not the branch I've been working on.
<rvba> That's you problem then.
<rvba> your*
<rvba> I suggest you create a recipe to build a package from trunk and put it in the experimental PPA.
<jtv> Yes, that sounds like a good idea.
<jtv> Also, shouldn't the daily/trusty recipe build from a trusty packaging branch?
<rvba> jtv: that's what it does
<jtv> Then why the different package contents..?
<jtv> It said a package with the same version but different contents was already in the PPA.
<rvba> jtv: I don't know.  Looks like it should be exactly the same content.
<jtv> Could be a transient clash as version numbers sync up again after the fork, I suppose.
<allenap> jtv: Iâm glad that rvbaâs here, because I donât have a clue. DDs went in only as far as needed, and were promptly ejected from braincore at the end of that project.
<rvba> \o allenap
<allenap> o/ rvba
<allenap> rvba: I guess we should check the permissions on the parent directory.
<jtv> Hi allenap
<allenap> re. dhcpd lease rotating.
<rvba> allenap: yes
<allenap> Eyup jtv.
<rvba> allenap: paste.ubuntu.com/7329355/
<rvba> allenap: I /think/ the dhcp.leases~ is the old, "rotated", file.
<allenap> rvba: Not sure how thatâs being rotated by a process running as dhcpd.
<allenap> rvba: ls -d /var/lib/maas/dhcp
<allenap> rvba: ls -ld /var/lib/maas/dhcp
<rvba> allenap:  sudo ls -ld /var/lib/maas/dhcp
<rvba> drwxr-xr-x 2 root root 4096 Apr 25 09:08 /var/lib/maas/dhcp
<jtv> allenap, bigjools, gmb, rvba: we have a new recipe: "maas-daily-trunk," against the experimental-builds PPA.
<allenap> rvba: It looks like /var/lib/maas/dhcp should be owned by dhcpd.
<rvba> allenap: I seem to remember there is a catch somewhere about thatâ¦
<rvba> I can't remember what it was though.
<allenap> Hush :)
<jtv> allenap, rvba: IIRC we had a changeover, in Precise, from "it has to be owned by root" to "it has to be owned by dhcpd," or vice versa.
<rvba> jtv: Yes, that was it.
<jtv> Oh by the way, the import code has a bunch of check_call()s... should those be call_and_check()s?
<jtv> And speaking of which, large imports cleanup up for review: https://code.launchpad.net/~jtv/maas/split-out-repowriter/+merge/217209
<jtv> allenap: are you still working on that speedup for the leases parser?  I was quite looking forward to that.
<jtv> It's probably too much to hope that we could just call into ISC's compiled parser...
<allenap> jtv: https://code.launchpad.net/~allenap/maas/dhcp-leases-parsing/+merge/215112 is the code. Iâm not sure what Iâve got left to do. There are tests, it looks cleanish, but something probably held my hand.
#maas 2014-04-26
<newell> anyone from the maas team around?
#maas 2015-04-20
<mup> Bug #1446112 was opened: Can't check power of a "NEW" machine <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1446112>
<mup> Bug #1446323 was opened: [1.8.0b3] Third party drivers display missing from node detail page <oil> <ui> <MAAS:New> <https://launchpad.net/bugs/1446323>
#maas 2015-04-21
<mup> Bug #1438102 changed: text alignment on dropdown buttons <ui> <ux> <MAAS:Fix Released by ricgard> <https://launchpad.net/bugs/1438102>
<mup> Bug #1434257 changed: MAAS should set dnssec-validation to no in /etc/bind/named.conf.options <MAAS:Triaged> <maas (Ubuntu):Confirmed> <https://launchpad.net/bugs/1434257>
<mup> Bug #1434257 changed: MAAS should set dnssec-validation to no in /etc/bind/named.conf.options <MAAS:Triaged> <maas (Ubuntu):Confirmed> <https://launchpad.net/bugs/1434257>
<mup> Bug #1446625 was opened: package maas-region-controller 1.7.3+bzr3363-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned
<mup> error exit status 1 <amd64> <apport-package> <need-duplicate-check> <third-party-packages> <vivid> <maas (Ubuntu):New> <https://launchpad.net/bugs/1446625>
<dimitern> rvba, blake_r, mpontillo, maas+juju interlock meeting?
<rvba> dimitern: joining nowâ¦
<blake_r> dimitern: on the way
<mup> Bug #1446629 was opened: Node status transition events are logged at 'debug' level <MAAS:Fix Committed by rvb> <https://launchpad.net/bugs/1446629>
<dimitern> rvba, you saide 1PM UTC tomorrow, right?
<dimitern> said*
<rvba> dimitern: I added the meeting at 4pm CET.  Happy to move it if you want me to.
<dimitern> rvba, hmm I can't see it
<dimitern> rvba, ok I've seen it on your calendar
<dimitern> rvba, that's fine
<rvba> dimitern: rarg, forgot to send the invites.  Done now.
<mup> Bug #1446699 was opened: After upgrade to 15.04, unable to boot with maas installed running systemd <MAAS:New> <https://launchpad.net/bugs/1446699>
<mup> Bug #1443408 changed: Web UI ignores "Choose your image" and deploys some other image anyway <MAAS:New> <https://launchpad.net/bugs/1443408>
<mup> Bug #1443408 was opened: Web UI ignores "Choose your image" and deploys some other image anyway <MAAS:New> <https://launchpad.net/bugs/1443408>
<mup> Bug #1443408 changed: Web UI ignores "Choose your image" and deploys some other image anyway <MAAS:New> <https://launchpad.net/bugs/1443408>
<catbus2> newell: https://bugs.launchpad.net/curtin/+bug/1425264
<catbus2> newell: http://paste.ubuntu.com/10862264/
<mup> Bug #1446795 was opened: 1.8beta3: Can't tell if power check worked or not <oil> <MAAS:New> <https://launchpad.net/bugs/1446795>
<mup> Bug #1446810 was opened: 1.8beta3: Too Many Open Files in maas.log <oil> <MAAS:New> <https://launchpad.net/bugs/1446810>
<mup> Bug #1446813 was opened: 1.8beta3: clusterd.log starts off with about 34MB of 0's <oil> <MAAS:New> <https://launchpad.net/bugs/1446813>
<mup> Bug #1446822 was opened: maas erase disk cannot be canceled <maas (Ubuntu):New> <https://launchpad.net/bugs/1446822>
<mup> Bug #1446840 was opened: Internal server error saving the clusters interfaces <MAAS:Triaged> <https://launchpad.net/bugs/1446840>
<mup> Bug #1446878 was opened: maas django app won't start "ImportError: No module named apt_pkg" <maas (Ubuntu):New> <https://launchpad.net/bugs/1446878>
#maas 2015-04-22
<mup> Bug #1446525 was opened: Curt tries to umount /tmp filesystem while commands are running. <curtin:New> <MAAS:New> <https://launchpad.net/bugs/1446525>
<mup> Bug #1446914 was opened: 2015-04-22 00:36:04 [-] Error on request (25) node.check_power:  <oil> <MAAS:New> <https://launchpad.net/bugs/1446914>
<mup> Bug #1446915 was opened: 2015-04-22 00:37:05 [root] ERROR:  <oil> <MAAS:New> <https://launchpad.net/bugs/1446915>
<mup> Bug #1446916 was opened: MAAS should provide access to every installation log recorded <MAAS:New> <https://launchpad.net/bugs/1446916>
<thetrav> does MaaS use cloud_init to configure its nodes, and if it does, is there an API exposed that I can use to manipulate the cloud-config file delivered to nodes?
<mup> Bug #1447009 was opened: New web UI doesn't refresh correctly <MAAS:New> <https://launchpad.net/bugs/1447009>
<dimitern> rvba, hey, I've just noticed there's no hangout link for the deep dive call
<rvba> dimitern: https://plus.google.com/hangouts/_/canonical.com/netwk
<mup> Bug #1443627 changed: 1.8beta2: MAAS fails to release nodes <oil> <MAAS:Fix Committed by rbanffy> <https://launchpad.net/bugs/1443627>
<mup> Bug #1446914 changed: 2015-04-22 00:36:04 [-] Error on request (25) node.check_power:  <oil> <MAAS:New> <https://launchpad.net/bugs/1446914>
<mup> Bug #1446915 changed: 2015-04-22 00:37:05 [root] ERROR:  <oil> <MAAS:New for rbanffy> <https://launchpad.net/bugs/1446915>
<mup> Bug #1447208 was opened: deferToThread should not wait for a thread in the same threadpool <MAAS:Triaged> <https://launchpad.net/bugs/1447208>
<mup> Bug #1443627 was opened: 1.8beta2: MAAS fails to release nodes <oil> <MAAS:Fix Committed by rbanffy> <https://launchpad.net/bugs/1443627>
<mup> Bug #1446914 was opened: 2015-04-22 00:36:04 [-] Error on request (25) node.check_power:  <oil> <MAAS:New> <https://launchpad.net/bugs/1446914>
<mup> Bug #1446915 was opened: 2015-04-22 00:37:05 [root] ERROR:  <oil> <MAAS:New for rbanffy> <https://launchpad.net/bugs/1446915>
<mup> Bug #1447208 changed: deferToThread should not wait for a thread in the same threadpool <MAAS:Triaged> <https://launchpad.net/bugs/1447208>
<mup> Bug #1443627 changed: 1.8beta2: MAAS fails to release nodes <oil> <MAAS:Fix Committed by rbanffy> <https://launchpad.net/bugs/1443627>
<mup> Bug #1444012 changed: 1.8beta2: settings page rendering is all messed up <oil> <MAAS:Confirmed for ricgard> <https://launchpad.net/bugs/1444012>
<mup> Bug #1446914 changed: 2015-04-22 00:36:04 [-] Error on request (25) node.check_power:  <oil> <MAAS:New> <https://launchpad.net/bugs/1446914>
<mup> Bug #1446915 changed: 2015-04-22 00:37:05 [root] ERROR:  <oil> <MAAS:New for rbanffy> <https://launchpad.net/bugs/1446915>
<mup> Bug #1447208 was opened: deferToThread should not wait for a thread in the same threadpool <MAAS:Triaged> <https://launchpad.net/bugs/1447208>
<mup> Bug #1447230 was opened: 1.8b3 MAAS favicon incorrect colour <ui> <MAAS:New> <https://launchpad.net/bugs/1447230>
<mup> Bug #1447262 was opened: 1.8b3 Weird timestamp on images page <ui> <MAAS:New> <https://launchpad.net/bugs/1447262>
<mup> Bug #1447319 was opened: 1.8b3 incorrect styling for selected navigation <ui> <MAAS:New> <https://launchpad.net/bugs/1447319>
<mup> Bug #1447320 was opened: 1.8b3 incorrect styling for selected tab <ui> <MAAS:New> <https://launchpad.net/bugs/1447320>
<mup> Bug #1447319 changed: 1.8b3 incorrect styling for selected navigation <ui> <MAAS:New> <https://launchpad.net/bugs/1447319>
<mup> Bug #1447320 changed: 1.8b3 incorrect styling for selected tab <ui> <MAAS:New> <https://launchpad.net/bugs/1447320>
<mup> Bug #1447319 was opened: 1.8b3 incorrect styling for selected navigation <ui> <MAAS:New> <https://launchpad.net/bugs/1447319>
<mup> Bug #1447320 was opened: 1.8b3 incorrect styling for selected tab <ui> <MAAS:New> <https://launchpad.net/bugs/1447320>
#maas 2015-04-23
<mup> Bug #1447573 was opened: [0-day SRU] maas needs to use python-django16 instead of 1.7 <maas (Ubuntu):New> <https://launchpad.net/bugs/1447573>
<mup> Bug #1446878 was opened: maas django app won't start "ImportError: No module named apt_pkg" <MAAS:Fix Committed by mpontillo> <MAAS 1.7:In Progress by andreserl> <maas (Ubuntu):In Progress by andreserl> <https://launchpad.net/bugs/1446878>
<mup> Bug #1447583 was opened: The background of the owner column on the node listing page stays grey <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1447583>
<mup> Bug #1447681 was opened: 1.8b3 Zones on "zone" page doesn't match zones on "node listing" <ui> <MAAS:New> <https://launchpad.net/bugs/1447681>
<mup> Bug #1447709 was opened: 1.8b3: Selections should be cleared when not displayed in list of filtered nodes or server should always be displayed until deselected <oil> <MAAS:New> <https://launchpad.net/bugs/1447709>
<mup> Bug #1447681 changed: 1.8b3 Zones on "zone" page doesn't match zones on "node listing" <ui> <MAAS:Won't Fix> <https://launchpad.net/bugs/1447681>
<mup> Bug #1447728 was opened: 1.8beta3: regiond and clusterd logs are rotated out too quickly <oil> <MAAS:New> <https://launchpad.net/bugs/1447728>
<mup> Bug #1446625 changed: package maas-region-controller 1.7.3+bzr3363-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned
<mup> error exit status 1 <amd64> <apport-package> <third-party-packages> <vivid> <maas (Ubuntu):In Progress by andreserl> <https://launchpad.net/bugs/1446625>
<mup> Bug #1447736 was opened: Node isn't removed from the node listing when it becomes non-visible <ui> <websockets> <MAAS:Triaged> <https://launchpad.net/bugs/1447736>
<mup> Bug #1447739 was opened: Node isn't added to the node listing when it becomes visible <ui> <websockets> <MAAS:New> <https://launchpad.net/bugs/1447739>
<mup> Bug #1447758 was opened: 1.8b3 Can't assign zones to deployed machines <ui> <MAAS:New> <https://launchpad.net/bugs/1447758>
<VijayT_> hello
<VijayT_> I am trying to commission nodes through MaaS
<VijayT_> and I need to change my default ntp server from ntp.ubuntu.com to my server. i have made appropriate changes in preseeds_master file
<VijayT_> after this also I notice that nodes after deployment do not get synced to my server. infact I error "ntpdate[884]: no server suitable for synchronization found" in syslog
<VijayT_> is there any other setting I need to change
<mup> Bug #1447783 was opened: 1.8b3 Failed deployment/release timeout <landscape> <power> <MAAS:New> <https://launchpad.net/bugs/1447783>
<mup> Bug #1447783 changed: 1.8b3 Failed deployment/release timeout <landscape> <power> <MAAS:New> <https://launchpad.net/bugs/1447783>
<mup> Bug #1447828 was opened: 1.8b3 number of nodes per zone on zones page inaccurate <ui> <MAAS:New> <https://launchpad.net/bugs/1447828>
#maas 2015-04-24
<mup> Bug #1447783 was opened: 1.8b3 Failed deployment/release timeout <landscape> <power> <MAAS:New> <https://launchpad.net/bugs/1447783>
<mup> Bug #1447961 was opened: MAAS  it can not install in ubuntu 15.04 server <MAAS:New> <https://launchpad.net/bugs/1447961>
<mup> Bug #1423613 changed: [0-day sru] maas needs to support systemd for Ubuntu >= 15.04 <hs-arm64> <verification-done> <MAAS:Fix Committed by andreserl> <maas (Ubuntu):Fix Released by andreserl> <https://launchpad.net/bugs/1423613>
<mup> Bug #1447961 changed: MAAS  it can not install in ubuntu 15.04 server <MAAS:New> <https://launchpad.net/bugs/1447961>
<mup> Bug #1446878 changed: maas django app won't start "ImportError: No module named apt_pkg" <verification-done> <MAAS:Fix Committed by mpontillo> <MAAS 1.7:In Progress by andreserl> <maas (Ubuntu):Fix Released by andreserl> <https://launchpad.net/bugs/1446878>
<mup> Bug #1447573 changed: [0-day SRU] maas needs to use python-django16 instead of 1.7 <verification-done> <maas (Ubuntu):Fix Released> <https://launchpad.net/bugs/1447573>
<mup> Bug #1447961 was opened: MAAS  it can not install in ubuntu 15.04 server <MAAS:New> <https://launchpad.net/bugs/1447961>
<mup> Bug #1423613 was opened: [0-day sru] maas needs to support systemd for Ubuntu >= 15.04 <hs-arm64> <verification-done> <MAAS:Fix Committed by andreserl> <maas (Ubuntu):Fix Released by andreserl> <https://launchpad.net/bugs/1423613>
<mup> Bug #1446878 was opened: maas django app won't start "ImportError: No module named apt_pkg" <verification-done> <MAAS:Fix Committed by mpontillo> <MAAS 1.7:In Progress by andreserl> <maas (Ubuntu):Fix Released by andreserl> <https://launchpad.net/bugs/1446878>
<mup> Bug #1447573 was opened: [0-day SRU] maas needs to use python-django16 instead of 1.7 <verification-done> <maas (Ubuntu):Fix Released> <https://launchpad.net/bugs/1447573>
<mup> Bug #1447961 changed: MAAS  it can not install in ubuntu 15.04 server <MAAS:New> <https://launchpad.net/bugs/1447961>
<mup> Bug #1423613 changed: [0-day sru] maas needs to support systemd for Ubuntu >= 15.04 <hs-arm64> <verification-done> <MAAS:Fix Committed by andreserl> <maas (Ubuntu):Fix Released by andreserl> <https://launchpad.net/bugs/1423613>
<mup> Bug #1446878 changed: maas django app won't start "ImportError: No module named apt_pkg" <verification-done> <MAAS:Fix Committed by mpontillo> <MAAS 1.7:In Progress by andreserl> <maas (Ubuntu):Fix Released by andreserl> <https://launchpad.net/bugs/1446878>
<mup> Bug #1447573 changed: [0-day SRU] maas needs to use python-django16 instead of 1.7 <verification-done> <maas (Ubuntu):Fix Released> <https://launchpad.net/bugs/1447573>
<mup> Bug #1293701 changed: Starting nodes en mass without ssh keys gives bad error message <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1293701>
<mup> Bug #1367511 changed: XML and YAML output should be line numbered. <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1367511>
<mup> Bug #1374070 changed: It's possible to remove the name from a node and MAAS won't supply a new one <confusing-ui> <ui> <MAAS:Invalid> <https://launchpad.net/bugs/1374070>
<mup> Bug #1375273 changed: 'Allocated', 'deploying' and 'deployed' nodes are all represented as 'allocated' on the frontpage dashboard. <node-lifecycle> <ui> <MAAS:Invalid> <https://launchpad.net/bugs/1375273>
<bdx> can anyone depict a way to commission and deploy other releases of ubuntu than trusty
<bdx> ?
<mup> Bug #1447783 changed: 1.8b3 Failed deployment/release timeout <landscape> <power> <MAAS:New> <https://launchpad.net/bugs/1447783>
<mup> Bug #1448338 was opened: unable to select power type or add a node using firefox <MAAS:Confirmed> <https://launchpad.net/bugs/1448338>
<mup> Bug #1448338 changed: unable to select power type or add a node using firefox <MAAS:Confirmed> <https://launchpad.net/bugs/1448338>
<mup> Bug #1448338 was opened: unable to select power type or add a node using firefox <MAAS:Incomplete> <https://launchpad.net/bugs/1448338>
#maas 2016-04-25
<mup> Bug #1526532 opened: [xenial, 1.10] enlistment failing <python3> <MAAS:Fix Committed by blake-rouse> <maas (Ubuntu):New> <https://launchpad.net/bugs/1526532>
<slacker27> Any update with the 1.9.2 package?
<slacker27> I have a node that doesn't seem to get past Commissioning, using MAAS 2.0.0. The node is PXE booting and getting an IP. I have verified that the node is reachable via ping, and even attempted to ssh into it (public key denial). Are there any logs I can check on the node about it's progress?
<mup> Bug #1562249 opened: Failed to deploy machine with HP Smart Array Raid 6i <landscape> <Landscape Server:Invalid> <MAAS:New> <https://launchpad.net/bugs/1562249>
<mup> Bug #1526532 changed: [xenial, 1.10] enlistment failing <python3> <MAAS:Fix Committed by blake-rouse> <https://launchpad.net/bugs/1526532>
<mup> Bug #1562249 changed: Failed to deploy machine with HP Smart Array Raid 6i <landscape> <curtin:New> <Landscape Server:Invalid> <MAAS:Invalid> <https://launchpad.net/bugs/1562249>
<mup> Bug #1562249 opened: Failed to deploy machine with HP Smart Array Raid 6i <landscape> <curtin:New> <Landscape Server:Invalid> <MAAS:Incomplete> <https://launchpad.net/bugs/1562249>
<mup> Bug #1574113 changed: No way to inject apt archive/mirror key 'in-target' before apt starts processing packages <curtin:Invalid> <MAAS:Invalid> <https://launchpad.net/bugs/1574113>
<dimitern> mpontillo, roaksoax, blake_r: hey guy, are you aware of the issues with deploying nodes commissioned with biosdevname-enabled releases (e.g. xenial) and having too long interface names (e.g. 'enxxaabbccddeef0' for a usb2eth second NIC)?
<dimitern> s/guy/guys/
<dimitern> maas (and curtin) render /e/n/i in this case which cannot be applied, as creating a VLAN on such an interface (e.g. 'enxxaabbccddeef0.1234') exceeds the device name limit of 16 characters
<dimitern> I'm filing a bug now for that
<dimitern> https://bugs.launchpad.net/maas/+bug/1574771
<mup> Bug #1574771 opened: MAAS/curtin generate invalid /e/n/i and failed deployment for nodes with long (biosdevname) interface names, which in turn have VLANs <networking> <robustness> <MAAS:New> <https://launchpad.net/bugs/1574771>
<mpontillo> dimitern: thanks, good find. Hadn't seen that before; will look.
<pronetla> Hi any can help whit my build?
<pronetla> is very simple
<pronetla> i can build ubuntu openstack private cloud whit 2 phisican servers?
<pronetla> phisical*
<mup> Bug #1574771 changed: MAAS/curtin generate invalid /e/n/i and failed deployment for nodes with long (biosdevname) interface names, which in turn have VLANs <networking> <robustness> <MAAS:Invalid> <MAAS 1.9:Invalid> <https://launchpad.net/bugs/1574771>
<mup> Bug #1571898 changed: [2.0 beta 2] Fabric's are not created sequencially <MAAS:Invalid> <https://launchpad.net/bugs/1571898>
<LiftedKilt> quick question - I've created a custom image in maas, and it shows up under the generated images section - but it doesn't appear in the dropdown for deployment
<LiftedKilt> is there an additional step I need to do to ready an image for deployment?
<roaksoax> LiftedKilt: has it been synced to the cluster controller ?
<LiftedKilt> roaksoax: aha no - the cluster-master is saying it is out of sync
<LiftedKilt> they are on the same machine - how do I force a sync?
<roaksoax> LiftedKilt: is there an error of why that might be ? no issues in the logs ?
<LiftedKilt> exceptions.IOError: Unable to open http://localhost:5240/MAAS/images-stream/custom/amd64/generic/rancheros0.4.4/20160425/root-tgz. mirrors=[]
<roaksoax> LiftedKilt: so that's the error...now i wonder what the underlying issue might be
<roaksoax> LiftedKilt: do you have enough disk space?
<LiftedKilt> roaksoax: yeah I've got plenty of space
<LiftedKilt> roaksoax: I'm going to try restarting maas-*
<LiftedKilt> nope. didn't fix it
<roaksoax> LiftedKilt: the weird thing is that it is an IOError, so i wonder if it is related to the image itself or something else
<LiftedKilt> it might be - it's an image for rancherOS
<roaksoax> LiftedKilt: never tested one of those
<LiftedKilt> images should be in tar.gz?
<LiftedKilt> it's available in tar.gz and iso
<roaksoax> LiftedKilt: that's probably the reason why then
<roaksoax> LiftedKilt: it is probably
<roaksoax> LiftedKilt: that
<roaksoax> LiftedKilt: the images need to be in tgz's yes
<LiftedKilt> the image i tried uploading was a tgz
<LiftedKilt> I was just making sure that was correct
<roaksoax> LiftedKilt: if you could file a bug, we'll be able to look at it
<LiftedKilt> roaksoax: ok - I'll poke at it first for a bit. I might try on 2.0 and see how that works
<roaksoax> LiftedKilt: to be fair that codepath is fairly unchanged
<LiftedKilt> roaksoax: ok - thanks
#maas 2016-04-26
<Guest13147> hello friends
<Guest13147> I have a query regarding node detection in maas
<alexlist> Guest13147: just ask your question...
<Guest13147> Do we need to install  tftp-hpa separately  in the cluster controller for the node detection ?
<Guest13147> and how maas will detect a new node. Do we need to configure it in maas ?
<Guest13147> hi friends, can anybody help me with the node detection in maas
<Ramefa> hi channel, I'm trying to get Maas working on my rack. Discovery of the node works but the IPMI part fail while commissioning. Looking in rackd.log I got this error which leads to exceptions in defer.py:
<Ramefa> 	provisioningserver.drivers.power.PowerActionError: Failed to power query 172.16.6.20:
<Ramefa> 2016-04-26 08:14:37+0100 [-] Unhandled failure dispatching AMP command. This is probably a bug. Please ensure that this error is handled within application code or declared in the signature of the b'PowerQuery' command. [MaaS:pid=10895:cmd=PowerQuery:ask=44]
<Ramefa> 	Traceback (most recent call last):
<Ramefa> 	  File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1184, in gotResult
<Ramefa> 	    _inlineCallbacks(r, g, deferred)
<Ramefa> Any one knows how to fix this ?
<mup> Bug #919913 opened: cron.d/remote_syslog_compress should skip .bz2 files <amd64> <apport-bug> <precise> <running-unity> <MAAS:New> <orchestra (Ubuntu):Confirmed for lynxman> <https://launchpad.net/bugs/919913>
<mup> Bug #1574113 opened: curtin/maas don't support derived repositories. We need a way to specify an archive key <curtin:New> <MAAS:New> <https://launchpad.net/bugs/1574113>
<mup> Bug #1574113 changed: curtin/maas don't support derived repositories. We need a way to specify an archive key <curtin:New> <MAAS:New> <https://launchpad.net/bugs/1574113>
<mup> Bug #1574113 opened: curtin/maas don't support derived repositories. We need a way to specify an archive key <curtin:New> <MAAS:New> <https://launchpad.net/bugs/1574113>
<roaksoax> smoser: https://launchpad.net/bugs/1574113
<roaksoax> smoser: we need a way to tell curtin about the mirror/archive key
<roaksoax> smoser: apt_mirror_key is what's added
<roaksoax> smoser: cripto proposed a branch there
<mup> Bug #1575209 opened: After enlisting IBM S822LC 8335 GTA autodetects IPMI 1.5 instead of IPMI 2.0 <oil> <MAAS:New> <https://launchpad.net/bugs/1575209>
<richardldn> does wol exist in maas 2?
<mup> Bug #1575209 changed: After enlisting IBM S822LC 8335 GTA autodetects IPMI 1.5 instead of IPMI 2.0 <oil> <MAAS:New> <https://launchpad.net/bugs/1575209>
<mup> Bug #1575209 opened: After enlisting IBM S822LC 8335 GTA autodetects IPMI 1.5 instead of IPMI 2.0 <oil> <MAAS:New> <https://launchpad.net/bugs/1575209>
<mimizone> Hi all. anybody could point me to examples of how udev rules could be added in the enlist/commission/deploy steps? I need to create symlinks on NICs. I use Maas 1.9
<mup> Bug #1575209 changed: After enlisting IBM S822LC 8335 GTA autodetects IPMI 1.5 instead of IPMI 2.0 <oil> <MAAS:New> <https://launchpad.net/bugs/1575209>
<mup> Bug #1575337 opened: [2.0a4] maas.log is empty <MAAS:Triaged> <https://launchpad.net/bugs/1575337>
<mup> Bug #1575337 changed: [2.0a4] maas.log is empty <systemd (Ubuntu):New> <https://launchpad.net/bugs/1575337>
<mup> Bug #1575337 opened: [2.0a4] maas.log is empty <systemd (Ubuntu):New> <https://launchpad.net/bugs/1575337>
<mup> Bug #1575337 opened: [2.0a4] maas.log is empty <systemd (Ubuntu):New> <https://launchpad.net/bugs/1575337>
<mup> Bug #1575337 changed: [2.0a4] maas.log is empty <maas (Ubuntu):Incomplete> <https://launchpad.net/bugs/1575337>
<DavidRama> Hi, started my maas today but got issue on several nodes. They're detected but no "power" icon in the collumn.  Is there a way to correct this behaviour ? Also sometimes my nodes when commisionned have their hardrive not detecte
<mup> Bug #1575337 changed: syslog.log is completely empty <rsyslog (Ubuntu):New> <systemd (Ubuntu):Incomplete> <https://launchpad.net/bugs/1575337>
<mup> Bug #1436471 changed: maas DHCP is a SPOF <canonical-bootstack> <MAAS:Fix Released> <https://launchpad.net/bugs/1436471>
<mup> Bug #1436473 changed: maas DNS is a SPOF <canonical-bootstack> <MAAS:Fix Released> <https://launchpad.net/bugs/1436473>
<mup> Bug #1436474 changed: maas tftp is a SPOF <canonical-bootstack> <MAAS:Fix Released> <https://launchpad.net/bugs/1436474>
<mup> Bug #1379570 changed: maas config files have inconsistent naming scheme <canonical-is> <trivial> <MAAS:Fix Released> <https://launchpad.net/bugs/1379570>
<mup> Bug #1575337 opened: syslog.log is completely empty <MAAS:New> <https://launchpad.net/bugs/1575337>
#maas 2016-04-27
<mup> Bug #1550510 changed: 1.9 UI Take action "Go" button for (re)commissioning a node with customized storage doesn't trigger the action <MAAS:Expired> <https://launchpad.net/bugs/1550510>
<mup> Bug #1575567 opened: Re-commissioning doesn't detect storage changes <MAAS:New> <https://launchpad.net/bugs/1575567>
<mup> Bug #1575587 opened: Can't add new machines <MAAS:New> <https://launchpad.net/bugs/1575587>
<mup> Bug #1575590 opened: MAAS 1.9 docs contain out of date screenshots <MAAS:New> <https://launchpad.net/bugs/1575590>
<mup> Bug #1575625 opened: Can't find way for MAAS to autodiscover IPMI settings <MAAS:New> <https://launchpad.net/bugs/1575625>
<mup> Bug #1575631 opened: TestStaticIPAddressManagerMapping.test_get_hostname_ip_mapping_returns_domain_head_ips fails spuriously <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1575631>
<DavidRama> Hi folks, can Maas set-up network ranges for the  interfaces on the hosts without having a NIC connected to them ?
<DavidRama> them == network ranges
<mup> Bug #1374447 changed: some dns queries not forwarded properly <MAAS:Invalid> <https://launchpad.net/bugs/1374447>
<roaksoax> DavidRama: If you are using 1.9, you need to setup a static and dynamic range
<roaksoax> DavidRama: the dynamic rnage is used for say, commissioning, or random machines obtaining IP's from MAAS
<roaksoax> DavidRama: the static range is used for IP to be given to machines when deploying, statically
<roaksoax> DavidRama: in 2.0+ the static range disappeared, the only one that remains is the dynamic range
<roaksoax> DavidRama: which allows MAAS to enlist/commissioning using an IP from there
<roaksoax> DavidRama: all machines you deploy, by default, will get an IP outside from static range
<mup> Bug # opened: 1575692, 1575693, 1575696, 1575697
<bugrum> I just installed MAAS 2.0 beta 3 on Ubuntu 16.04 LTS and I noticed that Wake on Lan is no longer an option in the Power Type dropdown when configuring nodes. Is Wake on Lan no longer supported on MAAS?
<mup> Bug #1575697 changed: test 4 <ux> <MAAS:Invalid> <https://launchpad.net/bugs/1575697>
<mup> Bug #1575815 opened: NIC previously discovered through commissioning no longer connected to Maas network <oil> <MAAS:New> <https://launchpad.net/bugs/1575815>
<bdx> hey whats up everyone? I can't seem to get my region-controller to recognize my rack-controller ... any ideas? MAAS Version 2.0.0 (beta3+bzr4941)
<mup> Bug #1533229 changed: 1.9 wily arm64 root-image fails to deploy on EFI system <curtin:Invalid> <MAAS:Invalid> <https://launchpad.net/bugs/1533229>
<mup> Bug #1547185 changed: backtrace in node.create_bcache <landscape> <MAAS:Invalid> <MAAS 1.9:Invalid> <https://launchpad.net/bugs/1547185>
<mup> Bug #1548542 changed: maas.drivers.power.ipmi: [WARNING] Failed to change the boot order to PXE <IP>  ipmi_ctx_open_outofband_2_0: BMC busy on Dell 12G servers <oil> <MAAS:Won't Fix> <https://launchpad.net/bugs/1548542>
<mup> Bug #1575910 opened: [2.0a4] Fabric and space lack a description field <MAAS:In Progress by blake-rouse> <https://launchpad.net/bugs/1575910>
<bdx> Hey hows it going everyone? How can I add a rack controller? I have followed the procedure outlined in the docs, but my rack-controller and its supporting services are not showing up ....
<bdx> I mean, I see a controller under my nodes tab, but when I select it, all of the rack-controller services are red
<bdx> also, when I select the images tab, I see "One rack controller is not yet connected to the region. Visit the rack controllers page for more information." at the top of the page
<bdx> can anyone lend some insight on how to get past this?
<bdx> thanks
<bdx> when I try to delete the skeleton rack-controller that exists, I get this -> http://paste.ubuntu.com/16088372/
<bdx> ^SOS^
<roaksoax> bdx: known bug, fixed in latest trunk
<roaksoax> bdx: or soon to be beta4
<bdx> roaksoax: can I upgrade to beta4 by using ppa:maas/devel ?
<roaksoax> bdx: but that being said, what errors do you ssee in rackd.log in the rack that's failing to conect ?
<roaksoax> blake_r: ^^
<roaksoax> bdx: haven't released beat4 just yet
<roaksoax> bdx: it will be tomorrow or friday
<blake_r> bdx: what is in rackd.log?
<blake_r> bdx: does it say its connecting?
<blake_r> bdx: seems like it is not connection to the region
<bdx> blake_r, roaksoax: http://paste.ubuntu.com/16088464
<blake_r> bdx: okay its getting rejected by the regin
<blake_r> bdx: whats in the regiond.log
<bdx> blake_r, roaksoax: http://paste.ubuntu.com/16088545/
<blake_r> mpontillo: ^ see the "Interface matching query does not exist"
<mpontillo> bdx: can you post the content of "sudo maas-rack support-dump --networking" on the rack that is failing to register?
<mpontillo> bdx: actually I bet I know what this is. if you've been upgrading through previous betas, you may have corrupted interfaces in your database. let me see if I can find the workaround
<mpontillo> blake_r: see https://bugs.launchpad.net/maas/+bug/1563701/comments/13
<mpontillo> bdx: ^ oops notified wrong person
<roaksoax> blake_r: i wonder if his issues would go away with latest trunk ?
<mpontillo> roaksoax: a fresh install would fix it if it's the issue I'm thinking of
<mpontillo> roaksoax: previous beta users who have VLAN interfaces will hit this bug where they have incorrect interfaces stored in the datbaase
<mpontillo> *database
<mpontillo> that is, VLAN interfaces on rack controllers.
<roaksoax> mpontillo: how do we clean that up though
<mpontillo> roaksoax: we could do a database migration to do it.
<roaksoax> mpontillo: yeah we might have to do that
<mpontillo> roaksoax: it's a bit of a toss-up at this point, as it would only affect users of early betas
<roaksoax> mpontillo: bhehe early beta1 nbeta2 or 3 ?
<mpontillo> roaksoax: fixed in beta 2 I think
<bdx> roaksoax, mpontillo, blake_r: `sudo maas-rack support-dump --networking` -> http://paste.ubuntu.com/16088880
<bdx> mpontillo: could I manually replace the incorrect legacy interface values in the db?
<bdx> what table should I be looking at here?
<mpontillo> bdx: don't worry, I spotted the bug ;-) blake_r: take a look at the paste, it looks like get_interfaces_definition() is returning incorrect parents. the get_ip_addr() output is correct, but the VLANs' parents are themselves?!
<mpontillo> bdx: are you able to file a bug?
<bdx> mpontillo: have you identified the fix as well?
<mpontillo> bdx: not yet
<bdx> lol ... tis all I do
<mpontillo> bdx: yeah the code is assuming the VLAN name format is "<parent>.<vid>" when in your case you are using the alternate format
<mpontillo> bdx: https://paste.ubuntu.com/16088926/ <-- sad code
<mpontillo> bdx: just FYI, the input into that function is the output of the top function in your paste, get_ip_addr(). so we actually have all the data we need to make this correct
<bdx> mpontillo: I was in the middle of a workflow that I was trying to deploy/use xenial in, I upgraded my test-maas from 14.04 to 16.04 ... is there anything I can do to get things back to working real quick, or will I need to wait for the patch to land?
<bdx> oh my
<bdx> I see
<bdx> ooh, hmm
<mpontillo> bdx: should be a pretty easy fix.. let me see if I can get a quick patch for you to try
<mpontillo> bdx: sudo patch -d /usr/lib/python3/dist-packages -i /tmp/patch -p1
<mpontillo> bdx: given https://paste.ubuntu.com/16088969/ in /tmp/patch
<mpontillo> bdx: can you tell me if that fixes it?
<bdx> ha ya
<bdx> that was super fast! nice!
<mpontillo> bdx: hope it works =)
<mpontillo> bdx: completely untested TBH, you are the guinea pig right now, just thought you might like a preview of the fix
<bdx> mpontillo: should I dpkg-reconfigure maa-rack-controller following the application of the patch?
<mpontillo> bdx: that should not be necessary, just restart the rackd service and tell me if it registers successfully
<bdx> how?
<bdx> oh, the twistd3 process?
<bdx> oh maas-rackd
<bdx> nm
<bdx> oooooooOOOooo
<bdx> Success!!!!
<bdx> so sick
<bdx> I bow to thee
<bdx> mpontillo: real nice
<mpontillo> bdx: awesome, thanks for testing it for us =)
<bdx> np
<roaksoax> mpontillo: that's fixed in trunk isn't it
<roaksoax> ?
<mpontillo> roaksoax: nope
<mpontillo> roaksoax: we need a bug for this
<bdx> I just made one
<bdx> https://bugs.launchpad.net/maas/+bug/1575945
<mup> Bug #1575945 opened: rack-controller not connecting <MAAS:New> <https://launchpad.net/bugs/1575945>
<mup> Bug #1575946 opened: dist-upgrade from trusty to xenial errors (maas 1.9 -> 2.0) <landscape> <MAAS:New> <https://launchpad.net/bugs/1575946>
<bdx> mpontillo: how can I get dhcp going on my maas-mgmt network again?
<bdx> oh nm, I think I see
<bdx> yea, actually, how do I configure dhcp?
<bdx> I from what I can gather it is on, on the desired subnet, I just don't know how to introspect that from the gui ...?
<bdx> ahh, ok, dhcp is active
<bdx> on my maas-mgmt network ... I just don't see where or how. .... this must be upcoming gui functionality ?
<mpontillo> bdx: that info is on the vlan details page; the range is on the subnet details page. Not all of it can be edited from the UI in the current beta
<bdx> ok, I see
<bdx> mpontillo, blake_r, roaksoax: thanks for your help today!
<bdx> is maas2.0 not compatible with < juju2?
<mup> Bug #1575951 opened: upgrade of maas from 1.9.1 to 2.0 'str' object has no attribute 'version' <landscape> <MAAS:New> <https://launchpad.net/bugs/1575951>
<mpontillo> bdx: https://jujucharms.com/docs/devel/introducing-2#maas-2.0
<mpontillo> bdx: sadly I don't think MAAS 2.0 support made it in time for Xenial; you may need a dev release of juju
<mpontillo> bdx: I haven't tried it yet myself.
<bdx> do I have to bootstrap with that flag set, or is it enough to just set it?
<bdx> ok
<mpontillo> bdx: I'd assume you would need to bootstrap with that, since bootstrap makes use of MAAS
<mpontillo> IIRC ;-)
<rp_> Any one have info on a replacement for image-builder?  seems to be deprecated and advised to use maas/main.
#maas 2016-04-28
<mup> Bug #1576006 opened: 1.9.1: trying to save an overlapping network in the cluster generates ugly 500 <landscape> <MAAS:New> <https://launchpad.net/bugs/1576006>
<mup> Bug #1576116 opened: MAAS adds regions controller as DNS resolver <MAAS:New> <https://launchpad.net/bugs/1576116>
<mup> Bug #1576116 changed: MAAS adds regions controller as DNS resolver <MAAS:New> <https://launchpad.net/bugs/1576116>
<mup> Bug #1576116 opened: MAAS adds regions controller as DNS resolver <MAAS:New> <https://launchpad.net/bugs/1576116>
<mup> Bug #1576146 opened: test 5 <MAAS:New> <https://launchpad.net/bugs/1576146>
<mup> Bug #1576194 opened: Enlistment via DHCP fails because DNS has bogus PTR record <landscape> <MAAS:New> <https://launchpad.net/bugs/1576194>
<mup> Bug #1575693 changed: test 2 <ui> <MAAS:Invalid> <https://launchpad.net/bugs/1575693>
<mup> Bug #1575693 opened: test 2 <ui> <MAAS:Invalid> <https://launchpad.net/bugs/1575693>
<mup> Bug # changed: 1575692, 1575693, 1575696, 1576146
<mup> Bug #1575692 opened: this is a test <ui> <MAAS:Invalid> <https://launchpad.net/bugs/1575692>
<mup> Bug #1575696 opened: test 3 <design> <MAAS:Invalid> <https://launchpad.net/bugs/1575696>
<mup> Bug #1576146 opened: test 5 <MAAS:Invalid> <https://launchpad.net/bugs/1576146>
<mup> Bug #1575692 changed: this is a test <ui> <MAAS:Invalid> <https://launchpad.net/bugs/1575692>
<mup> Bug #1575696 changed: test 3 <design> <MAAS:Invalid> <https://launchpad.net/bugs/1575696>
<mup> Bug #1576146 changed: test 5 <MAAS:Invalid> <https://launchpad.net/bugs/1576146>
<mup> Bug #1576267 opened: [UI 2.0b3] interface addresses on rack controller details page not updated automatically <MAAS:Triaged> <https://launchpad.net/bugs/1576267>
<mup> Bug #1576357 opened: Determine a method for how to reconnect a deleted rack controller <MAAS:New for ltrager> <https://launchpad.net/bugs/1576357>
<mup> Bug #1508741 changed: IPMI driver does not handle timeouts correctly <MAAS:Fix Released by newell-jensen> <https://launchpad.net/bugs/1508741>
<mup> Bug #1576370 opened: Create node lifecycle models for region and rack controllers <MAAS:New for ltrager> <https://launchpad.net/bugs/1576370>
<mup> Bug #1576146 opened: test 5 <MAAS:New> <https://launchpad.net/bugs/1576146>
<mup> Bug #1576146 changed: test 5 <MAAS:Invalid> <https://launchpad.net/bugs/1576146>
<DavidRama> hi all
<DavidRama> I've been struggling for days, having servers that do not provision without amy reason (got same hardware based server that are correctly provisionned). If I look at the IPMI Console I see that the deploy works fine but Maas still seems to wait for something. Looking at the server logs on Maas last command pass is : Node installation - 'curtin' curtin command block-meta .
<DavidRama> I can log to the deply stuck server using ssh
<roaksoax> DavidRama: so, your machines enlist, commission but don't deploy ?
<roaksoax> DavidRama: do they switch from Deploying to Failed Deployment ?
<maileh> h
<DavidRama> at the end yes
<roaksoax> DavidRama: hwat version of MAAS? 2.0 or 1.9 ?
<roaksoax> DavidRama: can you  please share the installation log ? (it is in the webUI at the bottom)
<roaksoax> DavidRama: also, the full node event log ?
<maileh> DEBUG: 04-22 00:59:20, multi.py:135] Problem during bootstrap: '{'err': 'Bootstrapping environment "maas"\nStarting new instance for initial state server\nLaunching instance\nWARNING no architecture was specified, acquiring an arbitrary node\nWARNING no architecture was specified, acquiring an arbitrary node\nWARNING no architecture was specified, acquiring an arbitrary node\nWARNING no architecture was specified, acquiring an arbitrar
<maileh> maas version 1.9
<roaksoax> maileh: do you have images imported ? is the cluster controller connected ?
<maileh> i just read this now https://en.wikipedia.org/wiki/HP_Integrated_Lights-Out ... do i need to adjust my
<maileh> server
<maileh> roaksoax: yes everything looks normal ... nodes was successfully list and commissioned with the CPU and RAM info display but not the storage or the disk it is appear as zero
<maileh> it has the same error as juju complain above of the ui
<mup> Bug #1573046 opened: 14.04 images not available for commissioning as distro-info --lts now reports xenial <landscape> <sts> <MAAS:Fix Released by andreserl> <maas (Ubuntu):New for freyes> <maas (Ubuntu Trusty):New> <maas (Ubuntu Wily):New> <https://launchpad.net/bugs/1573046>
<mup> Bug #1576370 changed: Create node lifecycle models for region and rack controllers <MAAS:Invalid by ltrager> <https://launchpad.net/bugs/1576370>
<maileh> roaksoax: here is the nodes on the maas web interface  Search nodes Submit FQDN  MAC	Power	Status	Owner	Cores	RAM (GiB)	Disks	Storage (GB) ACER-PC1-FG.KalianetCLOUD.to		Ready		2	1	0	0.0 HP-SRV1-FG.KalianetCLOUD.to		Ready		4	2	0	0.0
<maileh> if you can see the 0.0 as the end are for the disk and storage
<maileh> any update guyss
<roaksoax> maileh: did you configure the storage of your servers
<roaksoax> maileh: Specify a storage device to be able to deploy this node.", "Mount the root \'/\' filesystem to be able to deploy this node.
<maileh> no i did not
<roaksoax> maileh: it seems you dont have a / mounted to be able to deploy your machjine
<maileh> where can i do that
<maileh> should i partition and format my hd before add to maas
<roaksoax> maileh: no
<roaksoax> maileh: go to your machine in MAAS, one that's on Ready state
<roaksoax> maileh: and check the storage section
<roaksoax> maileh: what do you have there ?
<maileh> this is the error on my machine page Storage No storage information. Commissioning this node will gather the storage information. Specify a storage device to be able to deploy this node. Mount the root '/' filesystem to be able to deploy this node.
<maileh> but it was successfully commisioned and READY state
<maileh> that's why i am confused
<roaksoax> maileh: go to the commissioning output at the bootom
<roaksoax> maileh: but either way, it seems it failed to discover your devices
<roaksoax> maileh: what type of hardware is it, and what storage devices are they ?
<maileh> HP Proliant G4 is the model
<maileh> sorry the model is DL380 G5
<maileh> HP Proliant
<roaksoax> maileh: do they have properietary storage array or something ? that requires a proprietary hardware ?
<roaksoax> blake_r: whywould it not discover storage ?
<roaksoax> DavidRama: if you can pastebin the output, it would be great (in the UI, at the bottom, you'll have the installation log)
<roaksoax> DavidRama: and the full node event log, there's a link to open it fully
<roaksoax> DavidRama: pastebin.ubuntu.com
<maileh> roaksoax: label on disk is Dual port 10K SAS 72G
<maileh> i have 4 of those on my server
<roaksoax> blake_r: ^^
<maileh> roaksoax: i believe the parts number for these disk is 389346-001
<roaksoax> maileh: so go to the bottom of your machine
<roaksoax> maileh: there's a dropdown
<roaksoax> maileh: check the commissioning output
<roaksoax> the storage section
<maileh> ok will do that and let you know
<maileh> fyi this is my cluster detail Clusters Name	Connected	Status	Managed interfaces	Nodes	Images	 Cluster master	â	Enabled	1	2	Synced	edit delete
<roaksoax> marlinc: 00-maas-07-block-devices.out
<roaksoax> err
<roaksoax> maileh: 00-maas-07-block-devices.out
<roaksoax> 00-maas-07-block-devices.err
<roaksoax> those two
<DavidRama> roaksoax: my deploy hangs at this step in the gui log: TFTP Request - libutil.c32  after PXE Request - local boot
<DavidRama> mmm looks like it maas srv still sees the server as powered on but node is off
<maileh> roaksoax: this is 00-maas-07-block-devices.out ... this is its content : [  {   "BLOCK_SIZE": "4096",    "NAME": "sda",    "ID_PATH": "/dev/disk/by-id/wwn-0x3000000300000001",    "PATH": "/dev/sda",    "ROTA": "1",    "RM": "0",    "MODEL": "VIRTUAL-DISK",    "RO": "1",    "SERIAL": "3000000300000001",    "SIZE": "1468006400"  },   {   "BLOCK_SIZE": "4096",    "NAME": "cciss!c0d0",    "ID_PATH": "/dev/disk/by-id/wwn-0x600508b100104d395
<DavidRama> Installation finished.
<DavidRama> but node hangs in "deploying status" (5 minutes now)
<DavidRama> ok node off in real but showed as on in the GUI
<maileh> i have only one line with .err ...00-maas-03-install-lldpd.err ...it's content is initctl: Unknown job: lldpd stop: Unknown instance:
<maileh> roaksoax: ....??
<maileh> roaksoax: this is for my other server , actually it is an ACER PC .....[  {   "BLOCK_SIZE": "4096",    "NAME": "sda",    "ID_PATH": "/dev/disk/by-id/wwn-0x3000000300000001",    "PATH": "/dev/sda",    "ROTA": "1",    "RM": "0",    "MODEL": "VIRTUAL-DISK",    "RO": "1",    "SERIAL": "3000000300000001",    "SIZE": "1468006400"  } ]
<maileh> roaksoax: there is no 00-maas-07-block-devices.err to both of them ...
<roaksoax> DavidRama: when the installation fininshes, the node reboots
<roaksoax> DavidRama: and loads the deployed environment
<roaksoax> DavidRama: and contact's maas again to tell it the deployment finished
<roaksoax> DavidRama: if that's not ahppeneing, there may be  a reason for that
<maileh> roaksoax: any suggestion yet
<roaksoax> maileh: i'd suggest you file a bug report, with the details of your hardware, and attach that file you are pastebinbing
<roaksoax> or pasting
<DavidRama> roaksoax: is there a place to look for this kind of failure ?
<DavidRama> having this issue on 4 nodes and not on 12 others sitting in the same place
<DavidRama> same hardware
<roaksoax> DavidRama: i'd wathc the console
<maileh> roaksoax: can you suggest how to do that ... sorry but i have not file a bug before .... hope you can help ... thanks
<roaksoax> DavidRama: can you watch the console to see what's going on while the machine deploys ?
<roaksoax> maileh: https://bugs.launchpad.net/maas/+filebug
<DavidRama> I can
<DavidRama> need to start java
<DavidRama> @roaksoax: WARN: No MBR magic
<mup> Bug #1576417 opened: rack controllers and region controllers should not be visible to non-admins <MAAS:New> <https://launchpad.net/bugs/1576417>
<maileh> roaksox: also what's your best shot ... is it my hardware does not support or is it that i need
<mup> Bug #1576427 opened: juju bootstrap error complaining about my storage <MAAS:New> <https://launchpad.net/bugs/1576427>
#maas 2016-04-29
<maileh> roaksoax: anything you might suggest and i have'nt recieved anything after filing the bug
<maileh> this is another extract from Commission Summary hw:setting:                 id: modified                 value: 2016-03-14 22:24:35               - lshw:setting:                 id: mount.fstype                 value: ext4               - lshw:setting:                 id: mount.options                 value: ro,relatime,data=ordered               - lshw:setting:                 id: mounted ....looks like it is OK
<maileh> roaksoax: anything yet ???
<mup> Bug #1576468 opened: APC Power Driver - NoneType' object has no attribute 'decode' <MAAS:Triaged by newell-jensen> <MAAS 1.9:Triaged by newell-jensen> <https://launchpad.net/bugs/1576468>
<maileh> alexlist: can you help with my issue
<maileh> helo anyone online now ???
<maileh> helo
<maileh> hellow
<DavidRama> hello
<maileh> hi david .... are you able to help my issue
<maileh> MAAS successfully commisioned my two nodes yet it shows error on my machines detail page on storage section saying that i need to commossion my nodes before disk can be setup
<maileh> david: ????
<DavidRama> maileh: sorry I'm new to that also
<mup> Bug #1576758 opened: [2.0b3] IP Ranges section on the subnet page should be shown even if no ranges <MAAS:New> <https://launchpad.net/bugs/1576758>
<bdx> hey whats up everyone?
<bdx> will beta -> stable upgrades be supported?
<bdx> for maas2.0
<roaksoax> bdx: upgradability is a primary focus for maas
<roaksoax> bdx: but yes, you'll be able to upgrade from beta to final without issues
<bdx> roaksoax: awesome, thanks
<bdx> roaksoax: when are you guys planning on dropping beta4?
<roaksoax> bdx: we are testing right now
<roaksoax> bdx: and waiting for a couple bug fixes to land
<bdx> roaksoax: right on, will beta4 have improved functionality for lxd/lxc networking?
<roaksoax> bdx: that actually comes from Juju
<roaksoax> bdx: since MAAS doesn't really deploy lxd containers
<roaksoax> bdx: but yes, maas 2.0 w/ juju 2.0 should have better lxd container networking
<bdx> roaksoax: doesn't maas provision the network interfaces on containers though?
<roaksoax> bdx: not for containers
<bdx> ok
<roaksoax> bdx: so since MAAS 1.8+ i think we supported registering containers , but juju never used the feature by default
<roaksoax> bdx: maas ensures that IP addresses are reserved for the container and specific interface and such
<roaksoax> bdx: but juju never used the feature by default
<roaksoax> bdx: when you enabled it, juju didn't write e/n/i for the container, so maas would deliver everythin via DHC{
<roaksoax> bdx: when you enabled it, juju didn't write e/n/i for the container, so maas would deliver everythin via DHCP
<roaksoax> bdx: but since MAAS doesn't really provision the container, it cannot write e/n/i for it
<bdx> totally
<bdx> but the container gets its provisioning metadata from MAAS yea?
<roaksoax> bdx: so, supposedly, Juju 2.0 will enable container registration in MAAS by default, and correctly e/n/i
<roaksoax> bdx: but haven't tested yet
<roaksoax> bdx: nope, conatiner gets everything from juju, other than the IP addresses
<roaksoax> bdx: basically, juju just says "register a device under machine XYZ, and I want IP addresses for A, B, C interfaces/mac addresses"
<bdx> I see
<roaksoax> bdx: and maas returns that info, and juju creates the container, and configures it as ti should
<bdx> but how does juju/maas know what interface to attach the container to?
<roaksoax> bdx: so say in a machine you configured eth0 to subnet1, eth1 to subnet2
<roaksoax> bdx: when you deploy a machine, juju asks for a machine in subnet1/subnet2
<roaksoax> bdx: and if you want your container in subnet1
<roaksoax> bdx: it puts it in subnet1
<roaksoax> bdx: so MAAS provides the interfaces juju needs to do that
<bdx> I see, do you know where this code lives, does it exist yet?
<roaksoax> bdx: putting it on a different way, MAAS provides juju with information about the phisical world, so juju can do stuff
<bdx> totaly
<roaksoax> bdx: on juju, I don't know where it lives
<bdx> ok
<roaksoax> bdx: on maas, we do it via constraints
<roaksoax> mpontillo: ^^ where are the network constraints ?
<bdx> but if no constraints are passed, is a default used?
<roaksoax> bdx: yeah if no constraints are passed, juju just takes the first interface of MAAS IIRC
<bsod90> hey guys! I have a question: when maas is deploying one of my nodes which has 2 NICs connected to 2 different networks, both enabled, one getting IP from MAAS DHCP, another one from the other network DHCP. How does it decide which default route to set? I'd like it to always point to our company network rather that management one, but I'm feeling like it's set just randomly.
<bdx> bsod90: your machine will use the last gateway route configured
<bdx> bsod90: I get around that by not setting the gateway in my subsequent dhcp configured interfaces
<roaksoax> bsod90: you can set that in maas : maas <session> node-interface set-default-gateway
<bdx> roaksoax: I see, what if your interfaces can't talk on the same net?
<bdx> similar to my situation
<roaksoax> bdx: then this may solve your problem? https://bugs.launchpad.net/maas/+bug/1519828
<roaksoax> :)
<roaksoax> bdx: we might do that for 2.1
<bdx> if I set dhcp on multiple subnets using maas, my nodes error when pxe booting due to getting dhcp from the wrong subnet
<bsod90> I see. Thank you, bdx and roaksoax
<bdx> roaksoax: so, I just configured 3rd party dhcp <- also doesn't set the gateway on subsequent interfaces
<mpontillo> roaksoax: bdx: when you use the "machines allocate" endpoint you can specify a list of constraints (should be documented in the normal way the APIs are doc'd)
<roaksoax> bdx: you are setting DHCP on multiple subnets under the same VLAN ? or different VLANs ?
<mpontillo> roaksoax: bdx: you can also use the "verbose" and "dry_run" options on that endpoint to experiment with constraints and see a little more info
<bdx> different vlans
<bdx> mpontillo: oooh thats awesome
<mpontillo> roaksoax: bdx: basically when that API returns you will see a "constraints_by_type" object on the node, specifying which storage or interface constraints matched what you specified
<roaksoax> bdx: so that means the machine has eth0 and eth1, eth0 being PXE, but it DHCP's from the range that is supposed to be on a different VLAN to where the node has been connected to ?
<roaksoax> bdx: and physically, they are different 'untagged' VLANs or the same VLAN in the switch?
<bdx> roaksoax: I can replicate in all scenarios ...
 * mpontillo steps out for lunch
<bdx> roaksoax: a node with multiple interfaces, each interface gets dhcp from maas on different vlan and subnet
<bdx> it hasn't made a difference whether the vlans are on separate switches, I disallow all comms from one to the other at the router level
<roaksoax> bdx: right, but in MAAS you do that by enabling DHCP on different vlans on the same fabric, or same VLANS (for example, untagged), on different fabrics
<bdx> roaksoax: entirely
<roaksoax> bdx: so say, fabric0->untagged->subnet1 fabric1->untagged->subnet2
<roaksoax> bdx: and fabric0/fabric1 is a different collection of switches
<roaksoax> anyway
<roaksoax> i'm giuessing this may be the issue with isc-dhcp we have a bug for
<bdx> roaksoax: I see, yea, but how do you stop maas from handing out pxe on non mgmt subnets?
<bdx> I think that is (at a high level) the root issue
<roaksoax> bdx: oh so you mean you dont want to provide a next-server in certain subnet's range ?
<roaksoax> bdx: can you file a bug for that ?
<bdx> roaksoax: entirely, provide dhcp, but not next. but I don't know how to make that happen within the context of maas
<bdx> yea
<roaksoax> bdx: i was thiking about that couple weeks ago
<roaksoax> bdx: but completely forgot about it :)
<bdx> yea, its been biting me since 1.7
<roaksoax> bdx: but yes, I do think it makes sense. You may want to enable DHCP on VLAN1, but not specifically for PXE, just for machines to get IP'sl from there
<roaksoax> bdx: but in 1.9/2.0 you do know you don't really need to set DHCP for a NIC that's not management ...
<roaksoax> bdx: you can allow maas to configure e/n/i for that interface, in the subnet you want
<roaksoax> bdx: which is not "management"
<bdx> so, what you are saying basically, is that the work around is to use other methods than dhcp to configure subsequent interfaces ?
<bdx> I see
<roaksoax> bdx: right, so say eth0 (pxe) -> fabric0 -> subnet1 -> auto-assign -> this would be NIC for the management netework
<roaksoax> bdx: but then, eth1 -> fabric1 -> subnet1 -> auto-assign
<roaksoax> bdx: maas would automatically pick an IP on subnet1
<roaksoax> bdx: so you could even do:
<roaksoax> eth0 (pxe) -> fabric0 -> untagged -> subnet1 -> auto-assign
<bdx> Ahhh, auto-assign does not use dhcp?
<roaksoax> eth1.1 -> fabric0 -> vlan1 -> subnet2 -> auto-assign # no DHCP is enabled in VLAN10, but MAAS will automatically pick an IP on subnet2
<bdx> entirely
<roaksoax> bdx: starting from 2.0, DHCP is really only used for enlistment and commissioning
<bdx> ahhh, I see. Well that basically solves the issue
<roaksoax> bdx: (same is the case for 1.9, but we had static ranges in the past, MAAS 2.0 no longer has static ranges)
<bdx> I see that
<roaksoax> bdx: but the bug you mention, about allowing to enable DHCP without PXE is completely valid
<bdx> ok, I'll file it
<roaksoax> thanks!
<bdx> so, while I've got your attention .... the other issue that has caused a great deal of contention for me is disk replacement
<bdx> I'm sure you are familiar with the issues surrounding disk replacement ?
<roaksoax> bdx: meaning, you have a machine deployed, disk failed, you want to replace it, but want to keep your machine deployed, and not release it and recommission /
<roaksoax> ?
<bdx> exactly
<roaksoax> bdx: yes, I've heard about the issue
<roaksoax> we currently not support that yet, but I'll definitely raise that
 * roaksoax takes note
<bdx> if I reboot with out recommissioning, my disks numbering get out of whack and I endup borking the node
<bdx> thank you
<bdx> this has caused me multiple trips to the datacenter, and has been probably the lagest point of contention I've had using MAAS to date
<bdx> I appreciate you looking into it
<bdx> I filed a bug a while back .... let me see if I can't dig it up
<roaksoax> bdx: np! the only issue I can think related to that, is that the new disk won't have the same partitioning as maas think the disk has
<roaksoax> but we can definitely explore that and see if that lands in the roadmap for 2.1
<bdx> yea, so, I can't get maas to recognize the new disk w/o recommissioning, the os will reletter the disks upon reboot, and then maas has a new /dev/sda, that wasn't previously sda :-(
<bdx> the os does at least
<bdx> maas retains the previous disk assignments
<bdx> and thus the issue
<bdx> thanks for hearing me out
<roaksoax> bdx: yeah, I know what you mean. We've talked about that before indeed
<roaksoax> bdx: maas doesn't have a way to discover current partitioning
<roaksoax> so maas would need to grow a way to enter into a maintenance mode while deployed
<roaksoax> and do a "recommission"
<roaksoax> but force the user to re-partitioning
<roaksoax> and maas would just update the knowledge it has about disks
<roaksoax> or something along those lines
<bdx> entirely, that would be HUGE
<bdx> I feel like MAAS deployed storage nodes are ticking timebombs to that affect
<roaksoax> yeah I'll bring that up when we discuss MAAS roadmap next
<bdx> SUPER!
<bdx> the CIO of my company constantly brings up the storage thing as a downside to implementing MAAS in production ... you can use that as firepower if you want
<roaksoax> bdx: hehe, don't worry it is already added in the ideas section
<roaksoax> but will use that as feedback from the field
<Chuckuzzo> using version 1.9.1, MAAS CLI to assign a VLAN to a space.  Getting "Too many Subnet objects match the given query"â¦ any idea?
<roaksoax> mpontillo: ^^
<mpontillo> Chuckuzzo: can you pastebin the exact command you're using?
<mpontillo> (or just paste it, should be short) ;-)
<Chuckuzzo> maas mymaas subnet update vlan:50 name=public-api space=4 gateway_ip=10.50.0.1
<Chuckuzzo> Following Dimiter's blog
<Chuckuzzo> https://insights.ubuntu.com/2016/01/23/maas-setup-deploying-openstack-on-maas-1-9-with-juju/
<mpontillo> Chuckuzzo: ah, yeah, it would be nice if that affected both subnets in that VLAN, come to think of it. but that's currently not how it works
<mpontillo> Chuckuzzo: it seems that you need to narrow your subnet query so that it only matches a single subnet
<Chuckuzzo> Would that be in MAAS setup or the OS network side?
<mpontillo> Chuckuzzo: well, you can use the same command, but to place your subnet into that space use "ip:<any-ip-address-in-the-subnet>" for each subnet you want to place into the space
<mpontillo> Chuckuzzo: in place of "vlan:50" that is
<mpontillo> Chuckuzzo: or you can specify the subnet by ID, but that would require looking it up
<Chuckuzzo> I'll give that a try
<Chuckuzzo> That worked
<Chuckuzzo> Many thanks!
<mpontillo> Chuckuzzo: np
<mup> Bug #1576854 opened: MAAS should be able to use power commands with rack controllers <MAAS:New for ltrager> <https://launchpad.net/bugs/1576854>
#maas 2016-04-30
<mup> Bug #1576929 opened: 1.9.2 proposed: maas ptr 2 hosts enlistment fails <landscape> <MAAS:New> <https://launchpad.net/bugs/1576929>
<mup> Bug #1576984 opened: MAAS v.2 (Beta) shows wrong CPU Core count on dashboard <cpu> <maas> <MAAS:New> <https://launchpad.net/bugs/1576984>
<mup> Bug #1577013 opened: Parsing error in  get_updates_package provisioningserver/boot/utils <MAAS:New> <https://launchpad.net/bugs/1577013>
<karan> I'm having trouble enlisting node using ubuntu 16 xenial boot image
<karan> I've captured cloud-init.log and cloud-init-output.log
<karan> can anybody look in to it?
<karan> The problem I see in cloud-init-output.log is thi error
<karan> sh: 786: maas-ipmi-autodetect-tool: not found
#maas 2016-05-01
<olavgg> Hi guys! I have a problem with MAAS that I can't figure out, if I try to create a subnet in the WEBUI it fails with the following error: Extra data: line 1 column 4 (char 3)
<olavgg> is this a bug?
#maas 2017-04-24
<mpontillo> jac_: is the 'vlan' package installed? any errors in the syslog or dmesg?
<mup> Bug #1581727 changed: [2.0b5] Document that we need to configure postgres allows connections from external hosts <doc> <maasgh> <MAAS:Expired> <https://launchpad.net/bugs/1581727>
<cnf> has anyone configured their maas controller as a NAT gateway?
<allenap> Hi. Does anyone know where or if the docs from the MAAS source are published these days? The docs at https://docs.ubuntu.com/maas/ are new, written by the docs team, and I have no complaints about them, but the from-source docs have a lot of other information in them, especially around how to develop MAAS itself.
<pmatulis> hi allenap, we're working on making the Dev docs part of docs.u.c
<allenap> pmatulis: Tip top, thanks. In the meantime are they available only via a checkout of the source?
<Flint> Good afternoon/morning everyone!
<Elm0> ok, is there anyone here?
<Elm0> I need some help with Windows images if anyone already worked with.
<cnf> not I
<pmatulis> allenap, yep
<allenap> Ta.
<Elm0> I mean, is a "classic" image build for windows (the way we build it on Openstack with packer) is suppose to work?
<Elm0> no one?
<cnf> Elm0: it is PXE booted
<cnf> i have no experience with pxe booting windows installers
<mup> Bug #1685807 opened: MaaS does not discover storage devices on Lenovo System x3650 M5 <MAAS:New> <https://launchpad.net/bugs/1685807>
<Elm0> cnf: I want to build a windows Image to provide to maas, but I don't want to use cloudbase.it tool as I already have a working pipeline using packer which build Windows images for Openstack
<cnf> Elm0: you want to live boot windows? not install it?
<cnf> ie, it lives in ram?
<mup> Bug #1685807 changed: MaaS does not discover storage devices on Lenovo System x3650 M5 <MAAS:New> <https://launchpad.net/bugs/1685807>
<Elm0> nop, I want like with any linux, maas to be used as the PXE images provider.
<cnf> Elm0: "like with any linux", maas boots into an _installer_
<cnf> Elm0: which then installs a distribution to disk
<Elm0> cnf: yes, that is that kind of information that I need ^^ thx
<cnf> np
<cnf> i have no idea how to pxe boot a windows installer, though
<Elm0> using windows PE
<Elm0> with a unattend installer
<Elm0> file
<mup> Bug #1685807 opened: MaaS does not discover storage devices on Lenovo System x3650 M5 <MAAS:New> <https://launchpad.net/bugs/1685807>
<cnf> i'd like to figure out how to install ESXi with MaaS :P
<Elm0> cnf: Another question that's stuck running in my head is, how the maas Âµos is launching the install of a virtual HDD using the cloudbase.it tool which launch a VM then create and install a windows and then upload the resulting virtual HDD
<Elm0> cnf: me too ^^ I'll need to boot ESXi nodes at some point eventually :D
<Elm0> cnf: BOOM!! http://bazaar.launchpad.net/~maas-committers/maas/trunk/view/head:/src/provisioningserver/boot/windows.py
<cnf> let me know if it works :P
<Elm0> cnf: I'm out from this week until the middle of may, so, I'll update you then.
<vasey> hey folks, i'm getting a "did not find any datasource" error when my hosts complete PXE booting into ubuntu 16.04.2 LTS...any idea what the issue is? the hosts are successfully getting DHCP addresses and booting, but the cloud-init fails because of this datasource issue
<Elm0> vasey: I had this error if my rackd server is on a different subnet than my regiond.
<vasey> elm0: hmmm, i've got everything on the same subnet for now, and i know everything can ping everything else
<xygnal> mpontillo: was there a way to up log level in maas?  I am not finding errors or tracebacks that indicate a problem.  trying to get more information out of it.
<mpontillo> xygnal: if there is a traceback, it will be in /var/log/maas inside regiond.log or rackd.log. what's the issue?
<mup> Bug #1683542 opened: After configuing Ubuntu Core system still displays subiquity wizard <cloud-init:Won't Fix> <MAAS:Triaged> <https://launchpad.net/bugs/1683542>
<mup> Bug #1685835 opened: MAAS doesn't ignore pre-composed node remote storage if InitiatorIQN is non-empty <MAAS:Triaged by newell-jensen> <MAAS RSD :Triaged by newell-jensen> <https://launchpad.net/bugs/1685835>
<mup> Bug #1683542 changed: After configuing Ubuntu Core system still displays subiquity wizard <cloud-init:Won't Fix> <MAAS:Triaged> <https://launchpad.net/bugs/1683542>
<mup> Bug #1685835 changed: MAAS doesn't ignore pre-composed node remote storage if InitiatorIQN is non-empty <MAAS:Triaged by newell-jensen> <MAAS RSD :Triaged by newell-jensen> <https://launchpad.net/bugs/1685835>
<xygnal> mpontillo: yes we were talking about this last week.  Comissions work, but deployments end up on temporary dhcp scope instead of auto-assign, and the UI goes to 'unmanaged'.
<xygnal> mpontillo: I have plenty of tracebacks, 99% sure none of them will tell you anything
<mup> Bug #1683542 opened: After configuing Ubuntu Core system still displays subiquity wizard <cloud-init:Won't Fix> <MAAS:Triaged> <https://launchpad.net/bugs/1683542>
<mup> Bug #1685835 opened: MAAS doesn't ignore pre-composed node remote storage if InitiatorIQN is non-empty <MAAS:Triaged by newell-jensen> <MAAS RSD :Triaged by newell-jensen> <https://launchpad.net/bugs/1685835>
<vasey> mpontillo: me again, since my hosts and MAAS are on the same subnet and can all ping each other, what do you think would cause my "could not find any datasource" error?
<xander> exit
<mpontillo> vasey: the first thing I always check is the MAAS URL; the MAAS region might report an IP address to the nodes that is off-subnet or otherwise unreachable.
<mpontillo> vasey: https://gist.github.com/mpontillo/6ee4c96d8aed4d0efde66a37aa6d5af9 << I wrote this last week to test things out, if you run it on the MAAS region it will connect to localhost and show you the default URLs presented to machines
<mpontillo> vasey: if you run it with a parameter, it will try to reach the MAAS server at that IP address/hostname.
<vasey> mpontillo: thanks! i'll give that a shot
<vasey> mpontillo: i'm getting a "(" unexpected error on line 5; doesn't look wrong to me though
<mpontillo> vasey: curl https://gist.githubusercontent.com/mpontillo/6ee4c96d8aed4d0efde66a37aa6d5af9/raw/dbc72aca7f6f056c773f4dad146547576e61c06b/test-maas-enlistment.sh > test-enlistment && chmod +x test-enlistment
<mpontillo> ^ that results in a working script for me
<mpontillo> xygnal: right, so I think I figured out where it goes to unmanaged; what I don't know is why. you might be able to force a traceback by modifying the code in that location, to get us more info
<mpontillo> xygnal: per https://bugs.launchpad.net/maas/+bug/1685306, if you were to edit /usr/lib/python3/dist-packages/maasserver/models/signals/interfaces.py and change the code (where it deletes all the links except DISCOVERED links) to do something like "raise ValueError()" on that line, that should provide a traceback that will at least tell us more about how we
<mpontillo> got into that situation
<vasey> mpontillo: for the "found metadata URL", it's pointing to an IP that i don't have set up; is that the trouble spot?
<vasey> mpontillo: the cloud-config-url is correct
<mpontillo> vasey: that's usually the problem. I would run "sudo dpkg-reconfigure -plow maas-rack-controller" and make sure the URL configured on the rack is the one that you want to communicate with from the deployed nodes
<mpontillo> vasey: the one subtle thing here is that MAAS may try to infer which URL to provide based on the source IP, so the most accurate way to run that script would be from a host on the same subnet as the MAAS rack
<vasey> mpontillo: so i ran the dpkg-reconfigure, then retested the enlistment, and the correct IP/URL shows up everywhere until right after END GRUB CONFIG. then it shows a different IP that i did not set, and which doesn't represent a real system in my network
<mpontillo> vasey: that's strange; what address is it showing?
<vasey> mpontillo: it's showing 192.168.0.201, when it should be 192.168.0.100
<roaksoax> 14:26 < vasey> mpontillo: for the "found metadata URL", it's pointing to an IP that i don't have set up; is that the trouble spot?
<mpontillo> vasey: can you pastebin the output for me? and the output of "sudo maas-rack support-dump --networking"? if it contains sensitive info you can email it to me or send me a PM to a secret gist on github
<roaksoax> mpontillo: ^^
<roaksoax> cloud-init tries to contact other stuff
<roaksoax> other ip addresses
<roaksoax> if it cannot contact the metadata
<roaksoax> that could be what's going on there
<mpontillo> roaksoax: yeah but this is MAAS itself reporting a weird URL per my diagnostic script
<mpontillo> roaksoax: I was thinking that too, just don't know why MAAS would report an incorrect IP at that point; that means it was found in the PXE config
<roaksoax> mpontillo: that could be the case if rackd.conf points to localhost for maas url
<mpontillo> roaksoax: yeah, that's why I said to check that first ;-)
<vasey> mpontillo: https://pastebin.com/hHL8UJ5g here's the script output first
<vasey> mpontillo: https://pastebin.com/a5z0KKRC and here's the networking output
<roaksoax> vasey: pastebin /etc/maas/rackd.conf
<mpontillo> vasey: I would check /etc/maas/regiond.conf and see if the .201 IP address is in there; if so, fix it and do "service maas-regiond restart"
<vasey> roaksoax: https://pastebin.com/CjdVBiPw
<mpontillo> vasey: is it possible that when MAAS was first set up the machine was using DHCP and had a different IP?
<vasey> mpontillo: that's the one! :)))
<roaksoax> vasey: restart maas-regiond && maas-rackd
<roaksoax> that will fix it
<vasey> mpontillo: and i think the system did originally have a DHCP-provided address, that makes a lot of sense
<mup> Bug #1685891 opened: [2.2] Allow pod syncing to fail for pre-existing or manual composed machines bad physical storage. <MAAS:In Progress by blake-rouse> <MAAS RSD :In Progress by blake-rouse> <https://launchpad.net/bugs/1685891>
<mup> Bug #1685904 opened: Remote Drive's CapacityGiB should be greater or equal to Master Drive's CapacityGiB <MAAS:Triaged by blake-rouse> <MAAS RSD :Triaged by blake-rouse> <https://launchpad.net/bugs/1685904>
<mup> Bug # changed: 1376483, 1381129, 1433012, 1533822, 1555759, 1616417, 1635061, 1657471, 1661203, 1671517, 1672220, 1672735, 1674148, 1675915, 1675919, 1676167, 1676882, 1676962, 1677336, 1677933, 1677936, 1678323, 1679431, 1680277, 1680278, 1680876, 1681378, 1681379, 1681383, 1681386, 1681387,
<mup> 1681389, 1681399, 1681757, 1681856, 1682099, 1682139, 1682152, 1682255, 1682290
<mup> Bug #1685952 opened: trusty with vlan reboot hang: ifup: waiting for lock on /run/network/ifstate.eth1 <MAAS:New> <https://launchpad.net/bugs/1685952>
<mup> Bug #1685955 opened: RSD nodes don't power off after commissioning <MAAS:Triaged by newell-jensen> <MAAS RSD :Triaged by newell-jensen> <https://launchpad.net/bugs/1685955>
#maas 2017-04-25
<mup> Bug #1685963 opened: [2.2] Django signal handlers are too opaque <MAAS:New> <https://launchpad.net/bugs/1685963>
<catbus1> Hi, seeing iscsistart: cannot make a connection to <MAAS IP>, and ipconfig: BOOTIF SIOCGIFINDEX: No such device prior, what might go wrong?
<mpontillo> catbus1: I would check that the machine you're booting will get an IP address that can reach MAAS first.
<catbus1> ack
<mpontillo> catbus1: I'd also run https://gist.github.com/mpontillo/6ee4c96d8aed4d0efde66a37aa6d5af9 from a machine on the subnet where the nodes are trying to boot, and validate that the URLs look correct
<mup> Bug #1686065 opened: [2.2.0rc2, UI, Machine details] The icons for error in Commissioning and Hardware tabs (secondary nav) are not up to date <ui> <ux-qa-2.2> <MAAS:New> <https://launchpad.net/bugs/1686065>
<mup> Bug #1686065 changed: [2.2.0rc2, UI, Machine details] The icons for error in Commissioning and Hardware tabs (secondary nav) are not up to date <ui> <ux-qa-2.2> <MAAS:New> <https://launchpad.net/bugs/1686065>
<mup> Bug #1686065 opened: [2.2.0rc2, UI, Machine details] The icons for error in Commissioning and Hardware tabs (secondary nav) are not up to date <ui> <ux-qa-2.2> <MAAS:New> <https://launchpad.net/bugs/1686065>
<jnielsen> hello, I was wondering if anyone knew how to delete a dns record from the dns tab on the maas webpage. I have some strange dns entries that look like ip addresses.
<jnielsen> using the cli, they are not listed in dnsresources, or dnsrecources-records
<jnielsen> also reading the domain (cli) the domain record count does not match what is shown on the maas webpage (cli:103, webpage:121)
<xygnal> mpontillo: does maas support vlans where the deployed system does not need tags? (native vlans)
<roaksoax> xygnal: it does, but they are modeled as "untagged" in a fabric
<mpontillo> xygnal: are those same VLANs tagged on the rack controller or untagged?
<mpontillo> xygnal: if they're on the rack controller you might hit https://bugs.launchpad.net/maas/+bug/1678339
<xygnal> would be tagged on controller, just not on nodes
<mpontillo> xygnal: okay, yeah, I have that setup at home, and have the bug referenced above, but MAAS otherwise does work
<xygnal> but rack controllers not in same L3
<mpontillo> xygnal: is this the DHCP relay config? yeah that should be fine
<mpontillo> xygnal: if MAAS doesn't know anything about the tags anywhere, it shouldn't get confused about it
<roaksoax> jnielsen: like which ones ? do you have any examples ?
<mup> Bug #1686169 opened: MAAS shows unsupported images but can't download them <MAAS:In Progress by ltrager> <https://launchpad.net/bugs/1686169>
<xygnal> xygnal this is the one that up to now, was just single-interface untagged but multiple fabrics.  even after going full separated fabrics and ensuring no leases are still there for that MAC anymore, it still fails as described before.  We are contemplating if this will not work and if we could switch to using VLAN tagging from MAAS server then.
<xygnal> mpontillo that would mean using tagging on the MAAS side, but not using tagging on the Node side, because the switch would be doing native vlan tagging for the node
<mpontillo> xygnal: from my perspective, it should work fine how you currently have it configured. I would like to get to the bottom of why the interfaces become unconfigured when you deploy. I've added some logging to regiond.log to attempt to determine that in https://bugs.launchpad.net/maas/+bug/1685963
<mpontillo> xygnal: rather, in https://code.launchpad.net/~mpontillo/maas/signal-handlers-add-logging--bug-1685963/+merge/323094
<xygnal> just now? let me see
<xygnal> oh
<jnielsen> roaksoax: in the maas domain it shows A records of the form name:###-###-###-### type:A Data: ###.###.###.###
<mpontillo> xygnal: it will be released in the next release... I'm trying to figure out how it's possible for the interfaces to become unconfigured in that way
<xygnal> mpontillo we have deployments coming up in about 3 weeks so we're growing quite concerned about getting to the bottom of it.   Can this logging code by implemented in our current installed version?
<mpontillo> xygnal: it seems to me that it /might/ happen if the VLAN the interface is on changes. so I'm wondering: if you repeat the deployment, does it always happen again? or does it "settle"?
<xygnal> remember we had some problems with RC2
<xygnal> mpontillo happens every time.
<xygnal> every single deploy fails the same
<mpontillo> xygnal: yeah, the bugs you encountered with RC2 should be fixed. okay. would it be possible for you to send me some more detailed information about your setup, so I can try to create a reproducible test case?
<xygnal> I verified no observed IP and no living leases for the box from last deploy attempt (the day before)
<xygnal> can you outline what details you want?  THe person who knows that in and out is not me, and I need to make sure they are not missing any details you want to have
<xygnal> mpontillo: I asked him to get started on that.  I'll pass along any specific data you ask for here to make sure
<mpontillo> xygnal: I would like to see the output of:
<mpontillo> sudo maas-region dbshell
<mpontillo> \pset pager off
<mpontillo> select * from maas_support__node_networking;
<mpontillo> xygnal: if it contains sensitive info, you can sanitize it or just email it to me
<mpontillo> xygnal: or send me a private message to a private pastebin URL such as a secret github gist
<mup> Bug #1686171 opened: NTP and stress-ng tests fail on Trusty <MAAS:Triaged by ltrager> <https://launchpad.net/bugs/1686171>
<xygnal> mpontillo is that enough to show you our networking config, or do you need any further diagrams outside of it?
<mpontillo> xygnal: I have what you've posted in the other bugs, so the output of that query would be a good start
<mpontillo> xygnal: I was looking for another query that might be useful, too
<mpontillo> xygnal: the output of this query will also help me get a feel for how your networks are modeled in MAAS http://paste.ubuntu.com/24455722/
<roaksoax> jnielsen: you mean, ip address based ?
<mpontillo> xygnal: I forgot to ask, are you using any HA features, such as multiple rack controllers?
<mpontillo> xygnal: or, might the networks appear (to MAAS) to be on different VLANs depending on which region or rack controller they are viewed from?
<mpontillo> jnielsen: A records may be automatically generated for deployed nodes in MAAS; does that account for the difference?
<xygnal> mpontillo we are using multiple rack controllers, yes.
<xygnal> mpontillo only two rack controllers in this environment.  one by itself and one on the same machine as the region controller.
<jnielsen> roaksoax: yea the names are based off the ip
<jnielsen> mpontillo: these records look stale.
<xygnal> mpontillo:  two new sanitized attachments on the bug 1685306
<mpontillo> xygnal: I'm now wondering if it's possible that the network configuration is re-detected on each rack controller independently, and causes changes to ripple through the system and ultimately remove the configuration on those interfaces
<xygnal> mpontillo shou;d
<xygnal> shouldn't HA be aware of this and avoid it?
<xygnal> or is HA a largely untested feature in this situation?
<roaksoax> jnielsen: whta evrsion of MAAs are you using ? And those are the addresses that MAAS auto-generates for machines in the dynamic range
<jnielsen> mpontillo: let me verify the difference to see if they are (stale) and not duplicates, and see if they match the difference
<mpontillo> xygnal: well, it's certainly a bug. I wouldn't say it's untested; we often test HA. but this may be an edge case that was missed
<jnielsen> roaksoax: 2.1
<mpontillo> xygnal: can you try an experiment for me? shut down the rack controller you're not using on the region controller. just stop the service. and then see if the bug still occurs
<xygnal> mpontillo hm.  its supposed to be rackd on one and region on the other.  according to services,  rackd, http, tftp are running.  but dhcpd is not.
<roaksoax> xygnal: in a HA mode, the secondary rack wont be running DHCP
<roaksoax> xygnal: until the primary dies
<xygnal> roaksoax: mpontillo: then would I be affected as suspected, or would that not happen?
<mpontillo> xygnal: in other words, it sounds like you're not using one of your rack controllers for DHCP, so shutting it down shouldn't hurt anything
<xygnal> mpontillo the 'backup' rack controller is on the region controller.  shall I just stop the rackd service?
<mpontillo> xygnal: yeah, just stop it and see if it makes anything better. that way we can characterize if this is a bug with HA or not
<mpontillo> xygnal: maybe just shut down the secondary, that way you can keep everything on one machine and see if that helps -- reduce the number of variables we're dealing with here.
<xygnal> mpontillo thats the plan
<jnielsen> mpontillo: I did not verify all of them, but they seem to be stale (not duplicates) and they make up the difference between what maas <user> domain read <domain> is reporting for records
<jnielsen> and what the webpage shows
<jnielsen> i have to run to a meeting real quick, I'll be back in a hour or so. I'll leave this open
<mpontillo> jnielsen: sure, I'd like to understand more what "stale" means. do you have enough information to file a bug for us?
<jnielsen> mpontillo: stale means I don't have a machine using that ip
<jnielsen> 'll investigate more
<mpontillo> jnielsen: so possibly DHCP addresses that expired but were not deleted? that might be a known (and/or fixed) bug. let me check
<roaksoax> jnielsen: try this
<roaksoax> jnielsen: sudo maas-region shell
<roaksoax> from maaserver.models import DNSResource
<roaksoax> DNSResources.objects.all()
<roaksoax> jnielsen: and I think they come from this:
<roaksoax> $GENERATE 190-253 $.90.90.10.in-addr.arpa. IN PTR 10-90-90-$.maas
<roaksoax> or similar, actually
<mpontillo> jnielsen: is there something special about xxxmaaskhost021?
<xygnal> was that for me?
<mpontillo> xygnal: ah, yes, sorry jnielsen. it seemed a little strange to me that it has an interface on both xx.xx.97.0/24 and xx.xx.186.0/23
<xygnal> mpontillo that is a special host being used for something else right now, we have not been testing on it recently.  would it be affecting other builds?
<mpontillo> xygnal: can you try removing those from the environment and see if that impacts the issue? my concern is that it looks like there are IP addresses from two different fabrics on those machines, which may be contributing to the VLAN flip/flop effect and causing the IP addresses to become unconfigured
<mpontillo> xygnal: maybe give it a try after you rule out HA?
<mpontillo> xygnal: just to confirm, have you tried recommissioning the machines before deploying, too?
<xygnal> mpontillo: we've removed and re-comissioned them before deploying, yes
<xygnal> xygnal in fact all of the -DEMO nodes I am certainn of this
<mpontillo> xygnal: ok great.. looking forward to hearing if taking HA out of the picture makes a difference
<xygnal> mpontillo is it just that one node, or all of the nodes named like that, that need to br removed?
<xygnal> (that have the dual-networks)
<mpontillo> xygnal: I'd just remove them all from MAAS for good measure
<mpontillo> xygnal: when it comes time to test that
<mpontillo> xygnal: let's try to rule out one thing at a time =)
<xygnal> mpontillo i'm testing the no-HA right now, just planning for after
<mpontillo> xygnal: great. right now I'm more suspicious of controllers, since they constantly update the region about their network configuration, which might lead to flip/flops if the two controllers don't agree on what the network looks like. then every 30 seconds to one minute you might see VLAN changes that could cause IP addresses to be cleared
<xygnal> mpontillo should I rewmove all of the nodes or just those xxxmaask ones?  Being that the other ones have been completely removed and added since re-fabricing
<xygnal> mpontillo just trying to avoid making the while dev environment unavailable to my colleages by removing all the hosts
<xygnal> whole*
<mpontillo> xygnal: I was only suspicious about the xxxmaask ones for now, but honestly I doubt it will change anything, especially if those nodes are just sitting there
<xygnal> yes, they are
<mpontillo> xygnal: honestly I doubt they are the issue; let's focus on anything running the controller software for now
<mpontillo> xygnal: I assumed that was xxxmaas0{1,2}
<vasey> hey folks, i'm tryna diagnose this issue when I try to use juju to bootstrap a MAAS controller: https://pastebin.com/Pd8ktgPm
<mpontillo> vasey: are you using any IPv6 in your environment? is juju configured to talk to MAAS by means of an IP address or DNS name? if DNS, what does it resolve to?
<mpontillo> vasey: in case it helps, here are my notes on testing MAAS with Juju the last time I did it https://gist.github.com/mpontillo/231790806c51cf07e51cbe30e8e0b0a1
<vasey> mpontillo: one thing i did was run 'sudo lxd init' before starting up; i now have an lxd bridge interface that i believe my juju is running from, and it's definitely not in the same subnet as my MAAS setup. how would i revert that operation?
<vasey> mpontillo: and to answer your questions, i don't believe i have ipv6 configured anywhere, how would i verify for MAAS? and juju is configured to talk to MAAS via IP address, not dns name
<mpontillo> vasey: the lxd bridge shouldn't affect things, but your containers' default profile would most likely be using the bridge, with NAT
<mpontillo> vasey: come to think of it, that error is most likely occurring when Juju selects a MAAS node to use as the juju controller, and attempts to allocate and deploy it. check your nodes' network configuration to ensure they have automatic IP addresses on the subnet(s) you expect
<jnielsen> mpontillo: interestingly the entries with the ip-like name have a live machine associated with them (not on my list)
<mup> Bug #1686195 opened: [2.2] MAAS should include a script to test enlistment <MAAS:Triaged by mpontillo> <https://launchpad.net/bugs/1686195>
<jnielsen> mpontillo: I'll investigate this further, thanks for the help! you too roaksoax:
<mpontillo> jnielsen: right, my guess is that they were created by DHCP leases and and safe to delete. I believe there is a bug where we do not delete them when the lease expires. I don't see a fix on the 2.1 branch
<vasey> mpontillo: that did the trick, none of my nodes had interfaces with auto-assign IPs added. is it possible to have juju run on a node that will be part of an openstack distro or is that just a terrible idea?
<jnielsen> mpontillo: do you know how to delete them?
<vasey> mpontillo: openstack deployment***
<mpontillo> jnielsen: you can delete them using the command-line interface. probably something like: "maas $PROFILE dnsresource delete <id>".
<mpontillo> jnielsen: but no guarantees because I didn't test that command =)
<mpontillo> vasey: I think juju was designed that way for separation of concerns; if something takes down your deployment, you don't want that to affect juju itself
<mpontillo> vasey: what I have seen many customers do is use a constraint in juju to select a specific machine in MAAS; you could, for example, use the virsh support to make your juju select a manually-configured VM on the MAAS server to be the controller
<jnielsen> mpontillo: they don't show up in my dnsresource list with maas <user> dnsresources read
<vasey> mpontillo: ahhhh that makes sense
<mpontillo> jnielsen: ah, I must have misunderstood; I thought you were saying they showed up in dnsresources read but not on the DNS page; it's the opposite, then?
<mpontillo> jnielsen: hmm, on my MAAS I see DHCP-provided hostnames if I do something like this: maas $PROFILE dnsresources read | jq -c '.[] | {fqdn:.fqdn, id:.id}'
<mpontillo> jnielsen: and I see things in the DNS details page for that domain which belong to my deployed nodes (they appear with a hyperlink so I can click them and go to the node)
<mpontillo> jnielsen: but I don't see anything that isn't a node that doesn't appear in the domain details
<mpontillo> jnielsen: I guess it would help if you can pastebin: dig @127.0.0.1 -t axfr <domain>
<mpontillo> jnielsen: and the dnsresources read with the jq above
<xygnal> mpontillo:  no luck . I even deleted the node I am building entirely and re-added.  Comission worked fine, deploy fails the same.
<xygnal> mpontillo and yes, i removed the khost nodes before even doing that
<vasey> mpontillo: if i'm using an ESXi-managed VM, how do i use virsh  as power control?
<vasey> mpontillo: if i use the VMware power options, using the UUID,  host IP, username and pass, i get this error: "No rack controllers can access the BMC of node: fluent-minnow"
<vasey> despite my host being able to ping that host. do i need to enable ssh in ESXi, now that i think about it?
<xygnal> mpontillo:  updated bug report with two sanitized copies of the logs from that time period today
<mpontillo> vasey: you need to install a python package called pyvmomi to talk to the ESXi API; probably KVM is more well-tested since few people have VMware licenses handy to test with
<mpontillo> vasey: should be available as an apt package, python3-pyvmomi I think -- but there are a few issues with it, certificate checking has been a problem in the past
<mpontillo> vasey: if you get an error that no rack controllers can access the BMC, you might need to refresh the power status to see if MAAS can determine which racks can reach it
<mpontillo> xygnal: OK, so without the HA rack enabled and without those dual-network nodes, you still have the problem? just to confirm, can you try a second deploy with one of the machines and tell me if it's any different? (that's weird.) I'll have to give this some more thought. please upgrade to the next rc build when it comes out; I've added some additional
<mpontillo> logging that may help, too
<xygnal> mpontillo: eta on Rc3?
<roaksoax> xygnal: ppa:maas/next-proposed has the proposed version of rc3
<mup> Bug #1686234 opened: [2.2] MAAS does not delete DNS records for released DHCP leases <MAAS:Triaged by mpontillo> <https://launchpad.net/bugs/1686234>
#maas 2017-04-26
<mup> Bug #1686244 opened: [web UI] Storage modification message is confusing <docteam> <MAAS:New> <https://launchpad.net/bugs/1686244>
<mup> Bug #1686246 opened: [CLI help] set-storage-layout says Allocated when it should say Ready <docteam> <MAAS:New> <https://launchpad.net/bugs/1686246>
<mup> Bug #1686248 opened: Node configuration user collisions are possible <docteam> <MAAS:New> <https://launchpad.net/bugs/1686248>
<mup> Bug #1686412 opened: Add ability to change PXE boot behavior of a device <MAAS:Triaged> <https://launchpad.net/bugs/1686412>
<vasey> mpontillo: i installed python3-pyvmomi, and i'm getting this message when i try to connect : "Error:__init__() takes 1 positional argument but 2 were given"
<vasey> as well as a "power error" message when i try to check the power state
<vasey> mpontillo: and now i'm seeing that certificate error in my events log for that node: https://pastebin.com/eYzdxecn
<xygnal> mpontillo:  I see a code merge for our problem.  is that still being tested?  its quite small so tempted to apply it to ours and see if we can verify the results
<roaksoax> xygnal:  i just uploaded to a ppa, if you wanna test from there ?
<roaksoax> xygnal: but if you give us some time to test that'd be good
<xygnal> roaksoax what kind of time are you looking for to incorporate this into RC3 and release it?  We have about 3 weeks time before we need to be ready for prod deployments and we want to be sure this is wrapped up.
<roaksoax> xygnal: it is already in RC3 milestone
<roaksoax> just need to test it first
<roaksoax> before I can say there's no regressions
<xygnal> roaksoax what is the *goal* date for RC3 release?
<xygnal> what are you aiming for
<roaksoax> xygnal: we are targetting a release for the end of the week. It may be final or it may be rc3
<xygnal> roaksoax thanks much.
<mup> Bug #1623851 changed: Tables not responsive for mobile <ui> <MAAS:Fix Released> <https://launchpad.net/bugs/1623851>
<mup> Bug #1686464 opened: [2.2, API] set-storage-layout fails silently when invoked by a non-admin <api> <api-ux> <docteam> <MAAS:Triaged> <https://launchpad.net/bugs/1686464>
<mpontillo> xygnal: I think patching your setup with the diff from that merge proposal would be a low-risk thing to do. please do give it a try.
<xygnal> mpontillo: thanks, will test it out this week.
<mup> Bug #1686485 opened: cc_ntp fails to work when deploying ubuntu-core <cloud-init:New> <MAAS:Triaged> <https://launchpad.net/bugs/1686485>
<mary_> hello I have a problem with maas, for some reason, the rack controller fails
<mary_> theyre both on the same machine
<mary_> can anyone help me
<catbus1> mary_: first post the error message please
<mary_> there's no error message just a red cross on the gui in front of the rack controller
<roaksoax> mary_: go to the rack controller, and see the status of it
<roaksoax> does it show why it is red ?
<mary_> on the images status it says region importing and on the boot images status tab it says out of sync
<mary_> I dont get it, I did configure the url
<mary_> and I did the same steps I did before but last time, it worked
<mup> Bug #1686516 opened: [2.2, trunk] Pod remote storage listing shows blank for pods with out remote storage <MAAS:In Progress by blake-rouse> <https://launchpad.net/bugs/1686516>
<xygnal> mpontillo: that works, final address is correct
<xygnal> mpontillo new problem.  observed address does not go away, so system keeps booting old temporary address,
<xygnal> will that fix itself when temporary lease expires?
<xygnal> hm...
<mup> Bug #1646847 changed: Multi interface issue while charm deployed on centos image <cloud-images:New> <juju:Invalid> <MAAS:Won't Fix> <https://launchpad.net/bugs/1646847>
<mup> Bug #1658718 changed: MAAS 2.1.3 Centos 7 image deployment fails <MAAS:Triaged by ltrager> <https://launchpad.net/bugs/1658718>
<roaksoax> xygnal: is the machine set as 'dynamic' or is it set as 'auto assign' ?
<roaksoax> xygnal: and what do you mean by keeps booting ?
<xygnal> ah, sorry bad phrasing.  DHCP-aquires the old dynamic range address
<xygnal> if you look in that subnets view, you can see that same node has an observed address and automatic address
<xygnal> observed is the dynamic
<roaksoax> xygnal: that will clear itself automatically
<xygnal> yes but wasnt that 2 hours?
<xygnal> for the default expire
<roaksoax> xygnal: the dynamic range expires 10 minutes
<xygnal> oh wow ok, understood
<roaksoax> xygnal: what may be failing is dhcp tells maas about a lease expiring
<roaksoax> and maas removes that from tracking
<roaksoax> xygnal: but has the deployed machine been successfully configuired ?
<xygnal> roaksoax maas has correct config, but node boots up with build IP instead of its assigned IP.
<xygnal> shutting them down for 10 minutes, power off
<xygnal> to verify that clears
<roaksoax> xygnal: if e/n/i is configured w/ static IP address, how will it boot from an address it gets from dhcp ?
<xygnal> I suspect the pre-existing lease is not given a chance to expire
<xygnal> auto-assign
<xygnal> your auto-assign is static dhcp, if I recall correctly
<roaksoax> xygnal: auto-assign will configure /etc/network/interfaces with 'iface X inet static'
<roaksoax> dhcp will configure /e/n/i w/ 'iface X inet dhcp'
<xygnal> then its NOT compatibe with a custom image, which I could have sworn mpontillo steered me the other way pon
<roaksoax> xygnal: is this an Ubuntu custom image?
<xygnal> CentOS only for us
<xygnal> cloud-init enabled image
<roaksoax> ah right
<roaksoax> so MAAS doesn't yet support network config for centos images
<roaksoax> but it will do soon
<xygnal> alright I thought that before, but somehow got a mixed message
<roaksoax> that said
<roaksoax> MAAS adds a hostmap
<xygnal> then we go back to my plan before that
<xygnal> which was using DHCP but changing the IP after deploy (Via post-script) to a reserved range address
<roaksoax> xygnal: so if eth0 - auto-assign, MAAS will add a hostmap for eth0's MAC + IP assigned by MAAS
<roaksoax> xygnal: but, unless isc-dhcp is ignoring the hostmap
<xygnal> hm... what will this hostmap result in?
<roaksoax> xygnal: the hostmap should result in the machine obtaining the IP as per 'auto-assign' and not form dynamic range
<roaksoax> xygnal: if you do dhclient on your system for eth0... does it get the right IP ?
<xygnal> roaksoax: no, it gets the dynamic/observed ip
<xygnal> roaksoax but in the UI it has an auto-assigned address in the proper range for auto-assign
<xygnal> roaksoax: if that is not supported, why does it pick an auto assign?
<wasosa> Hi all. I'm looking for some help deploying a node with maas (just upgraded to 2.1.5+bzr5596-0ubuntu1~16). Though the web UI tells me the node is 'Ready', it also warns me: No storage information. Commissioning this node will gather the storage information.
<xygnal> I would expect to be told NO
<roaksoax> xygnal: check your isc-dhcp config
<roaksoax> xygnal: you should see the hostmap there
<roaksoax> xygnal: /var/lib/maas/dhcpd.conf
<roaksoax> xygnal: my guess is that isc dhcp is preferring the address from the dynamic range rather than tha hostmap address
<roaksoax> xygnal: what if you clean your leases file ?
<roaksoax> xygnal: try cleaning the leases file, then force the interface to re-obtain an IP from isc-dhcp and see if it gets the right address ?
<xygnal> roaksoax yes
<xygnal> there is a host map
<xygnal> I powered the nodes down in the hope that the 10 minute lease woud expire
<xygnal> if a lease is already alive, a new hostmap wont matter will it?  or should the old lease be overridden?
<xygnal> confirmed observed lease is gone
<xygnal> powered back up
<wasosa> Hi all. I'm looking for some help deploying a node with maas (just upgraded to 2.1.5+bzr5596-0ubuntu1~16). The web UI tells me the node is 'Ready', but warns me: No storage information. Commissioning this node will gather the storage information. As best as I can tell, the block-device output is good. The only hits I found with similar problems had to do with vms rather than real hardware (I'm attempting to deploy an Intel SkullCanyon 
<wasosa> I'd appreciate any help anyone can provide. Thanks!
<roaksoax> xygnal: did it get new IP ?
<roaksoax> wasosa: that means that no storage was discovered during commissioning
<roaksoax> wasosa: do you have any specific storage in this machine?
<xygnal> roaksoax I seem to be a little confused, i was testing two boxes.   Back just one now.  I dont seem to have a hostmap in dhcpd despite deploying as auto-assign
<xygnal> there is a hostmap in there for another build that *I* did not build, i am checking to see if that one was different somehow
<wasosa> roaksoax: Yes, the machine has one nvme drive, and it looks like that's showing up properly in the 00-maas-07-block-devices.out listed under 'Machine output'
<wasosa> roaksoax: (thanks for jumping in, btw)
<roaksoax> wasosa: are you commissioning with Xenial? go to the settings page, to the commissioning section, and select xenial for commissioning
<wasosa> roaksoax: yes I am, that secion reads: Default Ubuntu release used for commissioning: Ubuntu 16.04 LTS "Xenial Xersus" (and I can't change it).
<wasosa> roaksoax: the output of the block devices caputred during commissioning looks sane to me, but I haven't been able to find the problem yet. I can share that output here if you'd like.
<xygnal> roaksoax: think i found the problem.  its pxe booting them.  not sure why its responding to taht, as they  are 'deployed' status.
<mpontillo> xygnal: currently MAAS will always respond to a PXE boot, but if the machine is deployed the PXE boot payload will instruct the node to boot from its local disk
<xygnal> mpontillo: I will verify that behavior, ty
<mpontillo> xygnal: when the node PXE boots it should receive the IP address assigned via the static lease installed by auto-assignment
<xygnal> mpontillo: that it does not, bit the implied host map in dhcpd.conf is not there either
<xygnal> despite that, its in deployed status
<xygnal> and has an Assigned up
<xygnal> IP*
<xygnal> yes i just booted local HD
<xygnal> same result
<xygnal> there is no hostmap so there is no static entry
<xygnal> i do see one that was build yesterday pre-fix that now suddenly has correct addrwess
<xygnal> and is working
<xygnal> we are slowing down for the day so, we'll do some more exhaustive testing on this and report back tomorrow.  thanks for the help.
<mpontillo> xygnal: thanks; I'd investigate if the DHCP configuration is not being properly updated when the IP address is assigned, then. thanks for your testing!
#maas 2017-04-27
<roaksoax> xygnal: if they are deployed, and the machine is manually configured to pxe boot by default, the machine will PXE boot and will be told to oot from local disk
<roaksoax> xygnal: that sad, the machine should still be dhcp'ing from the hostmap
<roaksoax> xygnal: as mpontillo explained...
<xygnal> roaksoax the problem appears to be that the host map is not being created
<xygnal> i've just re-comissioned two machines and tried them with auto-assign, still doing this.  going to delete from MAAS all together next.
<roaksoax> xygnal: are there any error logs ? (tail -f /var/log/maas/*.log)
<roaksoax> xygnal: can you 'deploy' a machine, while tailing /var/log/maas/*.log
<roaksoax> xygnal: and share that
<roaksoax> xygnal: also share the output of /var/lib/maas/dhcpd.conf after the machine has been deployed
<roaksoax> err
<roaksoax> after you click deploy and the logs show that the deployment has started
<roaksoax> you will see something like: Apr 27 01:57:27 xenial-maas22 maas.interface: [info] Allocated automatic IP address 192.168.10.109 for eno1 (physical) on apt-heron.
<xygnal> yes i always see that
<xygnal> never throws an error either
<xygnal> and in the UI it shows the auto-asssignend IP
<xygnal> just dhcpd.conf which is missing the hostmap
<xygnal> there is only one such angry in there now for a node, and it is for a node i did not build.   all of the nodes I have tried to build (with identical config) dont end up with a hostmap
<xygnal> it's as if the DHCP sync is not happeningning
<roaksoax> xygnal: can you please share your config?
<roaksoax> dhcpd.conf that is
<xygnal> roaksoax: after moving my dhcpd.conf to a backup and restarting maas-rackd and maas-dhcpd, a new config has written, and it has the missing host mapping.
<xygnal> roaksoax: and after that, it just booted up with its assigned IP address.
<xygnal> (thumbsup)
<xygnal> confirmed on a couple more - all green
<xygnal> updated the bug report
<mup> Bug #1686607 opened: maas gui doesn't show bond details nor allow editing <MAAS:New> <https://launchpad.net/bugs/1686607>
<mup> Bug #1686607 changed: maas gui doesn't show bond details nor allow editing <MAAS:New> <https://launchpad.net/bugs/1686607>
<mup> Bug #1686669 opened: MAAS fails to deploy Ubuntu on host that had CentOS deployed and vice-versa <MAAS:New> <https://launchpad.net/bugs/1686669>
<mup> Bug #1686678 opened: No obvious way to change the domain of a controller <MAAS:New> <https://launchpad.net/bugs/1686678>
<mup> Bug #1616231 changed: Can't select partition table (MBR vs GPT) <MAAS:Fix Released> <MAAS trunk:Fix Released> <https://launchpad.net/bugs/1616231>
<mup> Bug #1616231 opened: Can't select partition table (MBR vs GPT) <MAAS:Fix Released> <MAAS trunk:Fix Released> <https://launchpad.net/bugs/1616231>
<mup> Bug #1616231 changed: Can't select partition table (MBR vs GPT) <MAAS:Fix Released> <MAAS trunk:Fix Released> <https://launchpad.net/bugs/1616231>
<David_Orange> Hi, can someone can provide me some information about "node-results" cli sub command ? i woud like to have the commisioning summary, but i can not find how to filter it from all the output (i can not find anything on that subcommand under maas doc)
<roaksoax> David_Orange: maas admin node-results read system_id=qctf8r name=00-maas-01-lshw
<roaksoax> that's an example
<roaksoax> obtaining the 00-maas-01-lshw file for the system qctf8r
<roaksoax> David_Orange: http://pastebin.ubuntu.com/24466683/ -> all the commissioning scripts/test scripts (this is maas 2.2)
<David_Orange> roaksoax: Ok, got it, it is files from "commisioning output", i was searching in summary. Thanks a lot
<roaksoax> David_Orange: cool, note that the 'data' field has the data in base64
<roaksoax> David_Orange: and the summary is just a nice way to show the output from the lshw script + the lldp output one
<David_Orange> roaksoax: ok, got it, thx
<mup> Bug #1686732 opened: [2.2] Cannot release a DISCOVERED IP address <MAAS:Triaged> <https://launchpad.net/bugs/1686732>
<mup> Bug #1686732 changed: [2.2] Cannot release a DISCOVERED IP address <MAAS:Triaged> <https://launchpad.net/bugs/1686732>
<mup> Bug #1686732 opened: [2.2] Cannot release a DISCOVERED IP address <MAAS:Triaged> <https://launchpad.net/bugs/1686732>
<mup> Bug #1686736 opened: [2.2] DISCOVERED IP addresses should never exist outside of the dynamic range <MAAS:Triaged> <https://launchpad.net/bugs/1686736>
<mup> Bug #1686736 changed: [2.2] DISCOVERED IP addresses should never exist outside of the dynamic range <MAAS:Triaged> <https://launchpad.net/bugs/1686736>
<xygnal> roaksoax:  hm.  this dhcpd.conf not updating strangeness is happening again.  had to remove dhcpd.conf, and restart maas-rackd to re-write it.
<xygnal> roaksoax: a simple diff between the old and new file shows the missing host maps again
<xygnal> roaksoax how does maas update dhcpd.conf? does it use API commands to add and remove things, or does it just re-write the config and HUP?
<roaksoax> xygnal: rewrites the whole config? are you still using multiople rack controllers ?
<roaksoax> xygnal: and in relay ?
<roaksoax> xygnal: i've been playing around (without relay or HA), and hostmaps get created just fine
<xygnal> roaksoax:  i turned the HA secondary back on, but that side is not running DHCPd
<xygnal> roaksoax:  it never was
<mup> Bug #1686736 opened: [2.2] DISCOVERED IP addresses should never exist outside of the dynamic range <MAAS:Triaged> <https://launchpad.net/bugs/1686736>
<xygnal> roaksoax still doing the same thing as before yes.
<roaksoax> blake_r: ^^ why would maas not create the hostmaps
<xygnal> it does if i remove dhcpd.conf and restart maas-rackd
<roaksoax> blake_r: he is using dhcp relay
<xygnal> but not before
<roaksoax> xygnal: right, so rackd is nto writing the hostmaps for some reason
<roaksoax> xygnal: so if you removed dhcpd.conf, restarted maas-rackd, and deploy new machines, hostmaps are created just fine ?
<blake_r> xygnal: is it not writing hostmaps for the relayed vlan?
<blake_r> xygnal: but it writes hostmaps for the main vlan?
<xygnal> not exactly.
<xygnal> everything i deployed is missing hostmaps
<xygnal> if i delete the conf and restart
<xygnal> the new conf has those hostmaps
<xygnal> but any new deploys after that are missinh
<xygnal> until i repeat the delete and restart
<blake_r> xygnal: okay let me test on my side without dhcp relay, and see if i am getting hostmaps one moment
<xygnal> blake_r i've not tried to write maps for the local network, as there are no servers in that.  All of our deploying nodes are in relayed fabrics, as that is what the prod arch will be.
<blake_r> xygnal: yeah I would bet that is the issue
<blake_r> xygnal: I am going to verify the local, and then I will file a bug, and get you a fix
<blake_r> xygnal: yep that is the issue
<xygnal> blake_r: ty sir
<blake_r> xygnal: thanks for testing DHCP relay!
<xygnal> blake_r: two way street,  your quick help makes a big difference
<blake_r> xygnal: https://bugs.launchpad.net/maas/+bug/1686755
<mup> Bug #1686755 opened: [2.2] Relay'd VLAN's hostmaps are not writtin to the dhcpd.conf, unless rackd is restarted <MAAS:In Progress by blake-rouse> <https://launchpad.net/bugs/1686755>
<mup> Bug #1686757 opened: [2.2] Rack registration fails if machine has domain in hostname <MAAS:Triaged by danilo> <https://launchpad.net/bugs/1686757>
<mup> Bug #1686757 changed: [2.2] Rack registration fails if machine has domain in hostname <MAAS:Triaged by danilo> <https://launchpad.net/bugs/1686757>
<mup> Bug #1686757 opened: [2.2] Rack registration fails if machine has domain in hostname <MAAS:Triaged by danilo> <https://launchpad.net/bugs/1686757>
<mup> Bug #1686763 opened: MAAS blanks out search query <ui> <MAAS:Confirmed> <https://launchpad.net/bugs/1686763>
<mup> Bug #1686763 changed: MAAS blanks out search query <ui> <MAAS:Confirmed> <https://launchpad.net/bugs/1686763>
<mup> Bug #1686763 opened: [2.2, UI] MAAS blanks out search query <fff> <ui> <MAAS:Confirmed> <https://launchpad.net/bugs/1686763>
<mup> Bug # changed: 1377335, 1393936, 1654063, 1672327, 1672363, 1677056, 1680086, 1680886, 1680979, 1681390, 1681407, 1681442, 1681745, 1681869, 1681937, 1682174, 1682663, 1683433, 1683440, 1683448, 1683502, 1683503, 1683542, 1683855, 1684074, 1684305, 1685306, 1685361, 1685410, 1685435, 1685624,
<mup> 1685835, 1685891, 1685904, 1685955, 1685963, 1686516
<mup> Bug #1639332 changed: [2.2] Expire the DHCP lease after commissioning or make the  default-lease-time configurable <sts> <trivial> <MAAS:Won't Fix by andreserl> <https://launchpad.net/bugs/1639332>
<mup> Bug #1683919 changed: NVMe disk with trusty and hwe-t kernel fails installation <kernel-da-key> <trusty> <MAAS:Won't Fix> <https://launchpad.net/bugs/1683919>
<mup> Bug #1639332 opened: [2.2] Expire the DHCP lease after commissioning or make the  default-lease-time configurable <sts> <trivial> <MAAS:Won't Fix by andreserl> <https://launchpad.net/bugs/1639332>
<mup> Bug #1683919 opened: NVMe disk with trusty and hwe-t kernel fails installation <kernel-da-key> <trusty> <MAAS:Won't Fix> <https://launchpad.net/bugs/1683919>
<mup> Bug #1639332 changed: [2.2] Expire the DHCP lease after commissioning or make the  default-lease-time configurable <sts> <trivial> <MAAS:Won't Fix by andreserl> <https://launchpad.net/bugs/1639332>
<mup> Bug #1683919 changed: NVMe disk with trusty and hwe-t kernel fails installation <kernel-da-key> <trusty> <MAAS:Won't Fix> <https://launchpad.net/bugs/1683919>
<mup> Bug #1686794 opened: Cancel button broken on add user page <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1686794>
<mup> Bug #1624344 opened: [2.1] Can't SSH to machine in Rescue mode <MAAS:Invalid> <https://launchpad.net/bugs/1624344>
<mup> Bug #1624344 changed: [2.1] Can't SSH to machine in Rescue mode <MAAS:Invalid> <https://launchpad.net/bugs/1624344>
#maas 2017-04-28
<mup> Bug #1686864 opened: [2.2] Cannot view implicitly-created DNS records using the API <MAAS:Triaged by mpontillo> <https://launchpad.net/bugs/1686864>
<wililupy> I have MAAS 1.9 installed, and I am doing some testing where I have to take the DHCP lease down to 60 seconds. How do I do this with MAAS 1.9?
<mup> Bug #1687076 opened: Failed allocate: assert self.owner is None or self.owner == user <MAAS:New> <https://launchpad.net/bugs/1687076>
<mup> Bug #1687076 changed: Failed allocate: assert self.owner is None or self.owner == user <MAAS:New> <https://launchpad.net/bugs/1687076>
<mup> Bug #1687076 opened: Failed allocate: assert self.owner is None or self.owner == user <MAAS:New> <https://launchpad.net/bugs/1687076>
<mup> Bug #1687092 opened: Unable to deploy a node in MAAS 2.1.3 in Ubuntu 16.04 <MAAS:Incomplete> <https://launchpad.net/bugs/1687092>
#maas 2017-04-29
<chatter29> hey guys
<chatter29> allah is doing
<chatter29> sun is not doing allah is doing
<chatter29> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
#maas 2017-04-30
<mup> Bug #1687305 opened: maas reports an incorrect amount of available storage space for a virsh pod <MAAS:New> <https://launchpad.net/bugs/1687305>
#maas 2018-04-23
<Couaque> Hello !
<mup> Bug #1766209 opened: set -e & debconf are not safe together <subiquity> <maas (Ubuntu):New> <https://launchpad.net/bugs/1766209>
<mup> Bug #1766211 opened: cannot force not installing dbconfig managed postgresql <subiquity> <maas (Ubuntu):New> <https://launchpad.net/bugs/1766211>
<mup> Bug #1766214 opened: shared-secret should not be asked about in postinst <subiquity> <maas (Ubuntu):New> <https://launchpad.net/bugs/1766214>
<mup> Bug #1766218 opened: invoke.rc-d --force should not be used <subiquity> <maas (Ubuntu):New> <https://launchpad.net/bugs/1766218>
<mup> Bug #1766241 opened: default url / ip based url / admin user not setup on reconfigure <subiquity> <maas (Ubuntu):New> <https://launchpad.net/bugs/1766241>
<mup> Bug #1766259 opened: [2.4, UI, regression] Machine listing page table columns are not correct <MAAS:New> <https://launchpad.net/bugs/1766259>
<Hey> roaksoax: what logs do I look at to see why a deployment failed?
<Hey> regarding adding a maas windows image, the name field refers to the name of the file?  and the content@ refers to the location of the directory where the
<Hey>              file resides?
<roaksoax> Hey: content@=/path/to/your/image
<roaksoax> Hey: name=windows/your-windows-image-name title="Pretty name"
<Hey> roaksoax: your-windows-image-name like name of the file, or name of the windows version?
<Hey> forgive the question.
<Hey> so.. it could look like content@=/home/user/win10.tar.gz   and name=windows/win10.tar.gz ?
<roaksoax> Hey: https://stackoverflow.com/questions/35087666/how-to-upload-custom-boot-image-to-maas
<mup> Bug #1581734 changed: [2.0b5] installing maas-region-api and maas-dns should only configure bind when connected to the db <MAAS:Fix Released> <https://launchpad.net/bugs/1581734>
<mup> Bug #1633468 changed: [Subnets page, DD] Add a warning message when Device discovery is disabled <ui> <MAAS:Invalid> <https://launchpad.net/bugs/1633468>
<mup> Bug #1766334 opened: Discover VID from lldp when available <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1766334>
<mup> Bug #1766370 opened: list-boot-images reports synced after only syncing bootloader/uefi for arm64 <cdo-qa> <cdo-qa-blocker> <foundations-engine> <zion> <MAAS:New> <https://launchpad.net/bugs/1766370>
#maas 2018-04-24
<mup> Bug #1750862 changed: stress-ng-cpu short runs forever on Huawei Server <MAAS:Expired> <https://launchpad.net/bugs/1750862>
<McL0v1n> Hey hey!
<McL0v1n> Anyone around? I've got a question.
<McL0v1n> I'm having issues with MAAS losing IPMI capabilities. Everything will be good in the interface, but then suddenly all nodes power status switches to error and maas can't do anything. All usernames and passwords are still configured
<mup> Bug #1766528 opened: Charm deploys fail with EOF when one Regiond daemon is missing on one MAAS node in HA MAAS <MAAS:New> <https://launchpad.net/bugs/1766528>
<mup> Bug #1766528 changed: Charm deploys fail with EOF when one Regiond daemon is missing on one MAAS node in HA MAAS <MAAS:New> <https://launchpad.net/bugs/1766528>
<mup> Bug #1766528 opened: Charm deploys fail with EOF when one Regiond daemon is missing on one MAAS node in HA MAAS <MAAS:New> <https://launchpad.net/bugs/1766528>
<mup> Bug #1074317 opened: cmdline acquire and start is difficult <cli> <MAAS:Triaged> <https://launchpad.net/bugs/1074317>
<mup> Bug #1766637 opened: UEFI-mode Bionic deployments failing <hwcert-server> <curtin:New> <MAAS:Incomplete> <https://launchpad.net/bugs/1766637>
<mup> Bug #1766637 changed: UEFI-mode Bionic deployments failing <hwcert-server> <curtin:New> <MAAS:Incomplete> <https://launchpad.net/bugs/1766637>
<mup> Bug #1766637 opened: UEFI-mode Bionic deployments failing <hwcert-server> <curtin:New> <MAAS:Incomplete> <https://launchpad.net/bugs/1766637>
<McL0v1n> Good day!
<McL0v1n> anyone around today? Still having issues with IPMI and maas
<mup> Bug #1766651 opened: broken layout on the action dropdown for "test hardware" <MAAS:New for deadlight> <https://launchpad.net/bugs/1766651>
<mup> Bug #1766637 changed: UEFI-mode Bionic deployments failing <hwcert-server> <curtin:Invalid> <MAAS:Invalid> <https://launchpad.net/bugs/1766637>
<roaksoax> McL0v1n: Hi. What issues are you having ?
<McL0v1n> SO, I had everything in maas ready to deploy. 11 nodes, 3 of which were already juju controllers
<McL0v1n> then suddenly ipmi error on every single one
<McL0v1n> sorry, power error
<McL0v1n> so the status on every single one is at error
<McL0v1n> I tried my old work around by changing the timeout in ipmi.py, but nothing yet brings it back
<McL0v1n> roaksoax
<McL0v1n_> Joined here, had ti leave the house
<McL0v1n> Sorry about that
<roaksoax> McL0v1n: so, hold on
<roaksoax> McL0v1n: you mean you enlist/commission the machines just fine
<roaksoax> McL0v1n: they are marked 'Ready'
<roaksoax> McL0v1n: and after a few minutes, power is red ?
<mimizone> Hi all. Anything that changed in the MAAS DHCP recently that would allow to set IP from different pools based on what either the relay that sent the request to MAAS or the MAC address of the server? Our IPs are segmented by rack (a few /25 per rack) and its' necessary for getting a working L3 routing in ToR switch that the right IPs are assigned by MAAS.
<mimizone> I'd like to only use one or two MAAS region controllers for our entire setup and not have rack controllers in every racks
<McL0v1n_> Roaksoax it wasnt after a few minutes, it was all day
<McL0v1n_> They are all ready, and 3 are even deployed
<McL0v1n_> Then at a certain time im sitting there configuring juju charms to prepare for a deployment and all power statuses turn error
<mup> Bug #1766665 opened: maas-region fails with an error 500 in an attempt to delete a subnet <MAAS:Incomplete> <https://launchpad.net/bugs/1766665>
<McL0v1n_> Roaksoax: i checked tbe logs and there isnt anything out of the ordinary
<mup> Bug #1766671 opened: [2.4] 2018-04-24 17:49:06 maasserver.dhcp: [critical] None         (UNABLE TO OBTAIN TRACEBACK FROM EVENT) <MAAS:Triaged> <https://launchpad.net/bugs/1766671>
<xygnal> so....we just deployed a node as a user
<xygnal> but that node was allocated to another user
<xygnal> this was done with non-admin keys for the 2 users
<xygnal> is this known?
<mup> Bug #1766680 opened: [2.4, regression] UI action confirmation messages are missing <regression> <MAAS:Triaged> <https://launchpad.net/bugs/1766680>
<eduardo_> Hi all. If you have Debian images that are working with MAAS, send me a message. We'd like to offer $100 per working image
<eduardo_> Same thing for Fedora, CoreOS, RancherOS
<xygnal> disregard - mistake
<mup> Bug #1766707 opened: [2.4, UI] Dismissing an error on the UI, will make it never appear again <MAAS:Triaged> <https://launchpad.net/bugs/1766707>
<ltrager> eduardo_: Canonical provides paid support and may be able to assist you in deploying other operating systems
<ltrager> eduardo_: Feel free to reach out at https://maas.io/contact-us
<eduardo_> Thank ou ltrager but you can't buy from them even if you want to. sales is horrible so I can't even imagine support
#maas 2018-04-25
<mup> Bug #1765661 changed: mode argument missing from snap <MAAS:Invalid> <https://launchpad.net/bugs/1765661>
<mup> Bug #1766769 opened: [2.x, UI, enhacement] Add 'allow_proxy' to the UI per subnet basis <MAAS:Triaged> <https://launchpad.net/bugs/1766769>
<mup> Bug #1766781 opened: [2.4, UI] Context menu regression <ui> <MAAS:Triaged by deadlight> <https://launchpad.net/bugs/1766781>
<srihas> hi guys, we have an UCS environment. Inorder to control power from MaaS, we provide the API on the HTTPS but the problem is we have a selfsigned certificate and the MAAS is not making me add UCS power type. Is there a tweak that I can make?
<srihas> thank you
<mup> Bug #1765751 changed: django.db.utils.OperationalError: could not serialize access due to concurrent update during "migrate-conflicting-options" <cdo-qa> <cdo-qa-blocker> <foundations-engine> <MAAS:Fix Released> <MAAS 2.3:Triaged> <https://launchpad.net/bugs/1765751>
<mup> Bug #1703231 opened: Virsh Power address of VM changes by itself <maas> <MAAS:Incomplete> <https://launchpad.net/bugs/1703231>
<mup> Bug #1703231 changed: Virsh Power address of VM changes by itself <maas> <MAAS:Incomplete> <https://launchpad.net/bugs/1703231>
<mup> Bug #1703231 opened: Virsh Power address of VM changes by itself <maas> <MAAS:Incomplete> <https://launchpad.net/bugs/1703231>
#maas 2018-04-26
<silox> Hello, I wanted to see if anyone could verify that both Landscape (on premises install) and MAAS will both function on Ubuntu 18.04 LTS that's scheduled to be released tomorrow.  Any help would be appreciated as I'd like to use 18.04 for a Landscape/MAAS deployment for an entire datacenter.
<roaksoax> silox: MAAS is in Ubunut Bionic
<roaksoax> 2.4b2
<mup> Bug #1767032 opened: [2.4b2] An edit button is shown for non-admin users in the DNS page <MAAS:Triaged> <https://launchpad.net/bugs/1767032>
<mup> Bug #1767033 opened: [2.4b2] DNS records link to machines that the users doesn't have permission to view <MAAS:Triaged> <https://launchpad.net/bugs/1767033>
<mup> Bug #1767032 changed: [2.4b2, UI] An edit button is shown for non-admin users in the DNS page <MAAS:Triaged> <https://launchpad.net/bugs/1767032>
<mup> Bug #1767033 changed: [2.4b2] DNS records link to machines that the users doesn't have permission to view <MAAS:Triaged> <https://launchpad.net/bugs/1767033>
<mup> Bug # opened: 1767032, 1767033, 1767035, 1767038
<mup> Bug #1767035 changed: [2.4b2, UI] Normal users are shown an edit button on the AZ page <MAAS:Triaged> <https://launchpad.net/bugs/1767035>
<mup> Bug #1767038 changed: [2.4b2, UI] An edit button is shown for normal users on the subnet page <MAAS:Triaged> <https://launchpad.net/bugs/1767038>
<mup> Bug #1767035 opened: [2.4b2, UI] Normal users are shown an edit button on the AZ page <MAAS:Triaged> <https://launchpad.net/bugs/1767035>
<mup> Bug #1767038 opened: [2.4b2, UI] An edit button is shown for normal users on the subnet page <MAAS:Triaged> <https://launchpad.net/bugs/1767038>
<srihas> hi guys, we have an UCS environment. Inorder to control power from MaaS, we provide the API on the HTTPS but the problem is we have a selfsigned certificate and the MAAS is not making me add UCS power type. Is there a  tweak that I can make?
<roaksoax> srihas: https is not supported on UCS
<srihas> roaksoax: URL for XML API what should I enter here?
<srihas> to be very clear, if I enter abc-ucs.example.int in my web browser it redirects to HTTPS
<roaksoax> srihas: http based on
<srihas> roaksoax: I didn't get, sorry
<mup> Bug #1766665 changed: maas-region fails with an error 500 in an attempt to delete a subnet <MAAS:Invalid> <https://launchpad.net/bugs/1766665>
<roaksoax> srihas: you need to point maas to a HTTP endpoint, not a HTTPS endpoing or an enpoint that forwards
<srihas> roaksoax: seems something I need to do on the UCS side
<srihas> roaksoax: will look into it
<srihas> I think its better to to have a checkbox like: dont verify SSL sort of
<roaksoax> srihas: please file a bug/enhancement request
<srihas> roaksoax: nice, will try to do it
<mup> Bug #1767137 opened: [2.3] Default install is now importing bionic by default instead of xenial. <MAAS:Triaged> <https://launchpad.net/bugs/1767137>
<mup> Bug #1767140 opened: Dead Keys do not work inside Snap Packages in Bionic <MAAS:New> <https://launchpad.net/bugs/1767140>
<mup> Bug #1767140 changed: Dead Keys do not work inside Snap Packages in Bionic <snapd (Ubuntu):New> <https://launchpad.net/bugs/1767140>
<mup> Bug #1767183 opened: default commissioning OS has changed to bionic in 2.3.2 <cdo-qa> <cdo-qa-blocker> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1767183>
<mup> Bug #1767184 opened: arm64 machines fail to commission with bionic: Device "enP2p1s0" does not exist. <cdo-qa> <cdo-qa-blocker> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1767184>
<mup> Bug #1767183 changed: default commissioning OS has changed to bionic in 2.3.2 <cdo-qa> <cdo-qa-blocker> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1767183>
<mup> Bug #1767184 changed: arm64 machines fail to commission with bionic: Device "enP2p1s0" does not exist. <cdo-qa> <cdo-qa-blocker> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1767184>
<mup> Bug #1767184 opened: arm64 machines fail to commission with bionic: Device "enP2p1s0" does not exist. <cdo-qa> <cdo-qa-blocker> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1767184>
<mup> Bug #1767184 changed: arm64 machines fail to commission with bionic: Device "enP2p1s0" does not exist. <cdo-qa> <cdo-qa-blocker> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1767184>
<capncrunch4me> I know this isnt the right channel, but kind of out of options. Is there a unicorn that I need to feed or leprechaun to befriend to actually be allowed to buy support from Canonical
<capncrunch4me> specifically for MAAS
<capncrunch4me> and specifically so I can have the tool to build customer OSs
<capncrunch4me> now going on 2 weeks of phone calls and emails to Caonical
<capncrunch4me> s/Caonical/Canonical
#maas 2018-04-27
<mup> Bug #1767226 opened: Commission sees interface that isn't there on Deployment <MAAS:New> <https://launchpad.net/bugs/1767226>
<roaksoax> capncrunch4me: what do you mean ?
<mup> Bug #1767254 opened: [2.4, UI] Machine listing UI tooltips are under fields of a table <MAAS:Triaged by ya-bo-ng> <https://launchpad.net/bugs/1767254>
<mup> Bug #1767257 opened: [2.4, regression] Applying tag with a definition no longer works <MAAS:Triaged> <https://launchpad.net/bugs/1767257>
<mup> Bug #1765535 opened: 18.04 beta commissioning smartctl problem <hwcert-server> <MAAS:New> <Speedsta Website Beta Testing:New> <https://launchpad.net/bugs/1765535>
<mup> Bug #1767483 opened: [2.3] ssh key being denied upon ssh to deployed Centos 6 and Centos 7 <cpe-onsite> <MAAS:New> <https://launchpad.net/bugs/1767483>
#maas 2018-04-28
<luckielordie> hi guys, In my Images section the status is "Waiting for rack controller(s) to sync"
<luckielordie> Do i need to do anything in with my Rack Controller to get the image to sync?
#maas 2018-04-29
<mup> Bug #1738782 changed: Deployment hangs because of failure to post event <MAAS:Expired> <https://launchpad.net/bugs/1738782>
<mup> Bug #1767766 opened: MAAS snap refresh fail with ownership change error <MAAS:New> <https://launchpad.net/bugs/1767766>
<mup> Bug #1767766 changed: MAAS snap refresh fail with ownership change error <MAAS:New> <https://launchpad.net/bugs/1767766>
<mup> Bug #1767766 opened: MAAS snap refresh fail with ownership change error <MAAS:New> <https://launchpad.net/bugs/1767766>
<mup> Bug #1767766 changed: MAAS snap refresh fail with ownership change error <MAAS:Invalid> <https://launchpad.net/bugs/1767766>
<mup> Bug #1767766 opened: MAAS snap refresh fail with ownership change error <MAAS:Invalid> <https://launchpad.net/bugs/1767766>
<mup> Bug #1767766 changed: MAAS snap refresh fail with ownership change error <MAAS:Invalid> <https://launchpad.net/bugs/1767766>
#maas 2020-04-20
<mup> Bug #1873729 opened: LXD pod host does not have snap OS info <blocking-ui> <MAAS:New> <https://launchpad.net/bugs/1873729>
<mup> Bug #1873879 opened: Storage level testing (Hard Drives) is systematically failing. <MAAS:New> <https://launchpad.net/bugs/1873879>
<colombrican> Hello, need some advice ... just did a base upgrade of a maas 2.3/16.04 server to 18.04, but when I run an apt upgrade i keep getting an error pointing to LXD bridge and accessing the MAAS url gives me a 404 not found error
<colombrican> Old bridge configuration detected in /etc/default/lxd-bridge, upgradingUnsetting deprecated profile optionsAttempting to kill current lxd-bridgeBringing down and renaming existing bridge lxdbr0 to lxd-upgradeCreating a new LXD bridgeMoving the old bridge into placeConfiguring the new LXD bridgeSetting IPv4 network to 10.80.0.15/24Error: Failed to
<colombrican> run: dnsmasq --strict-order --bind-interfaces --pid-file=/var/lib/lxd/networks/lxdbr0/dnsmasq.pid --except-interface=lo --interface=lxdbr0 --quiet-dhcp --quiet-dhcp6 --quiet-ra --listen-address=10.80.0.15 --dhcp-no-override --dhcp-authoritative --dhcp-leasefile=/var/lib/lxd/networks/lxdbr0/dnsmasq.leases
<colombrican> --dhcp-hostsfile=/var/lib/lxd/networks/lxdbr0/dnsmasq.hosts --dhcp-range 10.80.0.2,10.80.0.254,1h -s lxd -S /lxd/ --conf-file=/var/lib/lxd/networks/lxdbr0/dnsmasq.raw -u lxd: dnsmasq: failed to create listening socket for 10.80.0.15: Address already in usedpkg: error processing package lxd (--configure): installed lxd package post-installation
<colombrican> script subprocess returned error exit status 1Processing triggers for libc-bin (2.27-3ubuntu1) ...Errors were encountered while processing: lxdE: Sub-process /usr/bin/dpkg returned an error code (1)
<eXtace> the docs for curtin customiation are a big ambiguous 'The machine needs to be the machine name, as shown in the web UI URL."  The web UI for the machine doesn't have it's name,  just it's identifier,  I've tried every possible combination but cannot get it to work,  can anyone else wexplain how they did this to get a MACHINE SPECIFIC
<eXtace> curtin_userdata script in place?
<eXtace> curtin_userdata_custom_amd64_generic_xenial_<shortname> curtin_userdata_custom_amd64_generic_xenial_<fqdn> curtin_userdata_custom_amd64_generic_xenial_<id_from url>   none of these work
<eXtace> curtin_userdata_custom does (we are using custom images),  but I need a one-off to test against a single machine so I don't affect any other nodes being provisioned.
<eXtace> ok,  figured it out,  you cannot use "xenial" like in the examples above you need to use the name of the boot resource you created, and the _custom_ IS REQUIRED.
<eXtace> curtin_userdata_custom_amd64_generic_<IMAGE_NAME>_<SHORTNAME>  where IMAGE_NAME is pulled from maas <profile> boot-resources read  and SHORTNAME should be obvious...  The docs need improvement....
<mup> Bug #1873879 changed: Storage level testing (Hard Drives) is systematically failing. <MAAS:New> <https://launchpad.net/bugs/1873879>
<mup> Bug #1873879 opened: Storage level testing (Hard Drives) is systematically failing. <MAAS:New> <https://launchpad.net/bugs/1873879>
<mup> Bug #1873879 changed: Storage level testing (Hard Drives) is systematically failing. <MAAS:New> <https://launchpad.net/bugs/1873879>
<mup> Bug #1873962 opened: Machines can have inconsistent testing status <MAAS:New> <https://launchpad.net/bugs/1873962>
<mup> Bug #1873962 changed: Machines can have inconsistent testing status <MAAS:New> <https://launchpad.net/bugs/1873962>
<mup> Bug #1873962 opened: Machines can have inconsistent testing status <MAAS:New> <https://launchpad.net/bugs/1873962>
#maas 2020-04-22
<mup> Bug #1858766 changed: Machine can't be redeployed using zfsroot <curtin:Expired> <MAAS:Expired> <https://launchpad.net/bugs/1858766>
<mup> Bug #1863791 changed: apt-install of maas-rack-controller fails trying to connect to maas-internal hostname <cdo-qa> <foundations-engine> <MAAS:Expired> <https://launchpad.net/bugs/1863791>
<mup> Bug #1858766 opened: Machine can't be redeployed using zfsroot <curtin:Expired> <MAAS:Expired> <https://launchpad.net/bugs/1858766>
<mup> Bug #1863791 opened: apt-install of maas-rack-controller fails trying to connect to maas-internal hostname <cdo-qa> <foundations-engine> <MAAS:Expired> <https://launchpad.net/bugs/1863791>
<mup> Bug #1858766 changed: Machine can't be redeployed using zfsroot <curtin:Expired> <MAAS:Expired> <https://launchpad.net/bugs/1858766>
<mup> Bug #1863791 changed: apt-install of maas-rack-controller fails trying to connect to maas-internal hostname <cdo-qa> <foundations-engine> <MAAS:Expired> <https://launchpad.net/bugs/1863791>
<mup> Bug #1872021 changed: [Ubuntu][Bionic] systemd caused kernel to hang on fsnotify wait-on-completion <MAAS:Invalid> <linux (Ubuntu):New> <linux (Ubuntu Bionic):Triaged> <linux (Ubuntu Eoan):New> <linux (Ubuntu Focal):New> <https://launchpad.net/bugs/1872021>
#maas 2020-04-23
<mup> Bug #1874355 opened: Controller details page not updated to match machine details page designs <ui> <MAAS:New> <https://launchpad.net/bugs/1874355>
<mup> Bug #1874356 opened: Unable to view storage tab on controllers detail page <ui> <MAAS:New> <https://launchpad.net/bugs/1874356>
<mup> Bug #1874355 changed: Controller details page not updated to match machine details page designs <ui> <MAAS:New> <https://launchpad.net/bugs/1874355>
<mup> Bug #1874356 changed: Unable to view storage tab on controllers detail page <ui> <MAAS:New> <https://launchpad.net/bugs/1874356>
<mup> Bug #1874355 opened: Controller details page not updated to match machine details page designs <ui> <MAAS:New> <https://launchpad.net/bugs/1874355>
<mup> Bug #1874356 opened: Unable to view storage tab on controllers detail page <ui> <MAAS:New> <https://launchpad.net/bugs/1874356>
<mup> Bug #1874439 opened: Use standard notifications for deprecation notices <MAAS:Triaged by ack> <https://launchpad.net/bugs/1874439>
<mup> Bug #1874538 opened: Adding LXD Pod with pre-composed resources errors out <MAAS:In Progress by newell-jensen> <https://launchpad.net/bugs/1874538>
<mup> Bug #1874538 changed: Adding LXD Pod with pre-composed resources errors out <MAAS:In Progress by newell-jensen> <https://launchpad.net/bugs/1874538>
<mup> Bug #1874538 opened: Adding LXD Pod with pre-composed resources errors out <MAAS:In Progress by newell-jensen> <https://launchpad.net/bugs/1874538>
#maas 2020-04-24
<mup> Bug # changed: 1871003, 1873430, 1873478, 1873729
<mup> Bug # opened: 1871003, 1873430, 1873478, 1873729
<mup> Bug # changed: 1871003, 1873430, 1873478, 1873729
<mup> Bug #1874840 opened: [feature] Add support for RHEV power driver <feature> <MAAS:New> <https://launchpad.net/bugs/1874840>
<mup> Bug #1874840 changed: [feature] Add support for RHEV power driver <feature> <MAAS:New> <https://launchpad.net/bugs/1874840>
<mup> Bug #1874840 opened: [feature] Add support for RHEV power driver <feature> <MAAS:New> <https://launchpad.net/bugs/1874840>
<mup> Bug #1874847 opened: [2.7] cannot add kvm pod: 503 Service Unavailable <MAAS:New> <https://launchpad.net/bugs/1874847>
<mup> Bug #1874847 changed: [2.7] cannot add kvm pod: 503 Service Unavailable <MAAS:New> <https://launchpad.net/bugs/1874847>
<mup> Bug #1874847 opened: [2.7] cannot add kvm pod: 503 Service Unavailable <MAAS:New> <https://launchpad.net/bugs/1874847>
<mup> Bug #1874847 changed: [2.7] cannot add kvm pod: 503 Service Unavailable <MAAS:New> <https://launchpad.net/bugs/1874847>
<mup> Bug #1874847 opened: [2.7] cannot add kvm pod: 503 Service Unavailable <MAAS:New> <https://launchpad.net/bugs/1874847>
<mup> Bug #1874869 opened: vcenter settings are missing "cluster" option <MAAS:New> <https://launchpad.net/bugs/1874869>
<mup> Bug #1874895 opened: 2.7.0 - KVM Pod hosts using DHCP don't work  <MAAS:New> <https://launchpad.net/bugs/1874895>
<mup> Bug #1874917 opened: MAAS commissioning hook can not handle bonds <MAAS:In Progress by ltrager> <https://launchpad.net/bugs/1874917>
<mup> Bug #1874917 changed: MAAS commissioning hook can not handle bonds <MAAS:In Progress by ltrager> <https://launchpad.net/bugs/1874917>
<mup> Bug #1874917 opened: MAAS commissioning hook can not handle bonds <MAAS:In Progress by ltrager> <https://launchpad.net/bugs/1874917>
#maas 2020-04-25
<mup> Bug #1874984 opened: Unable to resolve apt proxy <MAAS:New> <https://launchpad.net/bugs/1874984>
<mup> Bug #1874984 changed: Unable to resolve apt proxy <MAAS:New> <https://launchpad.net/bugs/1874984>
<mup> Bug #1874984 opened: Unable to resolve apt proxy <MAAS:New> <https://launchpad.net/bugs/1874984>
<mup> Bug #1875064 opened: Acquire IP address before 'deploy'? <feature> <MAAS:New> <https://launchpad.net/bugs/1875064>
<mup> Bug #1875064 changed: Acquire IP address before 'deploy'? <feature> <MAAS:New> <https://launchpad.net/bugs/1875064>
<mup> Bug #1875064 opened: Acquire IP address before 'deploy'? <feature> <MAAS:New> <https://launchpad.net/bugs/1875064>
<mup> Bug #1875064 changed: Acquire IP address before 'deploy'? <feature> <MAAS:New> <https://launchpad.net/bugs/1875064>
<mup> Bug #1875064 opened: Acquire IP address before 'deploy'? <feature> <MAAS:New> <https://launchpad.net/bugs/1875064>
#maas 2020-04-26
<mup> Bug # changed: 1685615, 1702751, 1793077, 1814349, 1849294, 1849513, 1855158, 1864686
