#maas 2013-04-08
<alex_rus> Hello, is who?
<roaksoax> allenap: howdy! so just tested your fix and seems to work for unmanaged networks (I have 2 clusters in 2 different networks)
#maas 2013-04-09
<bigjools> roaksoax: fwiw I am getting apparmor problems with dhcp on quantal using the dailybuild package, is this known?
<roaksoax> bigjools: no tomy knowledge. what kind of error?
<bigjools> roaksoax: Apr  9 12:35:44 maas dhcpd: Open a socket for LPF: Permission denied
<bigjools> Apr  9 12:35:44 maas kernel: [ 1194.554101] type=1400 audit(1365474944.338:53): appar
<bigjools> mor="DENIED" operation="create" parent=1 profile="/usr/sbin/dhcpd" pid=3444 comm="dhc
<bigjools> pd" family="packet" sock_type="raw" protocol=768
<roaksoax> bigjools: has packaging changed in upstream? cause trunk should have all of the fixes that were made for qusntal
<bigjools> roaksoax: dunno - this is a build from a month ago
<bigjools> roaksoax: the daily ppa is a mess of versions
<bigjools> could do with an overhaul
<roaksoax> bigjools: thats weird
<roaksoax> yeah
<bigjools> anyway, testing the experimental Go-juju provider
<roaksoax> bigjools: i have not sern those issues running raring nor the sru prepared package
<bigjools> roaksoax: I suspect the package itself is screwed, I don't trust them any more because of so many version problems (upload fail with duped files)
<bigjools> this makes me sad
<roaksoax> yeah
<bigjools> roaksoax: commissioning and enlistment are taking *ages* now... :/
<TheChistoso_> i can't get the MAAS notice "The region controller does not know whether any boot images have been imported yet. If this message does not disappear in 5 minutes..." to go away
<TheChistoso_> where are these logs I'm supposed to inspect?
<TheChistoso_> anybody here?
<roaksoax> bigjools: i think I know why that is.. and I already have a fix for it
<roaksoax> allenap: howdy!! So FPI is mostly done, I do, however, have a question for you
<roaksoax> allenap: check https://code.launchpad.net/~andreserl/maas/trunk-fpi/+merge/152039 and look at line 707
<roaksoax> allenap: how do you think we should approach obtaining the interface in order to obtain the IP when there are no managed networks?
<allenap> roaksoax: I can't think of a better way than that. Do you have anything in mind?
<roaksoax> allenap: no idea.. wsa trying to think of a way but other than obtaining the first one, there doesn'y seem to be much of a solution
<allenap> roaksoax: Stick with that for now then.
<roaksoax> allenap: will do, thanks!
<TheChistoso_> hello!
<bigjools> roaksoax: would be be in the ipmi detection by any chance?
<bigjools> s/be be/it be/
<roaksoax> bigjools: were you using a branch with the new ipmi detection?
<roaksoax> bigjools: or did you enable the IPMI params?
<bigjools> roaksoax: argh, sorry, desktop problems.  my mouse keeps disconnecting itself and replugging doesn't work, I need to reboot.
<bigjools> anyway, it is slow with or without ipmi params enabled
<roaksoax> bigjools: have you grabbed any logs? (such as cloud init ones?)
<roaksoax> bigjools: while i have runned into slow ipmi detection myself, Its for network issues as my network setup is a strange one
<bigjools> roaksoax: not yet, fighting maas
<bigjools> and I need the backdoor image... grar
<roaksoax> bigjools: re on your re-writing thing.. I agree. I wanted to separate the ipmi detection on a separate package/binary... however, the particular bug that's been fixed there is a bug that was targetted for 1.2 and has been there for a long time
<roaksoax> and the only thing that caused is longer time on enlistment/commissioning for trying to discover ipmi
<bigjools> roaksoax: only longer on VMs though?
<bigjools> it takes about 10 minutes to complete on the HP microservers now
<roaksoax> bigjools: with today's fix, it should not even try to detect ipmi in VM's
<roaksoax> bigjools: and that's weird, I have my microservers here working just fine
<roaksoax> bigjools: they were taking longer than usual only because of my network setup
<bigjools> roaksoax: I suspect my maas is screwed up, I had to downgrade because of the crazy package versioning and it may have gone wrong
<bigjools> I will reinstall
<roaksoax> bigjools: ok
<roaksoax> bigjools: what are you using, daily builds?
<bigjools> yeah
<roaksoax> weird then
<bigjools> I previously had a home-made trunk build on quantal
<bigjools> I switched to daily
<bigjools> but the south migrations in the DB was screwed
<roaksoax> yeah that's a likely cause of nighmare's
 * bigjools getting fed up of twitter follow spam
<roaksoax> bigjools: i'll be on and off for the next hour/2 hour so let me know your findings
<bigjools> roaksoax: I'll be a while - I am upgrading the server to raring
#maas 2013-04-10
<roaksoax> allenap: any updaes?
<roaksoax> err
<roaksoax> bigjools: any luck>
<roaksoax> ?
<bigjools> roaksoax: literally just finished
<bigjools> seems ok now
<bigjools> however
<bigjools> I did see an error fly by from maas-ipmi something about None type not having a group attribute
<roaksoax> bigjools: ok let me check
<bigjools> then it shut down so it disappeared :/
<bigjools> this is raring packages btw
<bigjools> I need to take the dog out now, leave me a message if you want me to do anything
<roaksoax> bigjools: i'm testing enlistment here and see what happens
<roaksoax> bigjools: did it add the power settings correctly?
<roaksoax> bigjools: I just tested it, it works just fine for me
<roaksoax> bigjools: maybe your bmc is locked out?
<bigjools> roaksoax: I can't find the commissioning data after reinstall, did you move it?
<roaksoax> bigjools: jtv did
<roaksoax> bigjools: it's in /usr/share/maas/pyshared/metadataserver/commission/user_data.template IIRC
<bigjools> aha
<bigjools> /usr/share/maas/preseeds/enlist_userdata
<bigjools> everything worked but I hadn't enabled the BMC options for the HP so no power was detected
<roaksoax> bigjools: yeah that's enlistment, commissioning is under metadataserver (instead of /etc/maas/commissioning-user-data)
<roaksoax> bigjools: ah! that was it then :)
<bigjools> mmmm which do we change?
<bigjools> /usr/share/pyshared/metadataserver/commissioning/user_data.template
<bigjools> has the same code
<roaksoax> bigjools: yeah, so I really wanna make it a binary
<roaksoax> bigjools: along with maas-signal
<bigjools> that'd be nice
<roaksoax> (which is used during commissioning)
<roaksoax> so we can ditch all the dup code
<bigjools> no complains from me :)
<bigjools> complaints*
<roaksoax> cool, I'll try to get that done this week
<bigjools> roaksoax: just testing a new enlistment with the impi options set up, let's see ...
<bigjools> ipmi even
<bigjools> roaksoax: didn't detect it on enlistment
<roaksoax> bigjools: i would need to see logs why. I have just tested it myself
<roaksoax> and it worked like a charm
<bigjools> getting logs is hard :(
<bigjools> we really need to make them all go back to the maas host
<roaksoax> bigjools: nah! get the backport image thing and at touch /tmp/block-poweroff to the user data
<roaksoax> bigjools: and then you just ssh in and that's it :)
<roaksoax> bigjools: but yes, we need to get all those logs back to maas
<bigjools> roaksoax: that is too hard, really, when all we should do is rsyslog
<roaksoax> agreed
<bigjools> heck even my router logs using rsyslog to my server :)
<roaksoax> heh :)
<bigjools> I actually thought we had rsyslog set up
<bigjools> isn't it on the kernel cmd line?
<roaksoax> bigjools: we do, it only works for deployments
<roaksoax> bigjools: it doesn't work for ephemeral images
<bigjools> ah
<bigjools> shame
<roaksoax> bigjools: indeed.. but anyways... i thought danwest was gonna be in charge of maas from now on..
<bigjools> roaksoax: apparently so
<bigjools> roaksoax: so, I enabled this line:
<bigjools> IPMI_SI_PARAMS="type=kcs ports=0xca2"
<roaksoax> bigjools: that should be all you need
<bigjools> in /usr/share/pyshared/metadataserver/commissioning/user_data.template
<bigjools> and
<bigjools> /usr/share/maas/preseeds/enlist_userdata
<bigjools> didn't get power params on enlist or commissioning
<bigjools> this has happened before - the BMC goes all weird
<roaksoax> bigjools: boomer, I'm guessing there's an issue with your BMC?
<roaksoax> bigjools: yeah... I upgraded to the latest fiirmware
<roaksoax> so maybe you should do the same
<bigjools> last time, it refused DHCP OFFER all the time
<bigjools> then it worked for a while
<bigjools> oh
<bigjools> Apr 10 14:10:20 maas dhcpd: Can't create new lease file: Permission denied
<bigjools> apparmor fix needed
<bigjools> it existed already I think
<roaksoax> bigjools: i'll test that tomorrow and see what happens. cause I'm pretty sure it was working
<roaksoax> bigjools: unless the fixes got dropped
<bigjools> let me check my BMC hang on
<bigjools> ah bollocks this one's easy
<bigjools> the BMC has no ethernet cable in it :)
<roaksoax> lol
<roaksoax> :)
<bigjools> EOUTOFROUTERPORTS
<bigjools> I'll delete it and do it again
<bigjools> so I plugged in a cable and it's not DHCP requested yet :/
<roaksoax> bigjools: ok I think it got dropped
<roaksoax> the change in isc-dhcp
<bigjools> damn
<roaksoax> i'm checking now just o be sure
<bigjools> that was really screwing people over
<roaksoax> bigjools: nope, my bad, the fix is there
<roaksoax> bigjools: check in /etc/appamor.d/dhcpd.d/ whether there's the maas profile
<bigjools> roaksoax: no :/
<bigjools> why is that missing?  I install maas-dhcp
<bigjools> installed
<roaksoax> aas-dhcp.install:/debian/tmp/etc/apparmor.d/dhcpd.d/maas
<roaksoax> maas-dhcp.install:/debian/tmp/etc/apparmor.d/dhcpd.d/maas
<roaksoax> maas is installing it
<bigjools> maas is installed
<roaksoax> roaksoax@pursue:/etc/apparmor.d/dhcpd.d$ ls
<roaksoax> maas
<bigjools> oh wait it's there
<bigjools> so I suspect there's a profile problem where it can't delete and make a new file
<bigjools> ?
<bigjools> or open as new
<bigjools> overwriting an old one
<bigjools> aha I see IPMI
<bigjools> and it powered on when I did "accept & commission"
<bigjools> \o/
<roaksoax> \o/
<roaksoax> bigjools: alright, the other i can think of is that the profile has not being loaded with the maas related stuff
<roaksoax> see maas-dhcp.postinst in http://bazaar.launchpad.net/~maas-maintainers/maas/packaging/revision/169
<bigjools> roaksoax: it must be, it works
<bigjools> it's just that error on restarting it if there's an existing file
<bigjools> it can't clean out the file AFAICS
<bigjools> so it'll grow forever
<roaksoax> ah! I see
<roaksoax> alright then
<roaksoax> knowing you got it working
<roaksoax> i'm gonna go pass out :)
<bigjools> heh
<roaksoax> have a good day man
 * roaksoax sleeps
<bigjools> it must be late there
<roaksoax> half past midnight :)
<bigjools> go sleep!
<bigjools> thanks!
<roaksoax> np :)
#maas 2013-04-11
<Gayman_> could i log into maas node directly??
<bigjools> Gayman_: if you use Juju yes, or if you set an ssh key in maas, yes
<Gayman_> should i create the ssh key before installation of the new node, or there is some way that i can transfer the key to the nede
<bigjools> no it needs to be done in advance
<Gayman_> how i can do so ??
<Gayman_> do you mean that i have to create the key before start installation of the new node?
<bigjools> it's easiest to use juju, maas works best that way
<Gayman_> ok, but how to transfer the key from the maas master to mass node , with or without juju..
<bigjools> you set it on your user preferences in maas and then it'll be uploaded to the node when it installs
<bigjools> with juju, it just works too
<Gayman_> do you mean to copy past the ssh pub key of the master maas into the preferences UI page , i do so and it says invalid key
<jtv> Gayman_: I'm not sure about "of the master maas"...  What you need to do is copy (the text of) your own ssh pub key into that UI page, so that you can then use your own private key to log into nodes that are allocated to you.
<Gayman_> i try to do so many tims i get "Invalid SSH public key"
<Gayman_> could i download maas package into the maas server so when adding new node i don't have to connect to internet?\
<roaksoax> rvba: still around?
<18WADAAUZ> how to save a copy of all needed software -into master maas node- for enlist new node, so i don't need to download this package each time i enlist new node
<roaksoax> 18WADAAUZ: edit /usr/share/maas/preseeds/enlist_userdata and eble apt_proxy to use the proxy
<bigjools> 18WADAAUZ: the default installation of maas includes a proxy so that all nodes use it, so unless you changed something it will already download it only once
<bigjools> roaksoax: he doesn't need to edit that
#maas 2013-04-12
<roaksoax> bigjools: he does if he is using quantal
<roaksoax> 18WADAAUZ: are you using quantal?
<18WADAAUZ> no
<roaksoax> 18WADAAUZ: raring?
<18WADAAUZ> no
<18WADAAUZ> i am very new to maas
<roaksoax> 18WADAAUZ: what ubuntu release are oyu using?
<18WADAAUZ> 12.04.2
<roaksoax> 18WADAAUZ: so you should already be using the proxy by defaul IIRC
<bigjools> roaksoax: it still uses squid-deb-proxy in quantal, no?
<bigjools> roaksoax: and when are we going to SRU? :)
<roaksoax> bigjools: yes, but proxy access for enlistment/commissioning is not enabled by default
<roaksoax> bigjools: it is in the queue already waiting for verification :)
<roaksoax> bigjools: first python-tx-tftp and python-django need to be verified
<roaksoax> before we verify maas
<bigjools> roaksoax: very disappointed with the comments on the dhcp bug :/
<roaksoax> bigjools: link?
<bigjools> https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1069570
<ubot5> Launchpad bug 1069570 in MAAS "1 MAC Address, two IPs - DNS is "out of sync" with DHCP leases databases, I think..." [Critical,Triaged]
<18WADAAUZ> about proxy configration, i was think it is only to allow the master maas server to get internet connection. not internal proxy
<roaksoax> bigjools: that woudl also probably require TB exception
<18WADAAUZ> do i have to configure the proxy setting inside maas server manulay??
<bigjools> roaksoax: I can't remember where the proxy stuff was backported
<bigjools> if at all
<donmai> hello, is there an channel for MAAS support?
<donmai> or would questions go here
<jtv> donmai: yes, questions go here â it's still a bit quiet though because Europe is only just waking up.
<amir___> hi
<amir___> I have created a new MAAS ,what will the username and password for login
<amir___> kinly help me
<roaksoax> rvba: howdy!!
<roaksoax> rvba: still around?
<AskUbuntu> MAAS PXE Boot fail. IP-Config : no response | http://askubuntu.com/q/280811
#maas 2013-04-14
<Gayman_> for simple MAAS server and 3 nodes do i need to set nova.conf to accept multihost
#maas 2014-04-07
<basicer> So I have my curtin preseed doing some custom partition stuff, and it works okay, but grub fails to install.
<basicer> Where can I see what commands its trying to run so I can fix it ?
<gmb> jtv1: Iâve realised that I forgot to finish reviewing https://code.launchpad.net/~jtv/maas/boot-image-dict/+merge/214210 for you; profuse apologies. Iâll get right on it once Iâve finished this branch.
<gmb> bigjools: Do we have a sample of what bootresources.yaml should look like  in order to pull in HWE kernels?
<gmb> Just realised that my documentation reads âupdate bootresources.yaml appropriatelyâ which is a bit like saying âuse a goodly measure of spicesâ
<bigjools> gmb: it's all in the subarchs
<bigjools> so amd64/hwe-t for example
<gmb> bigjools: Thanks.
<bigjools> gmb: see http://maas.ubuntu.com/images/ephemeral-v2/daily/streams/v1/index.json
<gmb> bigjools: Ah, perfect!
<gmb> Excellent typoâ¦ âHardware enoblementâ
 * gmb fixes
<gmb> bigjools: Could you use tags to set HWE kernels?
<bigjools> gmb: no, it's driven entirely from subarchj
 * gmb is still murky about tag magic
<bigjools> "tags are cheesy"
<gmb> :)
<gmb> bigjools: https://code.launchpad.net/~gmb/maas/hwe-docs/+merge/214476
<gmb> Cheese-free, hopefully
<bigjools> gmb: cheers, will be on it shortly
<bigjools> gmb: there;s code at the bottom of the diff
<gmb> bigjools: Ah, sorry. colo-branch-using fail.
<gmb> Fixing.
<gmb> bigjools: Don
<gmb> e
<gmb> bigjools: Thanks for the review. All good points. On it now.
<bigjools> gmb, allenap: https://bugs.launchpad.net/maas/+bug/1302156
<ubot5> Ubuntu bug 1302156 in MAAS "maas upgrade 0072_remove_ipmi_autodetect fails" [Undecided,Incomplete]
<jtv1> bigjools: I'm just putting up a fix for bug 1302772.
<ubot5> bug 1302772 in MAAS 1.5 "update of maas-cluster-controller on trusty dumps traceback and crashes" [Critical,Triaged] https://launchpad.net/bugs/1302772
<bigjools> jtv: you're a star
<bigjools> jtv: I shall leave one of gmb or allenap to review that, as I am EOD now.  Thank you!
<jtv> np
<jtv> And I see that gmb assigned me the card.
<gmb> Iâll review it.
<gmb> Seems fair
<jtv> According to the timestamp, about 3 minutes before I ever mentioned it.  :)
<gmb> :)
<jtv> Thanks!
<jtv> Did you  finish reviewing my other branch?
<gmb> jtv: Iâm on it now.
<jtv> Ah OK
 * gmb designates self reviewmeister for this morning.
<jtv> Schnell!  Schnell!
<strikov> jtv: hey
<strikov> jtv: how about extending TestMain to (1) have/pull multiple labels (2) have/pull .gz image to make sure that unpacking works
<jtv> strikov: Useful in themselves, but would complicate a test that is already quite overweight and potentially brittle...  It's always tempting to throw more complications into these tests, but also quite costly.
<jtv> If we can unit-test these points, great.
<jtv> (Today's a holiday for me, so not around much)
<jtv> If we do the unpacking, then we can unit-test it.  If it's Simplestreams' job, then it's really something for the Simplestreams tests.
<strikov> jtv: Okay, thanks, got your point. Enjoy your holiday :)
<jtv> Thanks!
<strikov> jtv: I started to work on tests related to image unpacking (we do it, not ss) but met with one serious issue: euc2tgz tool (we use it to convert .img to .tgz) requires root permissions
<tych0> hi allenap, so it looks like i do want to trigger the celery job manually on the import process
<tych0> i guess you guys must do this for tests and stuff, is there a way to do that?
<jtv> strikov: ah yes, that tool... one thing you can try is fakeroot.
<jtv> It's like sudo, but fake.  :-)
<jtv> fakeroot runs a child process that thinks it's root, a lot like sudo, but it doesn't actually get any of the privileges.
<jtv> tych0: you can just run a celery task (i.e. a function defined with the @task decorator) by calling its delay() method.
<jtv> (Yes, the functions have methods :)
<tych0> jtv: ok, so i just import it and do footask.delay()?
<tych0> cool
<jtv> tych0: Yes.  And don't forget, when you need to patch out a celery task for a test, you actually need to patch out its delay() method!
<tych0> jtv: yep, we actually want to run this one this time :-)
<jtv> Ah, that's easier.  :)
<jtv> During tests, celery is wired up to execute tasks synchronously.
<jtv> In fact we've been sort of doubting the wisdom of that choice â because some of it gets run implicitly during tests for no good reason.
<webbrandon> any of you ever ran into these when mining: http://paste.ubuntu.com/7217201/ ?  I just started a priate network server and all my miners get that, trying to think of why?
<jtv> Mining..?
<webbrandon> oops
<webbrandon> wromg chan
<jtv> oic
<jtv> gmb, rvba: I'm backporting my fix for the config bug (where the old "boot" section in pserv.yaml broke the upgrade).  No objections?
<rvba> jtv: sounds good to me.
<tych0> hi jtv, i'm getting http://paste.ubuntu.com/7217337/
<jtv> tych0: new one on me... one of the guys in Europe may be able to help.
<tych0> ok
<tych0> rvba: ^^ ?
<tych0> or allenap
<jtv> Could be a celery change.
<tych0> i think this is probably something you've always had to do
<tych0> i vaguely remember rvba describing to me this before, at least
<jtv> Hmm yes, it's not a change in celery â it's something we do.
<rvba> tych0: yes, hang onâ¦
<rvba> tych0: Wrong celery config.
<tych0> ok, how do i pass the right one?
<rvba> tych0: you have two celery config in /etc/maas, have a look at the upstart script to see what variable you need to define to load the right config.
<tych0> ok
<tych0> hi rvba, sorry for being slow, but: http://paste.ubuntu.com/7217420/
<tych0> i'm not sure what variables to export exactly, based on my /etc/init/maas-cluster-celery.conf
<AskUbuntu> MAAS / nodes have limited internet access after install | http://askubuntu.com/q/444563
<tych0> allenap: any thoughts on my question above?
<allenap> tych0: otp, biab
<tych0> allenap: sure, no worries
<allenap> tych0: Are you setting CELERY_CONFIG_MODULE in the environment before invoking this?
<allenap> It has a similar approach to Djangoâs settings module.
<allenap> tych0: Are you trying to kick off the import job? That can be done via the remote API, but you donât get any feedback, so I assume you want to run it directly?
<tych0> allenap: yeah, viz. the paste above
<tych0> i might be doing it wrong, though
<tych0> allenap: oh, if we can do that via the api that is good enough
<allenap> tych0: I was looking at the wrong paste :-/
<tych0> allenap: we are going to run the import directly
<tych0> and then run the celery job to do the import
<tych0> and then check if it imported everything
<tych0> so i guess it would be easiest if we could run it directly so it could fail for us
<tych0> but not super important, since it probably (:-) won't fail
<tych0> the import job itself is much more likely to fail
<allenap> tych0: I donât follow :) Do the import directly then run the celery job to do the import? Do you mean the celery job to report back to the region whatâs been imported (report-boot-images or something like that)?
<tych0> yep
<tych0> the second one
<tych0> ideally we'd run that celery job manually too
<tych0> because we don't want to be stuck in a wait loop because it broke
<allenap> tych0: Yeah :-/ Okay, Iâll see if I can figure out why that setting isnât available.
<tych0> allenap: ok, cool, thanks
<tych0> i tried looking at celery
<tych0> scary stuff :-)
<allenap> tych0: Instead of /etc/maas in PYTHONPATH, use /usr/share/maas
<allenap> Or, both.
<tych0> allenap: bingo, thank you
<tych0> now i get back an AsyncResult object, which isuppose mean things worked?
<allenap> tych0: /etc/maas/maas_local_celeryconfig_cluster.py will probably only be readable by root:maas, so make sure youâre running as root or in the maas group; you wonât get any warning if it canât read that module because of permissions.
<allenap> tych0: Might have :) I donât know what one of those is.
<tych0> http://paste.ubuntu.com/7217779/
<allenap> I donât even know what a result backend is.
<allenap> rvba: Are you around? ^
<lazyPower> greetings maasers. I've run into an interesting issue with maas on trusty server that appeared after I rebooted the machine. http://i.imgur.com/QsOuhYZ.jpg
<lazyPower> it has to do with iscsi target host, and the tgt bootstrapping, this error was hit before but skipped. Now that i've rebooted the maas region-controller (Which is also the cluster-controller) i now get halted on this during the pxe boot process
<tych0> allenap: hmm, ok
<tych0> it isn't showing up in the logs, so i don't think it is actually running
<allenap> lazyPower: I suspect thatâs https://bugs.launchpad.net/maas/+bug/1300548. That will be fixed in trusty soon, but if you look at the diff in that change you can see that all you need to do is create a missing symlink (and probably restart tgt).
<ubot5> Ubuntu bug 1300548 in maas (Ubuntu) "tgt targets do not persist after a reboot" [Undecided,Fix released]
<allenap> tych0: Make sure youâve got both /etc/maas *and* /usr/share/maas in PYTHONPATH.
<allenap> I donât think thatâll fix the bug youâre seeing, but it needs to be done anyway.
<tych0> allenap: ok, yeah, didn't fix anything :-(
<lazyPower> aha! i knew i found it but closed the tab, and was unable to refind it.
<lazyPower> thanks allenap
<allenap> tych0: I think this is happening because, when you call .delay(), it expects to be able to send that task off to a queue. In MAASâs case, RabbitMQ.
<allenap> tych0: You need to find the function to call that actually executes the body of the code.
<allenap> run() maybe, but that doesnât seem to do anything here.
<tych0> hmm, ok
<tych0> just fiddling with somethign else, will look at it in a sec
<rvba> allenap: tych0: back with a decent internet connectionâ¦
<allenap> tych0: Youâre better off just calling maas-import-pxe-files!
<tych0> allenap: that's what we're planning to do
<tych0> but we need to also trigger the celery job to have it collect the images
<allenap> Thatâs all the task in p.tasks.report_boot_images does: calls sudo -n -E maas-import-pxe-files.
<rvba> tych0: right, you can't use r.failed(): MAAS doesn't store the result of the tasks it sends.
<tych0> otherwise we can't create a node
<tych0> allenap: yeah, that's what we were doing before
<tych0> now maas does things via celery vs. a simple filesystem check
<tych0> so we hav eto trigger the celery job too
<allenap> tych0: Yeah, ignore about the last 120 seconds from me :)
<allenap> Possibly more :)
<tych0> ideally we'd be able to trigger the celery job manually as well
<allenap> I was getting muddled between report_boot_images and import_boot_images.
<tych0> so i ncase that fails we get a non-zero exit code and know to inform the user
<allenap> rvba: So, how do we execute a task directly? .run?
<rvba> allenap: task.apply_async()
<allenap> tych0, rvba: Iâve just realised whatâs going to cause an issue. The credentials arenât in p.cache.cache (fwiw, p.cache.initialize() needs to be called early too).
<allenap> rvba: Doesnât apply_async() arrange for the task to be called later?
<rvba> allenap: yes, that's what I thought you meant.  Oh, you meant call the task's code manually?
<allenap> rvba: Yeah. I think .run() is the badger.
<allenap> tych0: Getting the credentials into p.cache.cache will result in total hair loss.
<allenap> report_boot_images() needs them to talk to the API.
<allenap> tych0: Wellâ¦ you might be able to fudge it.
<allenap> tych0: Do you have a one:two:three credentials thing for the API to hand at the point you need to call report_boot_images()?
<tych0> yep
<tych0> so i can pass those in somehow
<allenap> tych0: Here goes:
<allenap> from provisioningserver import cache
<allenap> cache.initialize()
<allenap> from provisioningserver import auth
<allenap> auth.record_api_credentials(âone:two:threeâ)
<allenap> from provisioningserver import tasks
<allenap> tasks.report_boot_images(http_proxy=â¦)
<allenap> Watch out for the quotes above; my machine automatically changes them to typographical quotes.
<tych0> yeah, saw that
<tych0> r.e. the quotes
<tych0> allenap: cool, will try now
<allenap> tych0: Eugh, ignore the http_proxy bit. I am yet again getting muddles.
<allenap> muddled too.
<allenap> tych0: I have to go now, but Iâll be back in ~2 hours.
<tych0> allenap: ok, it looks like this won't work exactly, but i think i can get it to work
<tych0> need to source /etc/maas/celery.conf and some other stuff
<tych0> but this is a lot further than i would have gotten myself
<tych0> i will let you know what i come up with
<allenap> tych0: Ah, yes! Source /etc/maas/maas_cluster.conf and export MAAS_URL and CLUSTER_UUID.
<tych0> yep
<tych0> arg
<tych0> 403 forbidden
<tych0> http://paste.ubuntu.com/7218034/
<Fishy_> whats it mean when I can't import boot images on a new install, and I get  "  File "/usr/lib/python2.7/dist-packages/formencode/schema.py", line 145, in _to_python     value_dict, state) Invalid: The input field 'username' was not expected."
<rvba> Fishy_: doesn't look good at all, could you please file a bug with the full stack trace, the version of MAAS you're using, the exact MAAS configuration, and what you've done to get that stacktrace?
<Fishy_> okay
<Fishy_> fresh install off CD
<Fishy_> https://bugs.launchpad.net/maas/+bug/1303935
<ubot5> Ubuntu bug 1303935 in MAAS "unable to import boot images in fresh install" [Undecided,New]
<rvba> Fishy_: ta.  I can't have a look at it right now but we will get back to you quickly.
<Fishy_> cool!
<Fishy_> im sure its me
<_bjorne> why im always get this answer in my access.log?!  200 is ok, 404 is error ----> GET /MAAS/metadata//2012-03-01/user-data HTTP/1.1" 404 200 "-" "Python-urllib/2.7
<tych0> hi smoser, what can you tell me about the new import script and tftp timeouts?
<tych0> it looks like my /var/lib/maas/tftp is totally empty, i assume it shouldn't be?
<smoser> that woudl seem bad.
<smoser> but it might be goign to ta different place.
<tych0> smoser: http://paste.ubuntu.com/7218450/
<smoser> tych0, that seems plausible
<tych0> smoser: ok, so that might work (?)
<tych0> i could bomb boot-resources and try again
<smoser> tych0, id' avhe to look closer, but generally it seems sane.
<smoser> i dont knwo about tftp timeouts though
<smoser> you ahve more info there?
<tych0> smoser: no, it pxe boots, gets an ip, and then never gets a kernel from tftp
<tych0> smoser: is there some more info i can collect somewhere?
<smoser> does it get the pxe config ?
<smoser> this is intel ?
<tych0> smoser: amd64, no, it doesn't get the pxe config
<tych0> PXE-E32: TFTP open timeout
<tych0> PXE-M0F: Exiting Intel Boot Agent.
<AskUbuntu> MAAS Controller & KVM Help | http://askubuntu.com/q/444648
<smoser> tych0, is the pserv running ?
<tych0> well
<tych0> i restarted it but i don't think it came up, actually
<tych0> sec
<tych0> heh...
<tych0> http://paste.ubuntu.com/7218525/
<tych0> upstart's maas-pserv.log
<smoser> tych0, is it crashing on a tftp request?
<smoser> or crashing just when run
<tych0> smoser: got it figure dout actually
<tych0> will file a bug shortly
<tych0> smoser: should i still expect things in tgt-admin --show?
<smoser> tych0, yes
<tych0> now iscsistart is timing out
<tych0> and there isn't anything there
<tych0> (in tgt-admin --show
<tych0> )
<Jeffrey_> Good afternoon, I am currently using MaaS 1.5 Trusty Thar and after a fast install using curtin on a node the server doesn't reboot. I was wondering if this is the expected action? I was using a previous MaaS 1.4 Saucy and after a fast install the machine would reboot and then be ready.
<smoser> console log is the most useful.
<smoser> if it as trusty ephemeral image
<smoser> then you will have /var/log/cloud-init-output.log
<smoser> and /var/log/cloud-init.log , looking for WARN will probably shoul you something
<Jeffrey_> smoser: Alright awesome thanks for your help! I'm going to go try some things now.
<allenap> tych0: How did you get on in the end?
<tych0> allenap: https://bugs.launchpad.net/maas/+bug/1302772 was what i was hitting
<ubot5`> Ubuntu bug 1302772 in MAAS "update of maas-cluster-controller on trusty dumps traceback and crashes" [Critical,In progress]
<allenap> tych0: Do you have a workaround for that?
<tych0> allenap: yeah, just delete that whole section from the config file
<allenap> tych0: Weâll have a fix for that in time for Trusty, so as long as you can bear it for now it should be fine.
<tych0> allenap: yep, that worked
<allenap> Tip top.
<lazyPower> looks like we have some new fun stuff on the horizon with import-pxe-files, i got an invalid key signature error
<lazyPower> http://paste.ubuntu.com/7218962/
<lazyPower> however, re-running the command completed successfully. Maybe a temporary hiccup
<tych0> lazyPower: those images probably aren't signed by the archive key
<lazyPower> its strange that re-running the command completed without issue. I think it was just a temporary hiccup?
<tych0> shoudl be signed by the key in ubuntu-cloudimage-keyring it hink
<lazyPower> because if its failing crc validation and bailing on the whole process, it should have repeated the same behavior
#maas 2014-04-08
<Kupo24z> hey all, trying 14.04 MAAS and getting this error when trying a pxe boot; Exception: {'__all__': [u'Node group interface with this Nodegroup and Interface already exists.']}
<Kupo24z> any idea?
<bigjools> Kupo24z: which log?
<Kupo24z> maas.log
<Kupo24z> looks like boot images are not importing either, similar error
<bigjools> can you paste the log please
<bigjools> and the pserv.log
<bigjools> and the cluster.log
<bigjools> are you on the latest revision 2202?
<Kupo24z> http://paste.ubuntu.com/7219582/
<Kupo24z> beta 2
<bigjools> what is the package version?
<bigjools> maas package
<bigjools> the time stamps do not match up on the logs for the operations you say they are doing
<bigjools> I think you have a cluster that is not accepted yet
<bigjools> what did you do leading up to this error?
<bigjools> upgrade? fresh install?
<Kupo24z> fresh install from beta 2 iso, updating apt right now
<bigjools> I tihnk the iso had a problem
<bigjools> packaged install from apt is OK
<Kupo24z> on reboot after update http://paste.ubuntu.com/7219609/
<Kupo24z> Version: 1.5+bzr2227-0ubuntu1
<Kupo24z> this is the output on import boot images: http://paste.ubuntu.com/7219621/
<Kupo24z> im assuming 'raised unexpected: AssertionError(u'MAAS_URL is not set.' is the cause
<Kupo24z> however in /etc/maas/maas_cluster.conf i can see it there
<bigjools> can you remove maas entirely and re-install from scratch from the archive please
<bigjools> apt-get purge '*maas*'
<bigjools> I don't trust the iso
<Kupo24z> I get E: Couldn't find any package by regex '*maas*' with that, syntax different?
<bigjools> argh
<bigjools> apt-get purge maas and then I think apt-get autoremove should get rid of the rest
<Kupo24z> does it require a maas user? django.db.utils.OperationalError: FATAL:  password authentication failed for user "maas"
<Kupo24z> http://paste.ubuntu.com/7219650/
<bigjools> urrrr
<bigjools> is this while purging?
<bigjools> roaksoax_: on the offchance you didn't actually go yet, can you look at this? --^
<bigjools> Kupo24z: is this while purging?
<diadistis> o/
<diadistis> Is it possible to use maas for servers that are not in the same subnet?
<bigjools> diadistis: yes, you need to install a cluster controller on the subnet
<bigjools> each subnet, I mean
<diadistis> The problem I'm facing right now is that we have about 20 dedicated servers in 12 subnets. I tried to use ipxe to boot them but no luck...
<bigjools> diadistis: http://maas.ubuntu.com/docs/cluster-configuration.html
<bigjools> rvba: have you seen bug 1304078
<ubot5> bug 1304078 in MAAS "Endpoint /MAAS/api/1.0/files/?op=list returns HTTP 500 with juju-core." [Undecided,New] https://launchpad.net/bugs/1304078
<rvba> bigjools: just saw it yeah.  I'll have a look now that https://code.launchpad.net/~rvb/maas/migr-bug-1302156/+merge/214667 is up for review.
<jtv> Speaking of reviews: I need a few!  One looks huge but is really just moving code.
<bigjools> btw folks, we don't need 14.10 milestones that have a 1.5 bugtask on 14.04
<bigjools> if it's fixed in 1.5 then it's fixed in trunk
<jtv> Assuming we backport from trunk to 1.5?  Because there was talk of doing it the other way around.
<bigjools> always backport
<bigjools> if we chop and change things will get *very* confusing very quickly
<jtv> OK
<jtv> Anybody free to review https://code.launchpad.net/~jtv/maas/split-boot_resources/+merge/214670 ?  It's really just moving code, no other changes.
<jtv> Although one obscure function moved "to nowhere."
<rvba> bigjools: couldn't reproduce the problem from https://bugs.launchpad.net/maas/+bug/1304078.  Will follow up when I get more details.
<ubot5> Ubuntu bug 1304078 in MAAS "Endpoint /MAAS/api/1.0/files/?op=list returns HTTP 500 with juju-core." [Undecided,Incomplete]
<bigjools> rvba: he's using an old version
<rvba> bigjools: no, just the cloud archive.
<rvba> On precise.
<bigjools> yes, an old version :)
<rvba> Well, precise is still supported.
<bigjools> and old!
<bigjools> :)
<rvba> okay :)
<bigjools> rvba: don't we have CI for that version in the lab?
 * rvba checks
 * bigjools stops to eat, back in a bit
<rvba> bigjools: no, what we test in the lab is whatever is in the daily PPA (i.e. the package built from 1.2)
<mwhudson> bigjools: btw i can finally try to break maas-on-arm tomorrow i think
<bigjools> rvba: urgh, I guess we should fix that
<bigjools> mwhudson: tip top!
<rvba> bigjools: we probably should.  I'll ask Diogo to do it.
<bigjools> rvba: thanks
<jtv> Any reviewers available for https://code.launchpad.net/~jtv/maas/split-boot_resources/+merge/214670 ?  It's a large diff, but it's all moving code, not changing it.
<strikov> jtv: Hi Jeroen. What's the idea behind make_image_spec() in tests? What's the problem with let say hardcoded arch and release? Thanks!
<jtv> strikov: it's a slightly controversial issue.  On the one hand, it's nice to have concrete human-readable strings in the test, and to have them look realistic.  On the other hand, tests should not pass "by accident."
<jtv> For example, if a test says "arch=i386" somewhere, it could be that it's hitting something that's broken for every architecture except i386, because that happens to be default somewhere else.
<jtv> Generally, with the factory style in our tests, we try to show that the behaviour we want has no implicit dependencies on other setup, configuration, defaults, etc.
<jtv> Any two items that a test creates are different and unrelated, unless there needs to be some specific connection â and then the test makes it explicitly.
<strikov> jtv: we're using release-XXXXXX and arch-XXXXXX generators right now, maybe it's better to stick with some more realistic value. But I got your point in general. Thanks!
<jtv> Those names are a compromise, really.
<jtv> You get random, but you also get recognisable.
<strikov> jtv: True
<rvba> gmb: jtv: The maas-test failure in the lab needs investigation http://paste.ubuntu.com/7220923/
<jtv> "Bad Request" *after* destroying the VM?
<rvba> jtv: the ordering of the messages is wrong.
<rvba> gmb: shouldn't you backport the HWE doc onto 1.5?
<rvba> (Looks like it's only in trunk.)
<jtv> rvba: I wonder if this means that we broke the interaction between the API client and the API somehow.
<jtv> Because that looks like the first API request that maas-test makes.
<jtv> Or, of course, we're just setting a value that is no longer in the config...
<jtv> Maybe we're setting an unsupported series?
<rvba> Yeah, that would be my guess too.
<jtv> Might be nice to dump the response body at that point in maas-test...
<rvba> jtv: I /think/ the change I just landed will fix the problemâ¦
<jtv> Ah good.
<jtv> I'll pick up one of those other maas-test bugs then.
<rvba> jtv: maas-test CI is still failing :/
<rvba> i.e. my change didn't fix the pb.
<jtv> rvba: what was the fix that didn't work?
<rvba> jtv: it's not the it didn't work.  I just didn't fix the CI problem (which I haven't diagnosed properly yet) https://code.launchpad.net/~rvb/maas-test/only-trusty/+merge/214312
<jtv> Oh, it was something you had already and hoped might _also_ fix the problem?
<jtv> AFAICT there is no real validation of the config value in that set_config call, is there?
<rvba> jtv: yes, I hoped it would fix the pb but it didn't.  The only validation is that it's a valid series.
<rvba> IIRC
<jtv> We validate that?  In the set_config call?
<jtv> I didn't think we did...
<jtv> I do remember making a change: I moved the commissioning series from the "networking" section of the config to the "Ubuntu" section.
<jtv> But that was only in the inline dict in get_default_config, I think â in which case it shouldn't matter, right?
<rvba> No, it shouldn't.
<jtv> I don't see any kind of validation of the value.
<jtv> The traceback also shows us that urllib2 will raise an exception when it gets an error code from the API...  the maas-test code only checks for a non-OK return value.
<jtv> Aren't we adding the server-side logs to the test details though?
<rvba> I don't see the logs anywhere.
<jtv> rvba: maybe that's because the error happens during setUp, and we don't gather the logs yet at that stage.  :/
<rvba> jtv: I'm debugging it the problem in the lab manuallyâ¦
<rvba> s/it//
<jtv> rvba: meanwhile I'll put up a branch that makes the fixture dump logs if it fails at this point.  It doesn't look very invasive.
<jtv> rvba: I do wonder if the RPC connection time is an issue for maas-test...
<jtv> rvba: https://code.launchpad.net/~jtv/maas-test/maasfixture-log-earlier/+merge/214718
<jtv>  â should help debug that problem
<rvba> jtv: yep, looks good.
<rvba> jtv: not sure it will help with our immediate pb though.
<jtv> It will activate the logging of server-side information before the fateful API request.
<jtv> So as long as the API logs the failure, we'll get it.
<jtv> But I do wonder: does maas-test wait for the cluster and region to hook up their RPC?
<rvba> I don't think the API will log a failure, it's a validation error.
<jtv> We don't know that.
<rvba> True, let's see.
<jtv> Yeah.
<jtv> Meanwhile, I have to call it a day.
<strikov> jtv: I want to come up with a test that generates pretty complex metadata (multiple versions inside the product, each with a specific label and set of subarches). I started to do it in a 'random fields' fashion (as you did TestMain) but feel that it's too much (i had to create a bunch of code to just generate this fields the right way). Any ideas which fields should be indeed random and which one I can hardcode?
<jtv> strikov: put the complexity into the unit tests, where it's still controllable.  Otherwise updating the test later becomes a nightmare.
<jtv> Factory methods can help a lot: "create an X for me with all the values randomised."
<jtv> The overall test will show that the parts fit together; the unit tests can put real stress on each of the parts.
<jtv> The trick for the tests is to hate whoever writes the code, and try to prove them Wrong in every way possible.  Even when that person is actually you.
<jtv> In other words, schizophrenia is one of the most valuable traits in software development.
<jtv> If you try to put that sort of thing in the big, end-to-end tests, it inevitably becomes a little arbitrary which corner cases the test does or doesn't exercise.
<jtv> With unit tests, it's easier to throw the real nightmares at the code.
<strikov> jtv: Just to make sure that I got you correctly. What do you mean by unit tests -- something which resides in src/provisioningserver/import_image/tests/?
<jtv> Well yes, but that's not the whole story.  :)
<jtv> I mean tests that take one small part of the software ("unit"!) and test it in detail, by calling it directly.
 * jtv has to go now
<jtv> strikov: for examples, have a look at the existing tests in src/provisioningserver/import_image/tests/, but specifically the tests for the lower-level functions, not the test for main().
<jtv> Good night!
<rvba> gmb: allenap: time for a tiny review? https://code.launchpad.net/~rvb/maas-test/maas-test-use-trusty/+merge/214751
<allenap> rvba: otp
<gmb> rvba: Sure
<gmb> That worked out well then :)
<allenap> rvba, gmb: roaksoax just reminded me that we need to ensure that maas-testâs changelog is up to date, and that each change since the last upload has a bug number attached. Do you know if thatâs the case?
<gmb> Er, nope.
<rvba> It's probably not the case.
<rvba> gmb: I wonder if you missed my message from earlierâ¦ shouldn't you backport the HWE documentation to 1.5?
<gmb> rvba: Yes, I think I missed that; had some connection problems with IRCâ¦
<gmb> rvba: Good point. Iâll do that now.
<rvba> Cool.
<allenap> rvba, gmb: Do either of you fancy doing it? :)
<rvba> allenap: I created a bug for the change I just landed.
<rvba> gmb: is it normal that the HWE doc isn't linked from the main index?
<gmb> rvba: Nope, thatâs an oversight. Iâll fix it.
<rvba> gmb: okay.  While you're at it, maybe add a note similar to the one we have in docs/networks.rst to state that this feature is new.
<gmb> Yep
<bladernr_> so... now that things have changed again (since the last time I updated my trust maas server) what do I edit to ONLY download trusty boot images (PXE and Ephemeral)
<bladernr_> is /etc/maas/import_pxe_files still valid (and /etc/maas/import_ephemerals) or is boot_resources.yaml the file now?
<bladernr_> err... bootresources.yaml
<roaksoax> bladernr_: bootresources.yaml from now on
<bladernr_> roaksoax: yeah, figured that out.  the old files shouldn't have been left if they're no longer honored, IMO... or at least should have been renamed to something like import_pxe_files.unused
<bladernr_> and just to be sure, it's safe now to delete /var/lib/maas/ephemeral? that would free up 20GB of disk space...
<bladernr_> I'm guessing yes but wanted to confirm to avoid hosing my server
<bladernr_> Under this new boot-resources scheme, how long are snapshot dirs kept?
<bladernr_> if I update daily, and pull in, say, 4GB per day of new images, if there's no garbage collection or whatever, I could quickly run out of disk space, depending on my maas server's setup
<allenap> bladernr_: You can delete snapshots as you like, just leave the one thatâs pointed to by the current symlink. The snapshots are created by hard-linking to files in the cache directory, so, even if you delete all snapshots, a sync should not need to download much, if anything.
<bladernr_> It does if I'm pulling in x86 and amd64 dailies for development... it's at least 12 images a day if trusty images are spun daily
<bladernr_> 3.5 - 4GB estimated per day, so if I have a cron set to update the images each morning, and no automated garbage collection, and forget cron is running, I could eat up 100GB in 25 days.
<bladernr_> I must admit though, I REALLY REALLY appreciate that the cluster now tells me exactly what images it has available
<bladernr_> there are some really great UI changes in the recent updates :D
<bladernr_> and that leads to another question about how these dirs are handled...  "current" points to the latest snapshot dir.  So lets say I'm pulling down Precise x86 and amd64 images, and trusty daily x86 and amd64 images.  Precise images won't be new each day, so the snapshot dir for today could have only trusty images in it.  Will the new method aggregate those dirs to allow me access to all of the available
<bladernr_> images?
<bladernr_> ok, curious...
<bladernr_> I added precise x86 and amd64 to bootresources.yaml and re-ran the import-pxe-files command.  I have a second snapshot that is 6.8GB vs 3.5 for trusty only.
<bladernr_> So, question is: did this copy my existing trusty stuff over, or re-download?  That would answer the above question about how existing stuff is handled.
<allenap> bladernr_: It should have hard-linked to the pre-existing images, so 3.5GB of the 6.8GB in the second snapshot should be the same on-disk data as the first.
<allenap> bladernr_: But if you discover otherwise, please file a bug.
<allenap> bladernr_: Btw, glad to hear you like some of the new stuff :) Unfortunately, for now, youâll have to arrange garbage collection yourself.
<smoser> allenap, are you sure?
<smoser> what did you mean.
<smoser> i think it should clean up after itself.
<allenap> smoser: I looked at the code in MAAS and I didnât see any clean-up. Is it in simplestreams?
<smoser> bladernr_, "current" is current for everything. they get munged into that dir.
<smoser> i believe the sync is done with max=1
<smoser> er... wait. thats not relevant.
<smoser> i thought that it only kept 2 thigns.
<smoser> i was pretty sure that oleg did that.
<smoser> if not then its a critical bug.
<allenap> smoser: Thereâs only one snapshot in the Garage MAAS, so maybe it is cleaning up after all.
<allenap> Oleg doesnât seem to be around today to ask.
<allenap> Or heâs EODed.
<smoser> allenap, and du should not be tricked by hard links.
<smoser> it should count correctly.
<allenap> smoser: Aye, but `du snapshot-1` and `du snapshot-2` run separately will sum up to more than `du snapshot-[12]`.
<smoser> and in both cases its counting is correct :)
<roaksoax> bladernr_: should be. Please do file bugs for all that stuff you are finding
<bladernr_> smoser, allenap thanks, just double checked and it is indeed hardlinking to the older items... (the hard links threw me, I'm so used to everyone using symlinks for that type of work)
<tych0> hi allenap, so r.e. calling the celery job
<tych0> i am getting a 403, http://paste.ubuntu.com/7223235/
<tych0> looking at the code, the nodegroup is the only one allowed to call that celery task?
<allenap> tych0: That sounds about right. Do you have access to those credentials?
<bladernr_> Is there any documentation, beyond a couple VERY brief blog posts I've managed to find, that explains in good detail the various options and ways to modify the fast-path install via curtin_userdata?
<bladernr_> I have a working d-i preseed in maas that I now want to translate into cloud-init-isms and have found bits related to ec2 cloud-config that I'm not sure work in MAAS...
<bladernr_> good example I haven't found yet, I can add a PPA (thanks to smoser's blog), but not sure how to do things like update apt cache, then install individual packages after passing things to debconf-set-selections
<bladernr_> Oh.. so this seems to be working a lot easier than I was thinking it was going to.  Not sure what I was doing wrong before, but adding in things line by line and re-doing the install to see the progress seems to be working well thus far.
<bigjools> bladernr_: if you collect useful info can you please let me know and I will add it to the maas docs
#maas 2014-04-09
<Kupo24z> There a way to edit tags without maas-cli?
<Kupo24z> maas-cli maas tag update-nodes juju add="node-3004a5ec-bf71-11e3-9d94-52540051bc11" results in "Not Found"
<jtv> Kupo24z: looks like the wrong command line.  I haven't done much with tags, so give me a moment to check
<Kupo24z> Got it from https://maas.ubuntu.com/docs/tags.html
<Kupo24z> ah, i think its 'tags new' first
<Kupo24z> yup that did it
<jtv> Yeah, we have this pattern where the plural acts more or less like a class, and the singular is for addressing objects.
<jtv> Creating an object is something you do on the class, basically.
<Kupo24z> Can you add multiple tags in one line?
<jtv> No.
<Kupo24z> jtv: is it possible to add a tag to a node by hostname or is it only system id?
<jtv> Only by system ID.  It's basically a node's identifying key.
<jtv> Hostnames can be changed, so you see the can of worms there...
<Kupo24z> hmm okay
<Kupo24z> trying to make this somewhat automated in a script
<jtv1> bigjools: got time for a pre-implementation chat?
<bigjools> jtv: yes
<jtv> talky?
<bigjools> yarp
<bigjools> jtv: fuxache
<bigjools> jtv: there's no option in talky to select which camera/mic I need to use
<bigjools> plus, trusty has broken my usb devices
<jtv> Ah.
<jtv> Well, maybe just here on IRC then?
<jtv> Providing your keyboard works?
<jtv> Branch up for review: https://code.launchpad.net/~jtv/maas-test/copy-file/+merge/214879
<bigjools> jtv: looking
<jtv> Thanks.
<bigjools> jtv: how can you have two symbols both called make_file in test_maasfixture.py?
<jtv> bigjools: one is just a convenience wrapper for the other.
<jtv> They mean the same thing.
<jtv> It's just that one is self.make_file() and the other is make_file(self).
<jtv> I can remove the wrapper, but it was easier to leave it.
<bigjools> yeah get rid of it :)
<jtv> It's easier now anyway â doing it before the review would just have polluted the diff.
<bigjools> kk
<rvba> jtv: Actually, I diagnose the first problem before running things with your change :)
<rvba> diagnosed*
<jtv> :(
<rvba> jtv: It was, indeed, a validation error.
<rvba> jtv: trying to debug the second maas-test problem now.
<jtv> The only thing in the logs that struck me as particularly suspicious was the login failure.
<jtv> I'm going out for a bit.
<rvba> bigjools: btw, when will we change 'daily' into 'release' for the Trusty image label in etc/maas/bootresources.yaml.  It's a bit of a chicken and egg problem unless the 'release' images get published a bit before the release.
<bigjools> rvba: we have to do it for the last upload
<bigjools> ie probably tomorrow
<bigjools> check with andres
<rvba> Okay.
<bigjools> it's not chicken and egg :)
<rvba> Depends when the images are published really.
<rvba> jtv: btw, there is no reason why we should run maas-import-pxe-files manually in maas-test, as opposed to using the API.
<jtv> Maybe one:
<rvba> I might fix that as a drive-by if I manage to fix my pb quickly.
<jtv> Running the script manually makes it slightly easier to write the bootresources.yaml.
<jtv> Because we can just pass it on the command line.
<jtv> Please don't change that while I'm working on this bug.
<jtv> We can look at it again later, but it's not urgent.
<rvba> Right.  But we could also simply overwrite the config file in /etc/maas/
<jtv> Slightly harder.
<jtv> We can, but then we need a sudo et.c
<jtv> Instead of a plain scp.
<rvba> Definitely not urgent.  But this is actually related to my problem: the problem I'm dealing with now is that the boot images are not reported in time *because* we're calling the script manually.
<jtv> Ahhh
<rvba> i.e. with the API, the images would have been reported at the end of the import phase.
<jtv> I Right.
<jtv> Right.
<rvba> But since this is all asynchronous, I have to poll for the boot images anyway.
<jtv> We _could_ just jack up the frequency of that celery job...  It's not going to be very costly, and 5 minutes was completely arbitrary as I recall.
<rvba> I do think 5 minutes is too long indeedâ¦ but to avoid a race condition, we have to wait until the boot images are there anywayâ¦
<jtv> Yup.
<rvba> Because we can't predict how long it will take for the import script to run.
<jtv> How did we deal with that previously?  I forget.
<rvba> We didn't have to deal with it really, because the reporting was just a nice-to-have, not a crucial part of the infrastructure.
<jtv> Oh, but as long as we're running the script manually, it won't complete until the import is done anyway, right?
<rvba> Yes
<jtv> If we jack up the frequency to twice per minute, then waiting for a minute after the script completes would solve the CI problem to all intents and purposes, right?
<rvba> Before all the bootresources work, the images being there was the only requirement.  Now we need them on the cluster and we need them reported back to the region.
<rvba> Yes, that would solve the pb.
<jtv> Just as a quick hack of course â as you say, in the end we must poll on BootImage.
<rvba> The branch I'm testing now wait 5 minutes after the import script. (It's just a test to confirm my hypothesis)
<rvba> waits*
<jtv> Five minutes plus overhead, I guess.  For those corner cases.
<rvba> Like I said, it's just a test.
<jtv> Sure.
<rvba> Node is being powered upâ¦ let's see what happens.
<rvba> jtv: gmb: btw, the decision to return 'no-such-image' as part of the pxe url when MAAS can't find a suitable image is one of those little things that make debugging so much easier.  Thanks for that!
<jtv> It was him.
 * rvba thanks him.
<rvba> Node enlisted okay this time.
<rvba> Okay, working on the polling stuff now.
<rvba> jtv: success! (with sleep(5*60) after the import script has run)
<jtv> Phew.
<jtv> Something else maas-test may need: subarch!  It doesn't do that yet, does it?
<jtv> Oh wait, it does, it does.
<rvba> Phew.
<jtv> It's just still hidden inside the arch string.
<jtv> There is some yuckiness going on with the additional i386 import, too.
<rvba> jtv: I have trouble running the tests for maas-test http://paste.ubuntu.com/7225462/ The failure looks familiar but I can't remember what the pb wasâ¦ can you?
<jtv> rvba: could tox be one of those packages that maas-test needs installed but maas needs un-installed?
<rvba> jtv: arg, that was it (but it wasn't tox, just python-api-client)
<rvba> Thanks.
<rvba> Any reviewer available for a fix to a critical issue? https://code.launchpad.net/~rvb/maas-test/import-images-api/+merge/214913
<jtv> rvba: if it's short, I can do it â but then you'll have to review and Q/A https://code.launchpad.net/~jtv/maas-test/bootresources-config/+merge/214916 :)
<rvba> jtv: deal :)
<jtv> Reviewing...
<rvba> jtv: as far as I can tell, the change you're proposing won't allow us to configure the boot resources to get, say, the 'daily' images for a release.  Wouldn't be simpler to let the user pass the entire bootresources.yaml file to maas-test?
<jtv> Simpler for us, yes.  But the UX was vetoed.  I figured it's easy to add label to this later.
<rvba> jtv: "But the UX was vetoed." what do you mean by that?
<jtv> I mean that Julian immediately and resolutely said "no" when I listed it among the options.
<jtv> Your branch has been reviewed.
<rvba> All right.
<rvba> Ta.
<rvba> I think it goes a bit against maas-test being just a simple tool to drive MAAS itselfâ¦ but okay.
<rvba> jtv: I'm fixing my branch (as per your review).  Then I'd like you to merge trunk into your branch so that I can actually QA it.
<jtv> There goes my plan to leave on time...
<rvba> jtv: I can create another branch from your branch and merge trunk myself.  No worries.
<jtv> Thanks!
<jtv> Although I probably have myself to blame for being such a picky reviewer...
<rvba> heh
<jtv> Good night everyone!
<rvba> allenap: I'd welcome your opinion on [1] in https://code.launchpad.net/~jtv/maas-test/bootresources-config/+merge/214916
<allenap> rvba: Okay, Iâll take a look.
<allenap> rvba: I think bootresources.yaml is different to power parameters. The latter have a number of schemas associated with them. Trying to flatten that into a command-line is nearly impossible.
<rvba> allenap: my suggestion is to pass the entire file content to maas-test.
<rvba> All at once.
<allenap> rvba: bootresources.yaml will be transient, but we can use capabilities to detect when we should use its successor.
<rvba> allenap: maas-test --bootresources <file>
<allenap> rvba: Would that be optional?
<rvba> allenap: yes, of course
<allenap> rvba: Whatâs the purpose?
<rvba> allenap: customize the boot image import: use a different label, use a different path, etc
<allenap> rvba: I imagine we still need the code in this branch when itâs not supplied?
<rvba> allenap: no, we can use the default one.
<allenap> rvba: Does that import everything? Using the default one makes sense - weâre trying to test how hardware works with MAAS out-of-the-box - but if itâs really slow then folk are going to tire of it.
<allenap> rvba: This is pertinent w.r.t. the âdirectiveâ we had about default-to-everything.
<rvba> allenap: It imports [i386,amd64]/release/precise [i386/amd64]/daily/trusty by default.
<allenap> rvba: Is that MAASâs default, or maas-testâs?
<rvba> MAAS's default
<allenap> biab
<allenap> rvba: When we transition away from bootresources.yaml, what will we do with maas-test then?
<allenap> gah, biab.
<rvba> allenap: maybe we won't transition away from bootresources.yaml.  Maybe the region will simply generate an ad-hoc bootresources.yaml every time the import script it run.
<rvba> allenap: and if we do get away with it, then that's one more reason no to spend time getting maas-test capable of writing that file.
<allenap> rvba: Either way, bootresources.yaml is an implementation detail, temporarily exposed to users while we scurry to provide API+UI for it. Jeroen has written the code to generate it. I think we should use it for now. I suspect weâll have to change maas-test again in any case.
<rvba> allenap: well, I don't agree but I guess I'm outnumbered :)
<rvba> allenap: bootresources.yaml being an implementation detail should be yet another reason not to spend time working on code to generate it.  We should expose it to user temporarily to give them maximum control over what gets imported.  And change that when MAAS itself changes.
<allenap> rvba: I think we can revisit this at some point. In the meantime I think jtvâs branch is an improvement, and is okay to land.
<rvba> allenap: we won't be able to offer a unified interface in maas-test anyway.
<rvba> allenap: well, apart from the fact that it doesn't work at all.
<allenap> rvba: Doesnât it?
<rvba> allenap: see my point [0]
<allenap> rvba: Oh yes :)
<rvba> allenap: yet another reason why fiddling with bootresources.yaml is, I think, a bit pointless.  Oh well
<allenap> rvba: Given that the work has been done already I donât think we can argue anymore to not do the work ;)
<rvba> allenap: if it was working, I'd say you're right.
<allenap> rvba: I donât feel passionately about this, so maybe Iâm missing something.
<allenap> rvba: I donât think this code is incompatible with adding a âboot-resources-config flag later on.
<rvba> allenap: it is not, but why duplicate the work?  That's all I'm asking.
<allenap> rvba: We canât unduplicate the work now. This is an improvement regardless, and itâs done (Iâm assuming fixing it is a small thing). I also think this makes the out-of-the-box experience of maas-test better.
<rvba> allenap: gmb: It's been a long battle, but I'm happy to report that the CI job for maas-test is now green.
<allenap> \o/
<rvba> allenap: I agree.  But adding the --bootresources would solve the bug this work is fixing and much more with ~10x less code.
<allenap> rvba: It wouldnât make the `apt-get install maas-test; maas-test â¦` experience better though. Itâs not a massive amount of code either.
<rvba> allenap: it would definitely make it better, because using your own bootresources.yaml file, you could do exactly what you want, and for instance limit the number of images much better.
<gmb> rvba: Sweet!
<allenap> rvba: How many people who want to test hardware compatibility with Ubuntu and/or MAAS (remember that MAAS compatibility is important to general Ubuntu Server compatibility now) are going to have a bootresources.yaml lying around? Afaict, this makes the experience better without having to think.
<rvba> allenap: my point is simply that I don't think it's worth it.  Use the default bootresources.yaml in most case, otherwise, let the user do as he pleases by providing his own bootresources.yaml.  This solution is something is the middle that is, I think, wasted effort.
<smoser> bladernr_, ping
<bladernr_> smoser: hello
<smoser> so fast path install doc is bad. agreed.
<smoser> :)
<smoser> one question as to why you're wanting to use it.
<allenap> rvba: It will save something now, and even more if/when (when most likely) we default to downloading everything.
<smoser> rather than user-data.
<bladernr_> heh I've patched together about 1/3 of the solution sof ar
<smoser> i suspect i can probably help you through the rest.
<allenap> rvba: Even if this is wasted effort (I donât think it is, fwiw), it canât be unwasted now.
<bladernr_> truth be told, I don't know exactly WHERE to put this stuff, I was putting it in the install late_command just because that's where it is in d-i and what the limited docs I could find indicated
<smoser> so how do you deploy nodes?
<smoser> via juju ?
<bladernr_> no, purely via maas
<smoser> perfect
<smoser> then just use user-data
<smoser> and cloud-init/cloud-config syntax there.
<bladernr_> either d-i or FPI if I can get FPI to install the test tools automatically
<smoser> only do in the install environment what you need.
<bladernr_> where's user-data?
<smoser> then your user-data stuff is install-path agnostic
<smoser> and will also work on ec2 or wherever else you can talk to cloud-init.
<smoser> (getting user-data info)
<smoser> bladernr_, http://bazaar.launchpad.net/~virtual-maasers/+junk/maas-libvirt-utils/view/head:/maas-deploy-node
<rvba> allenap: can't be unwasted.  Let's see how much time it takes to fix this branch and QA it.
<smoser> thats my 'deploy-node'. which takes a ubuntu release and user-data.
<smoser> but it shoudl tell you what you need to do on the api.
<smoser> essentially, you just pass 'user_data=BASE_64_DATA_HERE' on your 'start' call
<smoser> that user-data can be anything that cloud-init understands.
<smoser> which is described partially at
<smoser>  https://help.ubuntu.com/community/CloudInit
<smoser> and then examples and doc of cloud-config options are at
<smoser> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt
<allenap> rvba: Heh, yes, thatâs a fair point.
<smoser> but the dead simplist thing to do is just give a '#!' script to it, and it will be executed on first boot at rc.local-like time frame.
<bladernr_> Ahhh... yeah, I was wondering about that.  and you can pass the script in via user_data= ?? (like user_data=`base64 myscript`)
<bladernr_> or is that more encoding the actual keypairs instead?
<allenap> rvba: Okay, as this is not likely to make it into Trusty anyway, and weâre busy enough as it is, letâs put it on hold and discuss it in Austin?
<rvba> allenap: well, my main point being that is was a wasted effort, like you said, if Jeroen can get it done quickly, then fine.  But I suspect we will have to do the bootresources thing anyway.
<rvba> allenap: Julian apparently explicitly said he was against adding a --bootresources option.  That's what I'm fighting against.
<smoser> bladernr_, like you said there. user_data=`base64 myscrtip`
<allenap> rvba: I donât know what Julian said, but Iâm not thrilled about adding it either. It depends somewhat on how you see maas-test. I see it as a front-end for non-MAAS users to test hardware with MAAS. As such, I donât think asking them to provide config files is good UI.
<bladernr_> smoser: awesome.  thanks!
<rvba> allenap: I guess it depends the kind of polish we want to apply to maas-test.
<allenap> rvba: I think this is ripe for discussion face-to-face in Austin though. If nothing else it takes the heat off right now.
<rvba> allenap: yeah, agreed.
<rvba> allenap: any idea about https://bugs.launchpad.net/maas/+bug/1305061 ?  Looks related to the RPC stuff but it's not clean why 'power_type' isn't there at all.
<ubot5> Ubuntu bug 1305061 in MAAS "maas crashes because of a missing power_type, even though I provided one" [Undecided,New]
<rvba> tych0: do you have shell access to the machine where you saw https://bugs.launchpad.net/maas/+bug/1305061 ?
<allenap> rvba: tych0 figured it out; reload the bug report.
<allenap> rvba: Itâs because pserv wasnât running; it had crashed because of another bug :)
<allenap> However, the error was not helpful.
<rvba> allenap: ah right, I didn't reload the page.
<allenap> rvba: It should probably have said âI canât contact any clusters to validate thisâ or something like that.
<rvba> allenap: definitely
<jtv> rvba: I think I've found the reason for the problem with my maas-test branch...  It's that the default simplestreams path (as encoded in provisioningserver/config.py) never got the v2 data!
<allenap> jtv: Is this an âoh s**tâ moment?
<jtv> I would say so, yes.
<jtv> But nothing that a small, simple patch won't solve.
<rvba> jtv: right, the default value of the 'path'.
<jtv> It doesn't have the -v2 bit in it...
<rvba> indeed
<rvba> jtv: that would explain why the import script failed with a KeyError on 'subarches' :).
<jtv> Of course it also raises the question of whether the repo path should be a command-line option to maas-test.  But one thing at a time.
<jtv> Yeah, it's nothing whatsoever to do with the subarches in my code.
<jtv> It's a field in the simplestreams data â v2, but not regular.
<rvba> Yep
<rvba> roaksoax: https://code.launchpad.net/~andreserl/maas-test/release_bzr126/+merge/204040 is obsolete now right?
<jtv> rvba: https://code.launchpad.net/~jtv/maas/bug-1305118/+merge/214966
<jtv> Of course we'll also want either a configurable path, or dailies by default, in maas-test.  But that's a separate issue.
<rvba> Right.
<rvba> Looks good.
<rvba> jtv: that's precisely with I'm advocating for a general-purpose --boot-resources option.
<jtv> I know, I know... but bear in mind we're aiming to replace that config altogether.
<jtv> Thanks for the very quick review btw.  :)
<rvba> Quick fix â quick review :)
<jtv> I'll also backport to 1.5.
<roaksoax> rvba: that should have been emrged :)
<rvba> roaksoax: I know, but gmb's changes make this obsolete nowâ¦ correct?
<roaksoax> rvba:hcecking
<roaksoax> rvba: yes!
<vladk> rvba: https://codereview.appspot.com/86070043 - gomaasapi TestServer extensions required for juju-core testing
<rvba> vladk: looking
<vladk> rvba: thanks
<fader> Hey folks, is there any documentation anywhere on authenticating against the REST API?
<fader> I can use it properly from a web browser if I have logged into MAAS interactively already, but if I haven't logged in or try from a script I get something like "Unrecognised signature: GET list"
<fader> Seems to be similar to: http://askubuntu.com/questions/402691/handling-ubuntu-maas-restful-api-login (and not covered that I see in the API docs)
<Kupo24z> hey all, getting this error when booting via PXE: exceptions.AssertionError: No PXE template found in u'/etc/maas/templates/pxe'!
<Kupo24z> odd because it worked yesterday
<Kupo24z> and the dir is populated: http://paste.ubuntu.com/7227453/
<Kupo24z> hmm, reran pxe import script and it fixed it somehow
<tych0> hi rvba, allenap: what is the DJANGO_SETTINGS_MODULE for maas?
<tych0> ah ha, maas.settings
<bladernr_> hey, can someone catch me up on the state of uEFI support in MAAS?
#maas 2014-04-10
<jtv> bigjools: we can just make maas-test import from the daily images and ignore the releases repo, right?
<bigjools> jtv: hmm good question
<bigjools> I would say both, but default to release
<jtv> Maybe we can have a chat about this?
<mwhudson> hm
<mwhudson> how do you configure maas-dns?
<jtv> mwhudson: maas generates the dns config using a template (in /etc/maas/templates IIRC)
<jtv> So you edit the template.
<mwhudson> hm
<mwhudson> what i want to do is tell it where to forward most requests to
<mwhudson> like e.g. "python.org"
<jtv> Ah, that's already a thing.
<jtv> For some quantity of thing.  Let me look.
<mwhudson> i don't know much about configuring dns
<jtv> So what you want to set is the âupstreamâ DNS, for all requests for hostnames not managed by the MAAS, right?
<mwhudson> yes
<jtv> There's a UI setting for that.  Look for "upstream DNS."
<mwhudson> oh UI
<mwhudson> i wonder why the UI isn't responding
<jtv> At all..?
<mwhudson> just hanging
<mwhudson> bet it turns out to be a firewall
<jtv> Then why did it work before though?  Maybe a big ongoing upgrade?
<mwhudson> hm?
<mwhudson> it's never worked for me
<mwhudson> on this install
<mwhudson> which is a day old
<bigjools> you can set it via the API too, it's just a config item
<mwhudson> ah ok i think the api not working was a stale ip address
<mwhudson> shouldn't maas createadmin prompt for a password?
<bigjools> here we go again :)
<bigjools> createsuperuser does
<mwhudson> or maybe the docs should be fixed, if it's that sigh-worthy :)
<bigjools> people keep asking for one and then the other
<bigjools> one is django's command, one is our wrapper
<mwhudson> bigjools: http://maas.ubuntu.com/docs/install.html#create-a-superuser-account seems to be just wrong (for trusty anyway i guess?)
<bigjools> yeah the docs will be updated when 1.5 is released
<bigjools> and we'll have docs for each supported release, at last
<bigjools> separate docs I mena
<bigjools> mean
<mwhudson> i don't see a setting for dns in the ui :/
<mwhudson> oh that will be nice
<bigjools> it's on the config page somewhere
<mwhudson> this maas install seems less fresh than i thought it was :/
<bigjools> heh
<bigjools> 2230 is latest trusty
<mwhudson> is it possible that this maas doesn't think it's managing dns?
<mwhudson> 1.4+bzr1693+dfsg-0ubuntu2.2
<mwhudson> ok that's ancient?
<bigjools> mwhudson: ancient!
<mwhudson> ffs
<bigjools> that's cloud-tools or saucy's version
<bigjools> only about 500 revision behind
<mwhudson> oh
<mwhudson> this vm is saucy
<mwhudson> ffs
<mwhudson> anti-progress: the dns server i want to forward to does not, in fact, appear to be listening to me
<bigjools> winning
<bigjools> jtv: is there anything else in your branch that needs attention?
<bigjools> I will approve it
<jtv> I hit a different problem in Q/A; part that worked before.  May just be my experimental change.
<jtv> I always knew the uploading of the file would be the hard and risky part, but why did it work when RaphaÃ«l tried it?
<bigjools> jtv: what goes wrong?
<jtv> Oh, I see it now.  The scp command.
<bigjools> jtv: let me guess, quoting?
<jtv> No, just a missing username/host prefix.
<jtv> I guess RaphaÃ«l fixed that up in his experiment.
<bigjools> ahah
<jtv> Yup, that seems to work.
<jtv> I'll try another Q/A run.
<jtv> Hmm... images are imported just fine now (and according to spec), but RaphaÃ«l's new poll-until-images-are-imported code hits a timeout.
<jtv> So report_boot_images is not working in some way.
<jtv> Or maybe it's just genuinely taking too long.
<jtv> Ah, wouldn't surprise me â he switched over from running the import script to triggering a run from the API.
<jtv> The script doesn't return until the import is done, and from there all we need to wait for is for report_boot_images to run.
<jtv> But when we call the API for importing images, it returns immediately â and so what we're waiting for is completion of the import itself.
<jtv> (No longer report_boot_images, because the API-triggered task runs that right after the import).
<jtv> The timeout is 10 minutes, IIRC, which is fine for the report_boot_images cycle â but maybe not for the import.
<bigjools> jtv: so, is it working or not? :)
<jtv> Not yet, not yet!
<jtv> Can't wait to have some hardware for this stuff...
<jtv> No, no, the change that triggers the API version of the imports doesn't seem to have landed yet...
<jtv> Ahhh, found the cause: chmod.
<jtv> Another easy fix.
<jtv> My branch just passed the enlist-a-node test.
<jtv> \o/  Test successful.  Landing.
<jtv> bigjools, is this what you had in mind?  https://code.launchpad.net/~jtv/maas-test/daily-option/+merge/215088
<bigjools> jtv: boolean params always pique my interest
<bigjools> they are nearly always better replaced with some sort of enumerated value
<jtv> Very true, but it's the UI choice that matters here.
<bigjools> --image-type=
<jtv> What happens under the bonnet can be changed easily.
<bigjools> ?
<bigjools> and default to "release"
<jtv> ?
<bigjools> then it stays a little looser
<jtv> I have similar misgivings about calling things types of things.  There are usually different aspects that you could call types.
<bigjools> ok
<jtv> This option is just a shortcut for an alternate config...  easier to improve once a real pattern forms.
<bigjools> it was a rough suggestion, I'm open to options
<bigjools> you *could* just take a whole simplestreams path
<jtv> Yeah, but it's a lot more work for the user.  I figured that could be a next step in making it more flexible â if we need it.
<bigjools> but remember that this API needs to stick after bootresources is gone
<jtv> I see that as a reason to keep the UI as simple as possible: keeps it easy to change the whole implementation, even if we may later have to build a more flexible, more complicated way of doing the same thing.
<jtv> Not hard to say "you can't specify --daily-images and a custom path" later, if/when we add an option for the latter.
<bigjools> the mass-test UI would have to change if a new "type" was introduced
<bigjools> it would not have to change in maas
<bigjools> see my point?
<jtv> Wait... what's the connection to maas?
<jtv> I mean, maas would never know about any of this anyway.
<bigjools> maas itself just cares about the url to the index
<bigjools> "path" in the config
<jtv> Yes, that's what I mean.
<bigjools> it knows nothing about dailies/release
<bigjools> I think maas-test should be the same
<jtv> And that's the way I like it.
<bigjools> me too
<jtv> We can do that, but getting the right URL has been a bit of a pain in the past.
<jtv> You know: "I have a URL to an index listing here, but how many path components do I need to strip off to get the URL that simplestreams wants?"
<bigjools> my suggestion is to default the whole URL and allow knowledgeable users to override as they want
<bigjools> dailies won't get used much after release, everyone will want to know if trusty works on their hardware
<jtv> Okay.  It's an easy change â I just figured it was hard on the users.
<bigjools> I would normally agree but I think the frequency of using this option will be limited to power users
<jtv> What should I call the option then?  --image-stream?
<bigjools> --image-stream-url
<bigjools> ?
<jtv> OK
<bigjools> cool, thanks
<jtv> rvba: if you want to use the API for starting the import job, that'll work now â but don't forget that the timeout for the BootImage records to appear will then have to cover the import time, not the report_boot_images interval.
<rvba> jtv: not sure it's worth doing right now tbh.  It's a cleanup that can be done later.
<jtv> OK, just a thing to keep in mind.
<rvba> Yeah.
<jtv> Because 10 minutes is a long, long time for the report_boot_images schedule... but not a lot of time to import images!
<rvba> A very useful cleanup would be to avoid downloading the i386 images when it's not necessary.
<rvba> Maybe I'll fix that.
<jtv> That'd be great â look for "mipf" in the function name, in utils.py IIRC.
<rvba> allenap: bigjools: jtv: gmb: just a reminder (in case I forget): just before the release we want to change the label of the Trusty images from 'daily' to 'release'.
<jtv> That's what says "oh you asked for armhf?  I'll give you armhf/generic and throw in i386/generic as well."
<rvba> I know.
<jtv> Change the label?  Of already imported images you mean!?
<rvba> No, the label for Trusty in /etc/maas/bootresources.yaml.
<jtv> So Scott is going to throw the switch?
<rvba> We probably need to get confirmation from him that the 'release' images for Trusty have been published.
<jtv> Since AFAIR _all_ the images in the daily stream were labelled "daily," shouldn't we just use label "*"?  Saves us worrying about synchronicity.
<rvba> Doesn't make a great difference.  We would still have to change the 'path.'
<jtv> Is he going to change that as well!?
<jtv> ISTM we can just put trusty under the "releases" source.
<jtv> And just leave the label as *.
<jtv> ISTM we can do that before the upstream data changes, with no ill effects.
<bigjools> rvba: we need to change that ASAP well before the FF.  If there's a problem with images then we just ask someone to put images in release.
<bigjools> did that make sense?
<rvba> bigjools: I just checked and it seems the 'release' images for Trusty are already there.
<bigjools> \o/
<bigjools> JFDI then
 * gmb -> getting breakfast; bbiab
<rvba> Yep.
<rvba> JFDoingI
<bigjools> o/
<allenap> rvba, jtv: https://code.launchpad.net/~allenap/maas/dhcp-leases-parsing/+merge/215112 is my work-in-progress for speeding up lease parsing.
<allenap> It uses a regex to identify records, then it select only the latest ones, then it uses the full parser to break those apart.
<allenap> It saves a lot of work when the leases file is large.
<rvba> bigjools: btw, the upcoming (still waiting for the RT ticket to go through âhint, hint) api doc page has a toc: compare http://people.canonical.com/~rvb/maas-docs/api.html with http://maas.ubuntu.com/docs/api.html
<jtv> allenap: that's very little code indeed...  not sure what it does yet.
<bigjools> rvba: can you go and pester them again for the RT please
<bigjools> rvba: and the toc is a nice improvement, thanks
<rvba> bigjools: we got a response on the RT, just no estimation of when it will be done.  I'll ask them about that.
<bigjools> rvba: ok, thanks
<rvba> Done.
<jtv> rvba: did you want to make the change to how/where we import trusty?
<jtv> If not, I can propose a quick branch.
<rvba> jtv: I have a branch already.  I'm testing a package built from it right now.
<rvba> jtv: https://code.launchpad.net/~rvb/maas/use-release-trusty-resources/+merge/215114 WIP until I get confirmation that it's working as expected.
<jtv> Why not just move the "trusty" selection under the other source?
<jtv> I'm currently setting up for an import with that config btw.
<rvba> jtv: yes, that would be even a bit simpler.  Fixing the branch now.
<jtv> Oh dear.  Import fails while trying to write the meta file: snapshot directory does not exist!
<jtv> I have a horrible feeling we haven't been getting any new dailies for a while, and so failed to notice some problem or other...
<rvba> uh-oh
<jtv> Just filed it as bug 1305758
<ubot5> bug 1305758 in MAAS "Import fails while writing maas.meta: No such file or directory" [Critical,Triaged] https://launchpad.net/bugs/1305758
<jtv> Oh, another possibility I guess would be that there is simply nothing to download, and that this gets handled particularly badly in some cases.
<rvba> jtv: the import doesn't seem to work now.  I only got the precise image.
<jtv> Any tracebacks?
<rvba> No, no traceback.
<jtv> Spooky.
<rvba> Like you said, maybe there is nothing to download.  Although the images seem to be there.
<jtv> Probably identical to versions we already had...
<jtv> And I don't see anything that would create that snapshot directory if there was nothing to download.
<jtv> The code would try to write that maas.meta file, but the directory wouldn't exist.
<jtv> I seem to remember that this was always a weakness in the code, actually.
<rvba> jtv: the images seem to be there but clearly, the index file doesn't contain an entry for Trusty/release.
<jtv> Maybe because the same file was already in there as Trusty/daily?
<rvba> jtv: I guess I'll wait for smoser to come online and ask him about that.
<jtv> Wow.  Latest images I have in cache are from March 31.
<jtv> Uh-oh.  Deleting everything from /var/lib/boot-resources doesn't fix the problem either.
<jtv> And it fails suspiciously quickly â within a second.
<jtv> Maybe because it's hitting the caching proxy.
<rvba> pdb time :)
<jtv> When I put the daily trusty import back in (in addition to the release trusty) it seems to get going again.
<jtv> But of course maybe it's just slower to fail because I made it download stuff.
<jtv> I'm expecting to be called out soon.  May not have time to say so.
<rvba> jtv: when importing (with the updated config) from a freshly installed package, I don't get a traceback.
<jtv> !?
<rvba> Only precise gets imported.  but no traceback.
<jtv> Then I guess it may be getting confused because the same images are in different streams with different metadata...
<jtv> Although then why did it keep failing for me when I deleted my cache & snapshots..?
<rvba> I doubt that's the problem; like I said, there is no reference to Trusty/release in the index.
<jtv> Oh, there still isn't?
<jtv> Ah yes, see that.
<rvba> No.  Again: the images seem to be there but there is no reference to them in the index.
<jtv> So then the import procedure wouldn't find them...  I think.
<rvba> That's the behavior I see.
<rvba> Doesn't explain the bug you're seeing though.
<jtv> But the behaviour you're getting sounds completely correct under the circumstances, so maybe it's just something weird in my setup.
<jtv> After the ongoing import I'll try re-running it, and if that doesn't reproduce the problem, I'll try re-running but without the daily trusty source.
<rvba> k
<rvba> But like you said, this part of the code seems a bit fragile.  I'd be relieved if we could get to the bottom of this.
<jtv> That's exactly why I'm trying to reproduce the problem.
<jtv> Can't promise that it'll work.  :(
<jtv> Ahhh, I've reproduced the traceback.
<jtv> By commenting out the "daily" source.
<jtv> Ah!  Maybe I understand why!
<jtv> The snapshot directory gets created, "en passant" as it were, when <something> is downloaded from the simplestreams repo.  Not sure what exactly, but no downloads means no snapshot directory.
<jtv> But then.
<jtv> (Good thing I recently refactored this code â otherwise I wouldn't have understood it)
<jtv> Then, the import code generates a yaml dump for the metadata it has downloaded from the repo, _in memory_, and compares it to what's in /var/lib/maas/boot-resources/current/maas.meta
<jtv> If the two do not match, then something has changed, and so the import code decides that the new snapshot directory is worth keeping.
<jtv> It writes a new maas.meta file in that snapshot directory.
<jtv> Which, oops, does not exist because all that happened is that things disappeared.
<jtv> I think the sensible thing to do is to create the snapshot directory.  Assuming the rest of the code behaves sensibly.
<jtv> Oh dear.  The story just got weirder.
<jtv> The metadata dict is empty.
<jtv> That means that no matching products were found.
<jtv> Bother.  All this time wasted on what is probably a syntax error.  I don't like yaml.
<rvba> smoser: around?
<rvba> jtv: gmb: allenap: is one of you taking care of https://code.launchpad.net/~andreserl/maas/third_party_drivers/+merge/215065 ?
<jtv> Not me, sorry!
<allenap> rvba: Yeah, I was looking at it, but Iâm not going to be able to review it until at least 1900 UTC.
<rvba> allenap: I've written the tests.
<allenap> roaksoax: ^ is that going to be too late.
<allenap> rvba: \o/
<rvba> allenap: I'm taking care of it unless gmb wants to review it :)
<allenap> rvba: If gmbâs not around I think a selfie might be in order.
<rvba> allenap: that's the plan
<roaksoax> allenap: nope, we have until EOD today
<roaksoax> allenap: i'll be pushing the release team toapprove this too while jhobbs finishes up some changes
<roaksoax> allenap: all the hardcodede stuff (where the pPA is and stuff needs to go on a config file)
<rvba> roaksoax: btw, we'd like to land https://code.launchpad.net/~rvb/maas/use-release-trusty-resources/+merge/215114
<rvba> But it seems the images for Trusty/release are not included in the index file yet.
<rvba> The simplestreams index that is.
<roaksoax> rvba: so it would fail?
<roaksoax> rvba: maas-improt-pxe-files would fail?
<rvba> roaksoax: it would not fail for it would only import precise's images.
<rvba> s/for/but/
<roaksoax> rvba: so there's something weird
<roaksoax> rvba: http://paste.ubuntu.com/7230893/
<roaksoax> rvba: and it that diff I see: arches: ["i386", "amd64"]
<rvba> roaksoax: what's weird?
<rvba> roaksoax: the config file gets rewrittenâ¦ but it's semantically the same.
<roaksoax> rvba: ok
<roaksoax> rvba: so, i'm thikning that sicne there no release for trusty yet
<roaksoax> rvba: we could sru this, or tryu to get it post today?
<rvba> roaksoax: SRU works for me.  It's a bit of a chicken and egg problem.
<roaksoax> yeah
<rvba> bigjools: see ;) ^
<roaksoax> rvba: https://code.launchpad.net/~andreserl/maas/third_party_drivers_1.5/+merge/215185
<rvba> roaksoax: approved (you can usually self-review simple backports)
<roaksoax> rvba: thanks :)
<roaksoax> rvba: it does nee dot be manually uploaed right?
<rvba> smoser: when are the Trusty/release images going to be available in the simplestreams index on http://maas.ubuntu.com/images/ephemeral-v2/releases/ ?  i.e. should we land https://code.launchpad.net/~rvb/maas/use-release-trusty-resources/+merge/215114 as an SRU?
<roaksoax> rvba: don't lanmd anything to 1.5 please
<rvba> roaksoax: well, I'm not landing this unless the images are there, that's for sure.
<roaksoax> rvba: thganks
<fader> Hey folks, is there any documentation anywhere on authenticating against the REST API?
<fader> I can use it properly from a web browser if I have logged into MAAS interactively already, but if I haven't logged in or try from a script I get something like "Unrecognised signature: GET list"
<fader> Seems to be similar to: http://askubuntu.com/questions/402691/handling-ubuntu-maas-restful-api-login (and not covered that I see in the API docs)
<rvba> fader: Hi, I just posted a reply to that question on askubuntu.com.  Although we know the documentation is a bit poor in this area, the example Python code should be you started.
<rvba> fader: note that, if you're using Python, you can use the client library directly.
<fader> rvba: Thanks, I'll take a look!  (Don't shoot me but I was planning to do it from PHP via its built-in URL grabbing as a prototype)
<fader> I'm just trying to build a page that shows the status of multiple MAAS clusters as a proof-of-concept, nothing that will really be in production
<tych0> hi smoser, roaksoax, it looks like maas defaults to syncing the daily ephemerals as well as the release versions
<tych0> is that the way we are going to release it?
<rvba> tych0: That was my question to smoser :).  We've got https://code.launchpad.net/~rvb/maas/use-release-trusty-resources/+merge/215114 ready to land.  But we're waiting on simplestreams having the right data.
<tych0> oh, i see
<tych0> rvba: yeah, cool
<smoser> rvba, ?
<tych0> rvba: so one thing i don't understand about that diff, can we not specify two releases in the same keyring path?
<smoser> oh. i see.
<smoser> i'd land it.
<rvba> tych0: that's exactly what that branch does. The diff is a bit messed up.
<tych0> or maybe a question better for smoser
<smoser> well you're not going to have something labeled release until ... after release.
<tych0> rvba: ah, ok
<tych0> rvba: i am not that good at reading diffs :-)
<smoser> so that would put you in the realm of SRU
<rvba> smoser: okay, so I guess we will SRU this
<rvba> tych0: this diff is particularly nasty
<tych0> :-)
<smoser> suck.
<smoser> alright. so lets figure something out here.
<smoser> i'll try to get something itnto daily today.
<rvba> tych0: here is the file http://paste.ubuntu.com/7231245/
<smoser> and we can test that, and then i think i'm willing to call somethinng release in this single case.
<smoser> but we could also possibly call it "rc" or something
<rvba> smoser: it's a bit of a chicken and egg problem.
<smoser> and you allwo the label "rc"
<smoser> label rc|release
<rvba> smoser: that would work
<tych0> rvba: cool, that's what i was thinking
<smoser> i dont think its terrible either. and actually, since you have (poorly) only 'trusty' in that list, then its safe in the future.
<smoser> i really dont like that you've only extended the number of places with hard coded release names though.
<rvba> Not sure what you're talking about.
<smoser> 'trusty'
<smoser> you'll never see 'urban' (of 'urban unicorn')
<smoser> when it would be better if you started pulling those things in (or at least allowed for that) when said unicorn was 'release' or 'rc'
<smoser> maas should not have a database of ubuntu names.
<smoser> thats what i'm complaining about.
<rvba> I see.  This is a long-standing bug.
<smoser> yes. and this config file extended the number of places where naems are typed.
<smoser> i will work today
<smoser> and try to get daily updated.
<rvba> This file replaces two other files with these names in it.  So technically, it's one step into the right direction.
<smoser> rvba, thats good.
<smoser> *and* its user editable config
<smoser> rather than source code
<smoser> :)
<smoser> i'll get daily updated today. and we'll get that tested and then will promote a trusty to 'rc'
<smoser> and then you can land that patch tomorrow
<rvba> See, there is your silver lining.
<rvba> smoser: okay, please send an email to a maas ML when it's done.  Julian will probably be able to test and land the change to bootresources.yaml
#maas 2014-04-11
<jtv> Ohhhh WHAT?  Test failure while landing?  I tested locally!
<jtv> Rabbit.
<jtv> maasserver.tests.test_rabbit.TestRabbitBase.test_base_channel_creates_exchange
<jtv> Timeout.
<jtv> bigjools: is that related to what you just debugged with Scott?
<bigjools> jtv: no
<bigjools> random
<bigjools> not seen that for a long time
<jtv>                     {cannot_listen,{127,0,0,1},59471,eaddrinuse}}},
<jtv> That seems to be the nub of it.
<bigjools> yeah
<bigjools> nub
<jtv> I guess it was just an unlucky choice of port... retrying.
<jtv> Oh dear. And an error in simplestreams.
<jtv> bigjools: should I backport my fix for the inscrutable-import-error bug to 1.5?  Or is there no point now?
<bigjools> jtv: no point IMO
<jtv> OK
<bigjools> downgrade the bug from panic status
<jtv> Done.
<jtv> That error in the simplestreams went away, but now I'm getting one about an unexpected sha256 checksum.
<bigjools> jtv: I expect the mirror might still be running
<bigjools> which prompts another question ...
<jtv> Same exception again.  That makes it hard to do full Q/A.
<bigjools> jtv: worked here
<jtv> hmmm
<bigjools> if we have a label of "rc" is anything going to bork?
<bigjools> IOW did we rely on  "release" anywhere?
<rvba> bigjools: I think it will work just fine.
<rvba> We were using 'daily' before.
 * bigjools likes the optimism
<rvba> bigjools: the node failed to boot in the lab.
<rvba> :/
<bigjools> shit
<rvba> 'No such image'
 * rvba investigates
<rvba> â¦
<bigjools> rvba: is it hard-coded anywhere?
<bigjools> in the tests
<rvba> bigjools: no, the test just want an image for Trusty.  Again, it was working with the 'daily' images.
<rvba> bigjools: no Trusty image was imported.
<rvba> I just see the precise images.
<bigjools> rvba: are the tests using the default config?
 * rvba checks
<bigjools> I imported trusty "rc" ok on a new install
<rvba> yes (http://paste.ubuntu.com/7233732/ that's the config from the lab)
<rvba> /var/lib/maas/boot-resources/ contains only the precise images.
<rvba> bigjools: I don't see any reference to 'rc' images in http://maas.ubuntu.com/images/ephemeral-v2/releases/streams/v1/com.ubuntu.maas:v2:download.json
<rvba> What am I missing?
<bigjools> WFM, so, WTH
 * rvba tries on canonistack
<bigjools> could be a mirroring problem
<jtv> I do see "rc" in the sjson.
<jtv> Oh, that's in the regular json too.
<bigjools> jtv: I don't see it!
<bigjools>  "updated": "Fri, 11 Apr 2014 00:45:23 +0000",
<rvba> bigjools: arg, I was looking at a ached version of the json
<rvba> Now I see it too
<rvba> cached*
<rvba> bigjools: maybe that's what happened in the lab too
<jtv> Science: âI'll believe it when I see it.â  Religion: âI'll see it when I believe it.â
<jtv> Sounds as if maybe the caching headers on the index are set to cache too aggressively.
<rvba>  "updated": "Fri, 11 Apr 2014 00:45:23 +0000",
<rvba>  "products": {
<rvba>   "com.ubuntu.maas:v2:boot:14.04:armhf:generic-lpae": {
<rvba>    "label": "rc",
<jtv> Maybe the http headers were designed for etags, then had the etags removed or not implemented?
<bigjools> oh see it now
<bigjools> rvba: the lab will work once it can import the right image then :)
<rvba> bigjools: trying to clear the cache nowâ¦
<rvba> The cached data in the proxy that is.
<jtv> I got a checksum error, but disabling imports of the "rc" label seems to get me past it.
<rvba> bigjools: my run on a canonistack machine imported the 'rc' images all right. (Same as what you saw.)
<bigjools> jtv, rvba: I suspect proxies are screwing things over
<rvba> Yep
<rvba> Investigating that now
<rvba> Arg, I don't have permission to clear the cache on the proxy machine.
<bigjools> rvba: I do know that it worked in the Garage MAAS come to think of it
<bigjools> not this exact package but the rc data worked IIRC
<rvba> Okay
<rvba> Would be good to get an end-to-end test to pass though.
<rvba> But I'm not too worried.
<bigjools> k
<jtv> I would suspect the configuration or the original httpd more than the proxies.
<jtv> For example, if the directory with the index is set up for aggressive caching because they look like they only have static files...
<rvba> What's weird is that when I wget the index in the lab (using the same proxy the test script uses), I get the right index with the references to the 'rc' images.
<jtv> Well, the headers from the httpd say what caching is _allowed_.  After that, every proxy or client gets to decide to what extent it wants to use that.
 * jtv hates the quagmire of over-aggressive proxies
<jtv> There is no more objective reality in that situation.
<rvba> Running the int. tests manuallyâ¦
<rvba> If maas-import-pxe-files was a bit more verbose, that would helpâ¦
<rvba> bigjools: importing the images in the lab without going through the proxy.  It's going to take time, but we will have our answer.
<bigjools> rvba: ok
<bigjools> rvba: need to get the proxy fixed then if it's aggressively caching like that
<rvba> Yeah
<rvba> I'll need Diogo to help me with that cause I don't have permissions to manipulate the proxy.
<rvba> Import done.
<rvba> 'rc' images are there.
<rvba> Running the rest of the test nowâ¦
<rvba> allenap: time for a tiny review? https://code.launchpad.net/~rvb/maas/show-version-doc/+merge/215377
<gmb> rvba, allenap: How can I find out why maas-dhcp-server wonât start for me? `sudo service maas-dhcp-server-start` just give me âmaas-dhcp-server stop/waitingâ.
<rvba> gmb: upstart log/syslog
<gmb> Gah!
<gmb> rvba: Thanks. Forgot about upstart log. syslog is silent on the issue.
<rvba> gmb: the question you just asked should go into the FAQ.
<gmb> Hmm: â/var/lib/maas/dhcpd-interfaces does not exist.  Abortingâ
<gmb> rvba: Agreed.
<gmb> Will take care of it.
<rvba> Great, thanks.
<allenap> rvba: How about a bzipped normal review? Ha. Now Iâm scraping the bottom of the barrel in a different way :)
<rvba> allenap: thanks for the review
<rvba> allenap: gmb: could one of you have a look at bug 1306303 please?  I'm still trying to figure out this proxy problem.
<ubot5> bug 1306303 in MAAS "Enlistment fails with "400 BAD REQUEST" in logs" [Undecided,New] https://launchpad.net/bugs/1306303
<allenap> rvba: I might not be able to do it until much later, but sure.
<dimitern> allenap, ping
<rvba> gmb: found another gaping hole in the documentation (since you seem to be in a writing frenzy): the commissioning phase doesn't seem to be described anywhere.  Nothing tells you that you have access to the commissioning scripts' results for instance.
<d_`> Hi MAAS people, I really like the idea of MAAS, but I already have chef instead of juju. what is the relative difficulty of using not juju to configure servers when deploying with MAAS?
<rvba> d_`: juju is just a client of MAAS.  MAAS is pretty agnostic in this regard.  It just provisions servers and hands them over to clients.
<rvba> d_`: in other words, you shouldn't have trouble using Chef with MAAS.
<d_`> rvba: thanks for the quick reply, that's really encouraging. I think I'm going to set up a lab today
<d_`> rvba: since you have a canonical masked host, do you know what's up with the 14.04 RC? why it's not out?
<rvba> d_`: no idea, sorry.
<rvba> d_`: you might want to ask around in #ubuntu-release.
<d_`> rvba: haha, no problem. thanks for the quick answers
#maas 2014-04-13
<Jeffrey> Is there anyway to configure curtin's partitioning?
<Valduare> hows it going guys
<Valduare> have you seen the minnowboard-max ?
<Valduare> dual core atom with couple gigs of ram on board size of a raspberry pi
<Valduare> intel says the board can support up to 8 gigs of ram and quad core atom
<Valduare> thatâd be fun for MaaS to play with a bunch of those
<mwhudson> hm
 * mwhudson still can't seem to get maas to do dns
<mwhudson> root@pricklypear01:~# named-checkconf
<mwhudson> /etc/bind/named.conf.options:3: open: /etc/bind/maas/named.conf.options.inside.maas: file not found
<mwhudson> bigjools: are you awake yet
 * mwhudson disappears for a bit anyway
#maas 2015-04-06
<mup> Bug #1440763 was opened: 1.8b1 regiond.log Tracebacks when trying to deploy 42 nodes at a time <isolation> <MAAS:Triaged> <https://launchpad.net/bugs/1440763>
<mup> Bug #1440765 was opened: 1.8b1         oauth.oauth.OAuthError:  <isolation> <MAAS:Triaged> <https://launchpad.net/bugs/1440765>
<mup> Bug #1440823 was opened: Using both MAC address fields in AMT config causes AMT Power to fail <MAAS:New> <https://launchpad.net/bugs/1440823>
<saltlake> Hi,
<saltlake> I am working with maas and HO servers for the first time and I was able to see a "node" recognized on the maas server but wanted to know what the "power" settings for the node need to be ? The error I have right now is that "The node does not have apowere type"
<roaksoax> saltlake: do your nodes have an IPMI bmc?
<saltlake> roaksoax : Yes
<roaksoax> saltlake: and how was the node recognized by MAAS?
<roaksoax> saltlake: if you commission the node (even if you power it on manually), it should automatically configure the power parameters
<saltlake> roaksoax : But I have not setup or done anything with them ..I setup Network boot option for the node and rebooted it. I see the MAC addresses look different than what they were in linux
<roaksoax> that doesn't make any sense
<roaksoax> how would the mac address be different?
<roaksoax> saltlake: so if the node pxe booted from maas and registered itself into MAAS, automatically
<saltlake> Not sure maybe I mistaken.. but looks like it ..
<roaksoax> MAAS should have configured IPMI and updated the parameters automatically
<saltlake> roaksoax : the sttus on the maas page says "commissioning" for the node but there is a red error on top of the page that says "Doens not have a power type etc.. " I could manually reboot the node again to see if it makes a difference
<roaksoax> saltlake: yeah, reboot the node, make sure it PXE boots
<roaksoax> saltlake: and let it do the commissioning
<roaksoax> it should fix the power parameters
<saltlake> roaksoax : I aborted the commissioning and restarted commission... is there a way to see what is going on on that node ?
<roaksoax> saltlake: you'd have to setup console logging
<roaksoax> saltlake: and look at it directly
<saltlake> ok.. I have not tried that .. do you know how long it might take for a server to get commissioned ?
<roaksoax> saltlake: depends, no more than 10 mins
<roaksoax> i'd think
<saltlake> Right now the node log syas this "INFO  1 minute ago    Node changed status â From 'New' to 'Commissioning' "
<roaksoax> depends on how fast is the server, how long it takes to do POST, etc
<saltlake> Ok.. I'd give it 20 min and then reboot it physically
<saltlake> I mean hard reset it
<roaksoax> saltlake: Right. If the Node was in New state, and there were *no* power parameters configured, that means that when maas changed the status to 'Commissioning', it was unable to power on the node
<roaksoax> saltlake: because it cannot control is power
<roaksoax> saltlake: so, you need to force a reboot, physically
<saltlake> ok..
<roaksoax> or via IPMI if you have that
<saltlake> ok .. do I delete this node from maas before poering it on ?
<roaksoax> saltlake: no
<saltlake> ok
<roaksoax> saltlake: just reboot it, and make sure it PXE boots from MAAS
<roaksoax> saltlake: that should make it run the commissioning environment
<roaksoax> that *should* allow BMC discovery
<saltlake> roaksoax : "INFO        0 minutes ago   PXE Request â commissioning " This is a good sign right ?
<roaksoax> saltlake: yes
<saltlake> roaksoax : Unfortunately it failed comissioning thanks to this error on "failed [3/7] (00-maas-03-install-lldpd, 99-maas-01-wait-for-lldpd, 99-maas-02-capture-lldp)" How would I go about this now ?
<roaksoax> saltlake: check the logs and see what failed?
<saltlake> roaksoax : Finally the node went from commissioning to Ready.. I think that is a good sign!!
<roaksoax> saltlake: did the power paramters get added automatically?
<saltlake> roaksoax : Though the message continues to appear if I ignore the powere parameters.. it eventually commissions!!
<saltlake> roaksoax : BY message I mean the intimidating red message complaining about power parameters on the maas page
<saltlake> roaksoax : the power type in the node is still "--" though the status is ready.. should I be worried about that ?
<saltlake> roaksoax : Ok I have concluded that the power type -- is NOT a good thing since maas cannot control the node.
<saltlake> am now researching how to setup ipmi on these dl360 serers
<saltlake> ok has anyone used a DL360 server and know how to set the power type parametrs for the respective node ?
<saltlake> I think givev the boot screen for the node says it supports ILO 2 I think the power parameter should "Moonshot HP ILO chassis manager". Does nayone know how to get this setup ?
<mup> Bug #1440894 was opened: get_effective_power_parameters() - exceptions.AttributeError: 'unicode' object has no attribute 'copy' <MAAS:New> <https://launchpad.net/bugs/1440894>
<mup> Bug #1434257 was opened: MAAS should set dnssec-validation to no in /etc/bind/named.conf.options <MAAS:Triaged> <maas (Ubuntu):New> <https://launchpad.net/bugs/1434257>
#maas 2015-04-07
<thetrav> how do I set my MaaS nodes to automatically execute a script on start up?
<thetrav> this is the nodes managed by MaaS, not the region/cluster controllers
<mup> Bug #1252768 changed: removing (including with --purge) fails on pg script <MAAS:New> <maas (Ubuntu):New> <https://launchpad.net/bugs/1252768>
<mup> Bug #1252768 was opened: removing (including with --purge) fails on pg script <MAAS:New> <maas (Ubuntu):New> <https://launchpad.net/bugs/1252768>
<mup> Bug #1252768 changed: removing (including with --purge) fails on pg script <MAAS:New> <maas (Ubuntu):New> <https://launchpad.net/bugs/1252768>
<mup> Bug #1440994 was opened: maas api "device read <hostname>" returns HTML 404  <api> <juju-net> <robustness> <MAAS:New> <https://launchpad.net/bugs/1440994>
<mup> Bug #1440996 was opened: maas api "device create" exists but is not documented. <api> <doc> <juju-net> <MAAS:New> <https://launchpad.net/bugs/1440996>
<mup> Bug #1440998 was opened: maas api "device update <id>" requires setting parent= in addition to hostname=, but it's not documented as required <api> <doc> <juju-net> <MAAS:New> <https://launchpad.net/bugs/1440998>
<mup> Bug #1441002 was opened: maas api "device set-sticky-ip-address" fails with "500: 'bool' object has not attribute 'uuid'". <api> <juju-net> <robustness> <MAAS:New> <https://launchpad.net/bugs/1441002>
<mup> Bug #1440894 changed: get_effective_power_parameters() - exceptions.AttributeError: 'unicode' object has no attribute 'copy' <MAAS:New> <https://launchpad.net/bugs/1440894>
<mup> Bug #1441013 was opened: maas api "device claim-sticky-ip-address" does not allocate an address when there are existing IPs assigned <api> <juju-net> <robustness> <MAAS:New> <https://launchpad.net/bugs/1441013>
<mup> Bug #1441018 was opened: maas api "device release-sticky-ip-address" could use a better error message <api> <confusing-ui> <doc> <juju-net> <MAAS:New> <https://launchpad.net/bugs/1441018>
<dimitern> rvba, hey there
<rvba> \o dimitern
<dimitern> rvba, as you've probably noticed I've tested the 1.8-alpha10 devices support and filed a bunch of bugs
<rvba> dimitern: yes, going through them nowâ¦
<dimitern> rvba, cheers
<rvba> Thanks dimitern!
<dimitern> rvba, as a general feedback - it looks much more stable than initially :)
<rvba> dimitern: cool ;)
<dimitern> rvba, what I couldn't quite get is how will the devices work with ipaddresses - I mean claim-sticky-ip is one option, but I was thinking of using ipaddresses reserve and then set-sticky-ip-address with it (to better fit in our addressable containers workflow)
<rvba> dimitern: you don't need to reserve the IP and then claim it for the device: just one call to claim-sticky-ip should be enough.
<rvba> dimitern: also, don't use set-sticky-ip-address.  Just use claim-sticky-ip-address.
<dimitern> rvba, is the effect the same? the allocated IP will show as "Static IP" wrt IP Assignement and come from the static range?
<rvba> dimitern: we will remove set-sticky-ip-address since claim-sticky-ip-address does exactly the same thing as set-sticky-ip-address when you pass an explicit IP address.
<rvba> dimitern: yes
<dimitern> rvba, ok, so we'll change juju to use claim-sticky-ip-address for containers instead of ipaddresses reserve, once the 1.8 release is in trusty
<rvba> dimitern: sounds good.
<dimitern> rvba, or that won't happen before october?
<rvba> dimitern: I'm not sure about the timing tbh.  roaksoax will know.
<dimitern> rvba, ok, we'll chat on the interlock today
<rvba> k
<mup> Bug #1441021 was opened: maas api "ipaddresses release" unhelpful success message; bad error message on invalid <api> <confusing-ui> <doc> <juju-net> <MAAS:New> <https://launchpad.net/bugs/1441021>
<mup> Bug #1441133 was opened: MAAS version not exposed over the API <api> <MAAS:Triaged> <https://launchpad.net/bugs/1441133>
<mup> Bug #1441159 was opened: devices web UI is not updating (need to refresh) <confusing-ui> <dashboard> <juu-core> <MAAS:New> <https://launchpad.net/bugs/1441159>
<mup> Bug #1441160 was opened: maas should allow comment on why a system is broken <MAAS:Triaged> <https://launchpad.net/bugs/1441160>
<mup> Bug #1440994 changed: maas api "device read <hostname>" returns HTML 404  <api> <juju-net> <robustness> <MAAS:Invalid> <https://launchpad.net/bugs/1440994>
<mup> Bug #1441211 was opened: 1.8b1 Node remains clicked in the main page after accessing node details page <MAAS:Triaged> <https://launchpad.net/bugs/1441211>
<mup> Bug #1441211 changed: 1.8b1 Node remains clicked in the main page after accessing node details page <MAAS:Triaged> <https://launchpad.net/bugs/1441211>
<mup> Bug #1441211 was opened: 1.8b1 Node remains clicked in the main page after accessing node details page <confusing-ui> <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1441211>
<saltlake> champs , does anyone have experience with HP proliant servers ? My maas server is unable to control HP server nodes since it is unable to determine the power parameters for those servers. Those servers have ILO2 on them (as displayed on the boot up screen) But I have no idea how and what powere paamaters to set for these HP proliant nodes in their maas configuration
<saltlake> I just need a pointer on how to set the power parameters for these HP dl360 G6 nodes.
<mup> Bug #1441211 changed: 1.8b1 Node remains clicked in the main page after accessing node details page <confusing-ui> <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1441211>
#maas 2015-04-08
<thetrav> is this channel logged?
<thetrav> 1 -> is there a mechanism for running an arbitrary script on node start-up (eg, user-data)
<thetrav> 2 -> what are MaaS physical zone's all about?
<thetrav> 3 -> what causes a node to move from "deploying" state to the next successful state?  I've got ssh access to the host and so far as I can tell it's all fine, however it sits in "deploying" for a super long time then moves to "deploy failed" even though the server seems fine
<mup> Bug #1441399 was opened: socket.error: [Errno 92] Protocol not available <oil> <MAAS:In Progress by andreserl> <https://launchpad.net/bugs/1441399>
<mup> Bug #1441403 was opened: 1.8b1 Filter by zone is missing <MAAS:Triaged> <https://launchpad.net/bugs/1441403>
<mup> Bug #1441404 was opened: 1.8b1 Accessing nodes detail page gets stuck in Loading <MAAS:Triaged> <https://launchpad.net/bugs/1441404>
<mup> Bug #1441405 was opened: PXE power-off instead of power controller <MAAS:New> <https://launchpad.net/bugs/1441405>
<mup> Bug #1441408 was opened: 1.8b1 Failed Commissioning Machines are not turned off automatically after they timeout <oil> <MAAS:Triaged> <https://launchpad.net/bugs/1441408>
<mup> Bug #1418157 changed: Install failed: Unexpected EOF in archive <MAAS:Expired> <https://launchpad.net/bugs/1418157>
<mup> Bug #1441467 was opened: Adding a node in the UI requires specifying a power controller <MAAS:New> <https://launchpad.net/bugs/1441467>
<mup> Bug #1441471 was opened: MAAS python-vmomi power type: can't "add chassis" twice <MAAS:Triaged by mpontillo> <https://launchpad.net/bugs/1441471>
<mup> Bug #1441467 changed: Adding a node in the UI requires specifying a power controller <MAAS:New> <https://launchpad.net/bugs/1441467>
<mup> Bug #1441471 changed: MAAS python-vmomi power type: can't "add chassis" twice <MAAS:Triaged by mpontillo> <https://launchpad.net/bugs/1441471>
<mup> Bug #1441467 was opened: Adding a node in the UI requires specifying a power controller <MAAS:New> <https://launchpad.net/bugs/1441467>
<mup> Bug #1441471 was opened: MAAS python-vmomi power type: can't "add chassis" twice <MAAS:Triaged by mpontillo> <https://launchpad.net/bugs/1441471>
<mup> Bug #1441472 was opened: mass-cli "nodes new" command: autodetect_nodegroup parameter is undocumented <api> <doc> <MAAS:Triaged> <https://launchpad.net/bugs/1441472>
<mup> Bug #1441472 changed: mass-cli "nodes new" command: autodetect_nodegroup parameter is undocumented <api> <doc> <MAAS:Triaged> <https://launchpad.net/bugs/1441472>
<mup> Bug #1441472 was opened: mass-cli "nodes new" command: autodetect_nodegroup parameter is undocumented <api> <doc> <MAAS:Triaged> <https://launchpad.net/bugs/1441472>
<mup> Bug #1441497 was opened: DNS in deployed nodes not set correctly <MAAS:New> <https://launchpad.net/bugs/1441497>
<mup> Bug #1441497 changed: DNS in deployed nodes not set correctly <MAAS:New> <https://launchpad.net/bugs/1441497>
<mup> Bug #1441497 was opened: DNS in deployed nodes not set correctly <MAAS:New> <https://launchpad.net/bugs/1441497>
<mup> Bug #1441467 changed: Adding a node in the UI requires specifying a power controller <MAAS:Invalid> <https://launchpad.net/bugs/1441467>
<mup> Bug #1441606 was opened: Error: Page not found The requested URL /MAAS/nodes/ was not found on this server. <MAAS:New> <https://launchpad.net/bugs/1441606>
<mup> Bug #1441610 was opened: 1.8b1 Machines get stuck in releasing for a long time <oil> <MAAS:Triaged> <https://launchpad.net/bugs/1441610>
<mup> Bug #1441612 was opened: 1.8b1 Red outline on node name  <ui> <MAAS:New> <https://launchpad.net/bugs/1441612>
<mup> Bug #1441612 changed: 1.8b1 Red outline on node name  <ui> <MAAS:New> <https://launchpad.net/bugs/1441612>
<mup> Bug #1441612 was opened: 1.8b1 Red outline on node name  <ui> <MAAS:In Progress by blake-rouse> <https://launchpad.net/bugs/1441612>
<mup> Bug #1441621 was opened: 1.8b1 Padding between edit node name and save button <ui> <MAAS:New for ricgard> <https://launchpad.net/bugs/1441621>
<mup> Bug #1441624 was opened: MAAS doesn't support using an upstream proxy <landscape> <MAAS:Triaged> <https://launchpad.net/bugs/1441624>
<mup> Bug #1441652 was opened: 1.8b1: 502 Proxy Error when trying to access MAAS in browser <oil> <MAAS:New> <https://launchpad.net/bugs/1441652>
<mup> Bug #1441653 was opened: 1.8 V1: juju bootstrap failed - got error back from server: 502 Proxy Error <oil> <MAAS:New> <https://launchpad.net/bugs/1441653>
<mup> Bug #1441653 changed: 1.8 V1: juju bootstrap failed - got error back from server: 502 Proxy Error <oil> <MAAS:New> <https://launchpad.net/bugs/1441653>
<mup> Bug #1441682 was opened: 1.8beta1: RAM units is given as GB on node details page, instead of GiB <oil> <MAAS:New> <https://launchpad.net/bugs/1441682>
<mup> Bug #1441684 was opened: Add test for SO_REUSEPORT and add warning log if kernel does not support it <tech-debt> <MAAS:Triaged> <https://launchpad.net/bugs/1441684>
<mup> Bug #1441686 was opened: 1.8beta1: Storage sizes displayed as floating point <MAAS:New> <https://launchpad.net/bugs/1441686>
<mup> Bug #1441684 changed: Add test for SO_REUSEPORT and add warning log if kernel does not support it <tech-debt> <MAAS:Triaged> <https://launchpad.net/bugs/1441684>
<mup> Bug #1441686 changed: 1.8beta1: Storage sizes displayed as floating point <MAAS:New> <https://launchpad.net/bugs/1441686>
<mup> Bug #1441684 was opened: Add test for SO_REUSEPORT and add warning log if kernel does not support it <tech-debt> <MAAS:Triaged> <https://launchpad.net/bugs/1441684>
<mup> Bug #1441686 was opened: 1.8beta1: Storage sizes displayed as floating point <MAAS:New> <https://launchpad.net/bugs/1441686>
<mup> Bug #1441756 was opened: Manager service is not sending limit to region <ui> <MAAS:In Progress by blake-rouse> <https://launchpad.net/bugs/1441756>
<mup> Bug #1441756 changed: Manager service is not sending limit to region <ui> <MAAS:In Progress by blake-rouse> <https://launchpad.net/bugs/1441756>
<mup> Bug #1441756 was opened: Manager service is not sending limit to region <ui> <MAAS:In Progress by blake-rouse> <https://launchpad.net/bugs/1441756>
<serverascode> hi, how can I assign static IPs to servers, aka mac addresses? I want to manually assign them...anyone have pointers on doing that with maas?
<roaksoax> serverascode: only available in MAAS 1.7 or 1.8b1+
<roaksoax> serverascode: maas admin node claim-sticky-ip-address
<roaksoax> serverascode: maas admin node claim-sticky-ip-address --help
<serverascode> ok cool thanks will chekc that out
<mup> Bug #1441837 was opened: [1.8b1 devices] Can't add a device with multiple NIC's <oil> <MAAS:Confirmed> <https://launchpad.net/bugs/1441837>
<mup> Bug #1441841 was opened: [1.8b1 devices] Can't add a device that has IP address that it is within the wider range MAAS manages, but not within Dynamic/Static range MAAS manages <oil> <MAAS:Triaged> <https://launchpad.net/bugs/1441841>
<mup> Bug #1441851 was opened: 1.8b1: Can't view list of nodes for a physical zone <oil> <MAAS:New> <https://launchpad.net/bugs/1441851>
<mup> Bug #1441851 changed: 1.8b1: Can't view list of nodes for a physical zone <oil> <MAAS:New> <https://launchpad.net/bugs/1441851>
<mup> Bug #1436277 changed: No error message when the websocket connection times out <websockets> <MAAS:Triaged> <https://launchpad.net/bugs/1436277>
<mup> Bug #1441864 was opened: 1.8b1: Can't filter servers by owner correctly if owner is subset of another owner <oil> <MAAS:New> <https://launchpad.net/bugs/1441864>
<mup> Bug #1441472 changed: mass-cli "nodes new" command: autodetect_nodegroup parameter is undocumented <api> <doc> <MAAS:Triaged by mpontillo> <https://launchpad.net/bugs/1441472>
#maas 2015-04-09
<mup> Bug #1441933 was opened: Internal Server Error when saving a cluster without Router IP <MAAS:New for rvb> <MAAS 1.7:New> <https://launchpad.net/bugs/1441933>
<dimitern> rvba, ping
<rvba> dimitern: hey
<dimitern> rvba, hey, it's fine - I needed to confirm that missing lshw data always leads to failed deployments, but roaksoax already did this
<rvba> dimitern: okay, cool :).
<dimitern> rvba, which means juju should indeed fail when lshw is missing/unparsable
<rvba> Right.
<mup> Bug #1442059 was opened: 1.8b1 Failed deployment timeout powering on AMT <landscape> <power> <MAAS:New> <https://launchpad.net/bugs/1442059>
<mup> Bug #1442059 changed: 1.8b1 Failed deployment timeout powering on AMT <landscape> <power> <MAAS:New> <https://launchpad.net/bugs/1442059>
<mup> Bug #1442059 was opened: 1.8b1 Failed deployment timeout powering on AMT <landscape> <power> <MAAS:New> <https://launchpad.net/bugs/1442059>
<mup> Bug #1442112 was opened: booting ppc64el with hwe-u kernel hangs in initrd <MAAS:New> <https://launchpad.net/bugs/1442112>
<mup> Bug #1442131 was opened: 1.8b1 redundant owner column on devices page <ui> <MAAS:New> <https://launchpad.net/bugs/1442131>
<mup> Bug #1442157 was opened: Manually added node doesn't get added to MAAS managed DNS <MAAS:New> <https://launchpad.net/bugs/1442157>
<mup> Bug #1442162 was opened: Spurious test failure: maasserver.api.tests.test_nodes.TestFilteredNodesListFromRequest.test_node_list_with_ids_orders_by_id <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1442162>
<mup> Bug #1442234 was opened: maas-regiond and maas-clusterd clobber logs each time they're started <MAAS:New> <https://launchpad.net/bugs/1442234>
<mup> Bug #1442280 was opened: The ordering of the statuses changes when nodes change status <ui> <MAAS:New> <https://launchpad.net/bugs/1442280>
<mup> Bug #1442280 changed: The ordering of the statuses changes when nodes change status <ui> <MAAS:New> <https://launchpad.net/bugs/1442280>
<mup> Bug #1442280 was opened: The ordering of the statuses changes when nodes change status <ui> <MAAS:New> <https://launchpad.net/bugs/1442280>
<serverascode> Does anyone know if the 1.7.1 deb files for trusty around somewhere? the stable ppa has 1.7.2 which is not working for me, but 1.7.1 is in another install
<roaksoax> serverascode: why is it not working?
<roaksoax> serverascode: what are you affected by?
<serverascode> seems like the region controller doesn't auto configure, " Failed to connect to region controller, cannot upload leases", I don't see interfaces in the cluster in the gui
<serverascode> to be honest I don't really have time to troubleshoot it, I have a feeling 1.7.1 will work
<serverascode> I'd really like to use and recommend maas, but so far it has been quite the struggle
<bmorriso> Morning folks. It seems like MaaS by default installs on the first disk. "d-i     partman/early_command string debconf-set partman-auto/disk `list-devices disk | head -n1`" --  Would I just edit this to something more like "d-i partman-auto/disk string /dev/sdb" to specify the disk I want? I am using Curtin, rather than debian installer.
<blake_r> bmorriso: if you using curtin then you will want to change the curtin_userdata preseed
<bmorriso> I don't see anything in there specific to partitioning/disk layout
<blake_r> bmorriso: that is because by default curitn picks the first disk
<blake_r> bmorriso: http://paste.ubuntu.com/10784573/
<blake_r> bmorriso: add that to the config
<blake_r> bmorriso: change the /dev/sdb to the device you want
<bmorriso> Is there a certain place that should go?
<blake_r> bmorriso: it can just go at the end
<blake_r> serverascode: did you ever get the cluster connected to the region
<bmorriso> Thank you very much!!
<blake_r> bmorriso: no problem
<bmorriso> blake_r: if I wanted to target a specific host with that command? According to this https://maas.ubuntu.com/docs1.7/development/preseeds.html I would do something like "curtin_userdata_ubuntu_amd64_generic_bfs2.poc" ?
<bmorriso> With Curtin is there a way to target system information? Either brand of server, or type of disk?
<bmorriso> I can give more context if it'd help
<blake_r> curtin_userdata_ubuntu_amd64_generic_trusty_bfs2
<blake_r> don't include the fqdn
<blake_r> just the hostname
<blake_r> bmorriso: no real way of doing that
<blake_r> bmorriso: you could tag the machines in maas
<blake_r> bmorriso: then using the templating system we use, make a conditional on that tag
<bmorriso> So tag it UCS/LUN or something similar, then based on those tags, match on the conditional with an "if/else" and I could set the partition that way?
<bmorriso> I really don't want to get into managing preseeds per server, rather I'd like to say "If this has a NetApp disk (LUN) or If this is UCS booting from SAN, install Ubuntu on this disk, else install on the first disk"
<blake_r> bmorriso: no not that way
<blake_r> bmorriso: if you need to do something like that, then you will need to add that logic in the preseed to be processed by the client
<blake_r> bmorriso: I was speaking of tags in  maas, like tagging a machine
<bmorriso> I'll have to look at the docs to see.
<bmorriso> blake_r: I used what you suggested for /dev/sdb but it actually installed it on /dev/sdc http://paste.ubuntu.com/10784781/
<blake_r> bmorriso: the order the disks are picked up by the kernel are not persistent
<blake_r> bmorriso: so /dev/sdb would have been /dev/sdc in the installer environment
<bmorriso> OK. Fair enough. It did what I wanted, which was to _not_ install on the local disks
<blake_r> bmorriso: you could use by-id path if you want a specific disk and you know its id
<blake_r> bmorriso: ls -l /dev/disks/by-id/
<blake_r> bmorriso: that will make sure its that exact disk
<bmorriso> this should suffice. I don't hard code paths, the only intention was to ensure it didn't install on the local disks. This is perfect! Thanks for the support. Love this channel/group/project
<bmorriso> blake_r: what is the equivalent of "install disk-detect/multipath/enable=true" in curtin? Or is there?
<bmorriso> I have this in curtin_userdata_ubuntu_amd64_generic_trusty_bfs2 http://paste.ubuntu.com/10785028/ but it doesn't actually install the package.
<bmorriso> Would I not see early or late commands in install.log? Is there a way to see this output?
<blake_r> bmorris: try adding .local to the end of that file to see if it gets installed
<blake_r> might not be getting used
<blake_r> hostname will contain a .local if it was enlisted and not manually added
<blake_r> oh I know what's wrong
<blake_r> you need that one late_commands
<blake_r> and you need to use curtin in-target -- before it
<blake_r> without that you are installjng in the booted Ubuntu installed
<mup> Bug #1442360 was opened: 1.8b1: Cannot add machine Missing Power Type <oil> <MAAS:New> <https://launchpad.net/bugs/1442360>
<bmorriso> blake_r: what you sent earlier, is now getting picked up but it errors http://paste.ubuntu.com/10785782/
<blake_r> bmorriso: ah its block-meta not block_meta, my bad
<bmorriso> yeah, I looked closer at the output...no worries. Appreciate the guidance. Wish there were more documentation on curtin. Feels like a black box
<bmorriso> Is here the best place to ask curtin questions or is there a curtin specific channel?
<blake_r> bmorriso: this is the best place, no specific curtin channel
<bmorriso> I just hacked together a pretty awesome preseed, and now I have to figure out how to get it all into Curtin.
<bmorriso> So my install log shows "Installation finished. No error reported" but the server is just stuck in 'deploying' state http://paste.ubuntu.com/10785977/
<bmorriso> It never changes from 'deploying' to 'deployed'
<blake_r> bmorriso: the node has to boot again into the new installation and contactaas to
<blake_r> maas to be marked deployed
<blake_r> check the console of the node to see where it got stuck
<bmorriso> It's at the login prompt
<bmorriso> it never rebooted
<bmorriso> It put the keys on the host
<bmorriso> Here is a screenshot http://i.imgur.com/qXCk6Fb.png
<bmorriso> I can provide cloud-init.log or cloud-init-output.log if it would be useful
<mup> Bug #1442379 was opened: 1.8beta1: 500 error when shutting down node <oil> <MAAS:New> <https://launchpad.net/bugs/1442379>
#maas 2015-04-10
<mup> Bug #1442446 was opened: 1.8b1: selecting multiple filtering properties returns all  servers that match at least 1 property <oil> <MAAS:New> <https://launchpad.net/bugs/1442446>
<mup> Bug #1442446 changed: 1.8b1: selecting multiple filtering properties returns all  servers that match at least 1 property <oil> <MAAS:New> <https://launchpad.net/bugs/1442446>
<mup> Bug #1442446 was opened: 1.8b1: selecting multiple filtering properties returns all  servers that match at least 1 property <oil> <MAAS:New> <https://launchpad.net/bugs/1442446>
<mup> Bug #1442552 was opened: DHCP/DNS not syncing <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1442552>
<mup> Bug #1442552 changed: DHCP/DNS not syncing <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1442552>
<mup> Bug #1442552 was opened: DHCP/DNS not syncing <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1442552>
<mup> Bug #1442575 was opened: power_change_failure() does not handle NodeStateViolation and NoSuchNode <MAAS:Triaged> <https://launchpad.net/bugs/1442575>
<ravenpi> Good morning, all.  As noted in https://bugs.launchpad.net/maas/+bug/1401703 , I have 15 nodes that I'm trying to deploy, and 2 of them correctly saw their 1 TB disks.  The other 13 report 1 GB disks.  Based on the discovered data (see link), I'm kind of assuming that MAAS "found" the PXE install partition -- either that, or the 1 GB is completely bogus.  Is there a way to specify which drive to provision with?
<mup> Bug #1423721 changed: prefix_filter for probe-and-enlist for virsh/esxi doesn't create nodes with the hostname equal to the domain name <MAAS:Won't Fix by mpontillo> <https://launchpad.net/bugs/1423721>
<mup> Bug #1442360 changed: 1.8b1: Cannot add machine Missing Power Type <oil> <ui> <MAAS:New> <https://launchpad.net/bugs/1442360>
<serverascode> anyone know why the install would be asking to continue without a default route?
<ravenpi> Could you flesh out that question some?  Install of what?  Is it actually *asking* about a default route, or is it asking to continue, and you simply haven't added one?  As I understand it, the clients don't care -- they get to use the MAAS master as a proxy (Squid, port 8000).  The MAAS master, itself, probably needs one.
<ravenpi> [Note that I'm far from an authority on this -- just bumped my toes against some of that stuff recently, and think -- hope -- I have an understanding of it.)
<serverascode> when a node is started, it goes through the install procedure, but in my case I need to manually click yes to being ok with continuing without a default route
<serverascode> I'm guessing that dfault route is supposed to come from maas somewhere...?
<serverascode> perhaps something is misconfigured...just not sure what it would be
<ravenpi> Oh.  That, I don't know the answer to.  :(  Yeah, you're able to push the default route from MAAS.  Lemme take a quick peek.
<serverascode> not that they even need a default route...
<ravenpi> Clusters -> Cluster Master -> click edit icon for interfaces -> Router IP
<serverascode> ok yeah that makes sense, thanks ravenpi :)
<ravenpi> Pleasure's mine!
<mup> Bug #1442742 was opened: 1.8b2 Incorrect power on/off actions on node details <ui> <MAAS:New> <https://launchpad.net/bugs/1442742>
<mup> Bug #1442742 changed: 1.8b2 Incorrect power on/off actions on node details <ui> <MAAS:New> <https://launchpad.net/bugs/1442742>
<mup> Bug #1442742 was opened: 1.8b2 Incorrect power on/off actions on node details <ui> <MAAS:New> <https://launchpad.net/bugs/1442742>
<mup> Bug #1442746 was opened: 1.8b2 Add hardware journey not consistent with add devices <ui> <MAAS:New> <https://launchpad.net/bugs/1442746>
<saltlake> experts, I am looking for some help on deplying openstack: I knwo this is the problem in this area from the syslog http://pastebin.com/B5du7hDU.. exactly this like that deplyment starts but the controller node fails to get the results.. I just don't know what and I would very appreciate if anyone could throw some light on it. I think one problem coud be "if a node commissioned on the maas server has 2 NICs : Port
<saltlake>  1->connected to provate network and Port 2 connecte to the public network... I was expecting Port 2 to get a dhcp address on the public LAN but don't see that happening .. What do I need to do for that ?
<serverascode> hi all, how does one do classes of servers in maas? as in I want associate a disk layout with a particular class of servers
<serverascode> saltlake: do you have any more logs, I'm no expert but I can't see anything that helps from those logs
<mup> Bug #1442754 was opened: 1.8b2 No UI feedback on "power on" action <ui> <MAAS:New> <https://launchpad.net/bugs/1442754>
<saltlake> serverascode : Yes I have more of the syslog
<saltlake> serverascode : http://pastebin.com/EdZW3dyv
<saltlake> Any help on this would be so useful I am just unable tp proceed and stuck on what seems like something basic !!
<serverascode> saltlake: and what is the problem your having exactly?
<saltlake> serverascode : What happends is I start a juju boostrap on the maas controller node. On the maas web page I see one node change to "Deplying" and eventually it "Fails deplyment" and juju bootstrap after several minutes exits saying "Boot strapped but failed to deploy"
<serverascode> but you can insatll nodes ok?
<saltlake> serverascode : On the maas controller the 3 nodes aer successfully commisioned.
<saltlake> serverascode : But juju bootstrap OR openstack-install with the landscape option both fail the same way.
<serverascode> hmm, yeah I don't know anything about juju so I don't think I can help you there
<saltlake> SO something is wrong with my setup.
<saltlake> serverascode : Can you tell me if my network is setup properly though ?
<serverascode> being able to commission is a good sign I suspect
<saltlake> Each node is on 2 networks 1. private and commissioning is happening through this. 2. On the public network and I am wondering why this one does not get a dhcp address
<saltlake> is there a guide you have handy to install openstack on ubuntu ?
<serverascode> there are lots of guides including what's on the openstack site in terms of instlling on ubuntu 14.04
<serverascode> http://docs.openstack.org/juno/install-guide/install/apt/content/
<saltlake> serverascode : This does not use maas at all
<saltlake> serverascode ; Just curious: Have you used the steps at http://docs.openstack.org/juno/install-guide/install/apt/content/ without maas and has it worked out ?
<serverascode> saltlake: there are as many ways to install openstack as there are people :) yes I run openstack but don't use juju, but if you like juju then I think you should continue on, I just can't personally help you b/c I don't use juju
<saltlake> serverascode : I have not got anything working with openstack and have no experience with it and am looking for the shortest path to success .. :-) thanks I will try your link now
<mup> Bug #1442807 was opened: 1.8beta1: Attempting to release a node that's already releasing results in an error <oil> <MAAS:New> <https://launchpad.net/bugs/1442807>
<serverascode> anyone on how to add a class of hw to maas? is it done through the architecture somehow?
#maas 2015-04-11
<vinay_> what's the version of maas that ships with 14.10?
<blake_r> serverascode: what do you mean a class of hw?
<AskUbuntu> Ubuntu 14.10 MAAS - Importing images | http://askubuntu.com/q/608151
#maas 2015-04-12
<AskUbuntu> Juju - Wordpress hook failed : install | http://askubuntu.com/q/608238
<timbo_> hello my friends... anybody listening here...?
<timbo_> I am enthralled with MAAS and got a question or two with regards to Dell computers and Boot from Lan
<timbo_> I have my controller up and running and all it good..  I am having a tough time getting my nodes to commission..
<timbo_> I have a handful of optiplex 750's and it took a little work, but I got my first node to boot from lan successfully.
<timbo_> I delete the node from and allow it to be discovered.  When it is ready, I click commission and the node starts up.
<timbo_> I am watching the console on the node and it all looks good...  SUCCESS then a login prompt.
<timbo_> I try a root login (right or wrong?) and then it gives me some more output and shuts down the node.
<timbo_> and the node is back at READY...  Like nothing happened.
<timbo_> trying again.. shows up as declared but unknown power type.  I edit the WOL setting and add the MAC.  click commission and the node starts!
<timbo_> I am looking through the logs and config files on the controller...  Not finding anything interesting...
<timbo_> Anybody been here before and know where to investigate....  I don't need hand holding..  Just a pointer will do.
<timbo_> the node shuts down after a while and shows up as READY again...
<timbo_> bump
<Crossfire0mega> Hi all
<Crossfire0mega> So I just setup my first MAAS server and I am having some issues with getting my nodes up and running.
<Crossfire0mega> I have two nodes setup and conneced to the network and PXE boot working, they contact the MAAS server and pull the files correctly and go from commission state to ready state but when I select start nodes I get a mesage saying that their state doesnt allow that action.
<Crossfire0mega> I have edited both nodes power types and set them to WOL with their mac addresses but still to no avail.
<AskUbuntu> Juju - agent-state stuck on allocating | http://askubuntu.com/q/608544
#maas 2016-04-11
<bogdanteleaga> what version of maas should I install on trusty?
<bogdanteleaga> both the default one and the one from the stable ppa complain about postgresql and don't install succesfully
<bogdanteleaga> on a clean trusty install
<mup> Bug #1568847 opened: Service 'maas-proxy' failed to start: Job for maas-proxy.service failed because the control process exited with error code. See "systemctl status maas-proxy.service" and "journalctl -xe" for details. <MAAS:New> <https://launchpad.net/bugs/1568847>
<mup> Bug #1568878 opened: [2.0 beta 1] Enlistment environment trying to access precise ports? <MAAS:New> <https://launchpad.net/bugs/1568878>
<neiljerram> Does anyone know about status of using MAAS to deploy Xenial boxes?  For me it's not working, but maybe I'm doing something stupid...
<rbasak> Which version of MAAS? Some version works because I just got given a Xenial MAAS-deployed box.
<rbasak> I'm not an admin on that network though, so I don't really know any more.
<neiljerram> MAAS version 1.9.1, running on Trusty.
<neiljerram> BTW how close are we to the Xenial release now?
<mup> Bug #1568990 opened: Images do not load properly from API, only UI <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1568990>
<mup> Bug #1564802 changed: [2.0a4] cli maas boot-resources import does not trigger import of images <cdo-qa> <cdo-qa-blocker> <cli> <MAAS:Invalid> <https://launchpad.net/bugs/1564802>
<mup> Bug #1568990 changed: Images do not load properly from API, only UI <cdo-qa> <MAAS:Invalid> <https://launchpad.net/bugs/1568990>
<mup> Bug #1568878 changed: [2.0 beta 1] Enlistment environment trying to access precise ports? <MAAS:Invalid> <https://launchpad.net/bugs/1568878>
<mup> Bug #1568878 opened: [2.0 beta 1] Enlistment environment trying to access precise ports? <MAAS:Invalid> <https://launchpad.net/bugs/1568878>
<mup> Bug #1568878 changed: [2.0 beta 1] Enlistment environment trying to access precise ports? <MAAS:Invalid> <https://launchpad.net/bugs/1568878>
<mup> Bug #1272011 changed: MAAS installer doesn't prompt for superuser password and email <micro-cluster> <MAAS:Invalid> <maas (Ubuntu):Fix Released> <https://launchpad.net/bugs/1272011>
<mup> Bug #1569084 opened: MAAS should report whether a boot image on a rack controller is synced <MAAS:New> <https://launchpad.net/bugs/1569084>
#maas 2016-04-12
<mup> Bug #1569102 opened: API 2.0 deploy makes machine lose power information <MAAS:New> <https://launchpad.net/bugs/1569102>
<mup> Bug #1569104 opened: Docs wrong for link_subnet API call <MAAS:New> <https://launchpad.net/bugs/1569104>
<mup> Bug #1536039 changed: curtin fails install unexpected error while running apt-get command - Exit code 100 <oil> <curtin:Incomplete> <MAAS:Expired> <https://launchpad.net/bugs/1536039>
<mup> Bug #1569259 opened: TestInterfaceManager.test_get_interface_or_404_raises_Http404_when_invalid_id fails spuriously <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1569259>
<mup> Bug #1569259 changed: TestInterfaceManager.test_get_interface_or_404_raises_Http404_when_invalid_id fails spuriously <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1569259>
<mup> Bug #1569259 opened: TestInterfaceManager.test_get_interface_or_404_raises_Http404_when_invalid_id fails spuriously <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1569259>
<mup> Bug #1569365 opened: TestPartition.test_get_partition_number_returns_starting_at_2_for_ppc64el fails spuriously <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1569365>
<mup> Bug #1569385 opened: MAAS send DHCP Offer packet with wrong unicast ip address <dhcp> <MAAS:Incomplete> <https://launchpad.net/bugs/1569385>
<mup> Bug #1313550 changed: ping does not work as a normal user on trusty tarball cloud images. <cloud-images> <cloud-images-build> <patch> <verification-done> <curtin:Fix Committed> <MAAS:Fix Released> <curtin (Ubuntu):Fix Released> <iputils (Ubuntu):Fix Released> <lxc (Ubuntu):Invalid> <maas
<mup> (Ubuntu):Fix Released> <tar (Ubuntu):Fix Released> <tar (Ubuntu Precise):Confirmed> <maas (Ubuntu Saucy):Won't Fix> <tar (Ubuntu Saucy):Won't Fix> <curtin (Ubuntu Trusty):Fix Released> <maas (Ubuntu Trusty):Confirmed> <tar (Ubuntu Trusty):Fix Released> <maas (Ubuntu Vivid):Confirmed> <maas (Ubuntu
<mup> Wily):Fix Released> <https://launchpad.net/bugs/1313550>
<mup> Bug #1569483 opened: [2.0] Can't deploy CentOS  <MAAS:New> <https://launchpad.net/bugs/1569483>
<mup> Bug #1569549 opened: Deploy with RAID as / fails if there is a newer kernel available <kanban-cross-team> <landscape> <MAAS:New> <https://launchpad.net/bugs/1569549>
<mup> Bug #1569549 changed: Deploy with RAID as / fails if there is a newer kernel available <kanban-cross-team> <landscape> <MAAS:New> <https://launchpad.net/bugs/1569549>
<mup> Bug #1569549 opened: Deploy with RAID as / fails if there is a newer kernel available <kanban-cross-team> <landscape> <MAAS:New> <https://launchpad.net/bugs/1569549>
<mup> Bug #1569556 opened: MAAS 1.9.1 fails to commission a node <MAAS:New> <https://launchpad.net/bugs/1569556>
<mup> Bug #1569549 changed: Deploy with RAID as / fails if there is a newer kernel available <kanban-cross-team> <landscape> <curtin:Incomplete> <https://launchpad.net/bugs/1569549>
<mup> Bug #1569568 opened: [2.0beta1] maas-dhcpd should not attempt reload the apparmor profile when installing in a container <packaging> <MAAS:In Progress by blake-rouse> <https://launchpad.net/bugs/1569568>
#maas 2016-04-13
<mup> Bug #1544962 changed: MAAS tags don't find any nodes <MAAS:Expired> <https://launchpad.net/bugs/1544962>
<mup> Bug #1545035 changed: maas-cluserd cant bind to tftp port <MAAS:Expired> <https://launchpad.net/bugs/1545035>
<mup> Bug #1569385 changed: MAAS send DHCP Offer packet with wrong unicast ip address <dhcp> <MAAS:Invalid> <https://launchpad.net/bugs/1569385>
<mup> Bug #1569678 opened: POST /api/2.0/devices/ op=create stopped working with r4910 package <MAAS:New> <https://launchpad.net/bugs/1569678>
<mup> Bug #1569678 changed: POST /api/2.0/devices/ op=create stopped working with r4910 package <MAAS:New> <https://launchpad.net/bugs/1569678>
<mup> Bug #1569385 opened: MAAS send DHCP Offer packet with wrong unicast ip address <dhcp> <MAAS:Invalid> <https://launchpad.net/bugs/1569385>
<mup> Bug #1569385 changed: MAAS send DHCP Offer packet with wrong unicast ip address <dhcp> <MAAS:Invalid> <https://launchpad.net/bugs/1569385>
<mup> Bug #1569678 opened: POST /api/2.0/devices/ op=create stopped working with r4910 package <MAAS:New> <https://launchpad.net/bugs/1569678>
<mup> Bug #1569683 opened: MAAS constrains IPv4 & IPv6 static address selection on unmanaged interfaces <MAAS:New> <https://launchpad.net/bugs/1569683>
<mup> Bug #1569678 changed: POST /api/2.0/devices/ op=create stopped working with r4910 package <MAAS:Invalid> <https://launchpad.net/bugs/1569678>
<mup> Bug #1569678 opened: POST /api/2.0/devices/ op=create stopped working with r4910 package <MAAS:Invalid> <https://launchpad.net/bugs/1569678>
<mup> Bug #1569678 changed: POST /api/2.0/devices/ op=create stopped working with r4910 package <MAAS:Invalid> <https://launchpad.net/bugs/1569678>
<mup> Bug #1569873 opened: Failed to query node's BMC - Power state could not be queried: 'in <string>' requires string as left operand, not bytes <MAAS:New> <https://launchpad.net/bugs/1569873>
<mup> Bug #1569960 opened: Sdf <MAAS:New> <https://launchpad.net/bugs/1569960>
<mup> Bug #1569984 opened: AttributeError: 'NoneType' object has no attribute 'render_json' <MAAS:New> <https://launchpad.net/bugs/1569984>
<mup> Bug #1570002 opened: Expose custom network in non ubuntu deployments <MAAS:New> <https://launchpad.net/bugs/1570002>
<mup> Bug #1558747 changed: [1.9.1] Deployment for IBM S822LC  8335-GTA  and S812L TN71-BP012 fails to boot local disk following  curtin install <blocks-hwcert-server> <oil> <curtin:Invalid> <MAAS:Invalid by newell-jensen> <https://launchpad.net/bugs/1558747>
<mup> Bug #1570099 opened: Add server reservations by Maas Users <MAAS:Triaged> <https://launchpad.net/bugs/1570099>
<mup> Bug #1570104 opened: Bridges without parents are not modeled after rack controller registers <MAAS:Triaged> <https://launchpad.net/bugs/1570104>
#maas 2016-04-14
<mimizone> hi all, anybody has an example of a different way of defining the boot drive in the preseed? I need on somemachines to do it one way, and on others another way.
<mimizone> I am using maas 1.9.1
<roaksoax> mimizone: you can select the boot device in the UI
<mimizone> really???
<roaksoax> yeeees
<mimizone> :) I had never clicked on the circle :) go figure
<roaksoax> hopefully that helps :)
<mimizone> I am sure that would get me further
<mimizone> other question. If a node goes through the deploy installation fine based on the logs, but it is reported as a failed deployment, where should I look for some clues?
<mup> Bug #1570152 opened: [2.0 beta 2] Can't delete subnet in the UI, no action for it. <MAAS:New> <https://launchpad.net/bugs/1570152>
<mup> Bug #1570152 changed: [2.0 beta 2] Can't delete subnet in the UI, no action for it. <MAAS:New> <https://launchpad.net/bugs/1570152>
<mup> Bug #1570152 opened: [2.0 beta 2] Can't delete subnet in the UI, no action for it. <MAAS:New> <https://launchpad.net/bugs/1570152>
<mup> Bug #1570247 opened: MAAS 2 corrupts cloud init user data <MAAS:New> <https://launchpad.net/bugs/1570247>
<ReSam> good morning!
<ReSam> I'm getting "Failed Deployment" status on a couple of nodes, although the machine output / installation log looks good and clearly states "Installation finished." at the very end. I'm running MAAS 1.9.1 on trusty.
<mup> Bug #1570374 opened: Can't find way to edit or view bcache cache mode <MAAS:Triaged> <https://launchpad.net/bugs/1570374>
<mup> Bug #1541481 changed: number of CPU cores is 1 <MAAS:Invalid> <https://launchpad.net/bugs/1541481>
<mup> Bug #1553423 changed: Trying to update the upstream DNS, I saw: crochet._eventloop.TimeoutError:  <MAAS:Invalid> <https://launchpad.net/bugs/1553423>
<mup> Bug #1570391 opened: Add full disk encryption support <MAAS:Triaged> <https://launchpad.net/bugs/1570391>
<mup> Bug #1570407 opened: Unable to shut node down errors causing failures on client side <oil> <MAAS:Incomplete> <https://launchpad.net/bugs/1570407>
<mup> Bug #1570247 changed: [2.0] Cloud-init reports non-multipart userdata <MAAS:Invalid> <https://launchpad.net/bugs/1570247>
<mup> Bug #1570433 opened: no way of preserving the boot partition <MAAS:New> <https://launchpad.net/bugs/1570433>
<mup> Bug #1570606 opened: subnet.list: list index out of range <maas> <maasiprange> <maas (Ubuntu):New> <https://launchpad.net/bugs/1570606>
<mup> Bug #1570600 opened: [2.0 beta 2] Trying to enabled dhcp on fabric-1 with IPv4 networks, results in maas-dhcpd6 attempted to be enabled <MAAS:New> <https://launchpad.net/bugs/1570600>
<mup> Bug #1570606 opened: subnet.list: list index out of range <maas> <maasiprange> <MAAS:New> <maas (Ubuntu):New> <https://launchpad.net/bugs/1570606>
<mup> Bug #1570608 opened: [2.0 beta 2] wsman cli issue <MAAS:New> <https://launchpad.net/bugs/1570608>
<mup> Bug #1570609 opened: [2.0 beta 2]  builtins.TypeError: cannot use a bytes pattern on a string-like object <MAAS:New> <https://launchpad.net/bugs/1570609>
<mup> Bug #1570626 opened: [2.0 beta 2] NameError: name 'LargeFile' is not defined <MAAS:New> <https://launchpad.net/bugs/1570626>
<mup> Bug #1570633 opened: Nodes fail to remain powered after commision with "Allow SSH" selected <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1570633>
#maas 2016-04-15
<mup> Bug #1559354 changed: [2.0a3] Commissioning a Xenial image discovers LXC bridges <MAAS:Invalid> <https://launchpad.net/bugs/1559354>
<jacekn> where can I find documentation about preseed files in MAAS 1.9? I found this but links to the docs are dead: http://maas.ubuntu.com/docs1.9/configure.html#altering-the-preseed-file
<jacekn> and how can I view preseed for a given node in MAAS 1.9?
<mup> Bug #1570911 opened: [2,0b2] maas-dhcp packaging suggests init issues <MAAS:New> <https://launchpad.net/bugs/1570911>
<mup> Bug #1570911 changed: [2,0b2] maas-dhcp packaging suggests init issues <MAAS:New> <https://launchpad.net/bugs/1570911>
<mup> Bug #1570911 opened: [2,0b2] maas-dhcp packaging suggests init issues <MAAS:New> <https://launchpad.net/bugs/1570911>
<mup> Bug #1570934 opened: Reconfigure DHCP does not work <MAAS:New> <https://launchpad.net/bugs/1570934>
<mup> Bug # opened: 1570985, 1570990, 1570995, 1571002
<mup> Bug #1571006 opened: [2.0 beta 2] MAAS Rack Controller doesn't log when it is importing images <MAAS:New> <https://launchpad.net/bugs/1571006>
<mup> Bug #1571007 opened: [2.0 beta 2] MAAS Rack Controller doesn't log when it is importing images <MAAS:New> <https://launchpad.net/bugs/1571007>
<mup> Bug #1571031 opened: [2.0 beta 2] MAAS Rack Controller doesn't surface to the UI import issues <MAAS:New> <https://launchpad.net/bugs/1571031>
<mup> Bug #1571091 opened: [2.0b2] Initial install logs: duplicate key value violates unique constraint "maasserver_vlan_vid_7ed59c7c1ba3d05f_uniq" <MAAS:New> <https://launchpad.net/bugs/1571091>
<mup> Bug #1571091 changed: [2.0b2] Initial install logs: duplicate key value violates unique constraint "maasserver_vlan_vid_7ed59c7c1ba3d05f_uniq" <MAAS:New> <https://launchpad.net/bugs/1571091>
<mup> Bug #1571091 opened: [2.0b2] Initial install logs: duplicate key value violates unique constraint "maasserver_vlan_vid_7ed59c7c1ba3d05f_uniq" <MAAS:New> <https://launchpad.net/bugs/1571091>
<mup> Bug #1571101 opened: 2.0 beta2: maas cli client from trusty Trusty fails to login <oil> <MAAS:New> <https://launchpad.net/bugs/1571101>
#maas 2016-04-16
<mup> Bug #1571229 opened: localnet missing in ACL for maas-proxy (maas proxy fails to start) <MAAS:New> <https://launchpad.net/bugs/1571229>
<mup> Bug #1571233 opened: MAAS Region/Rack Controller does start on Bonds/VLANs <MAAS:New> <https://launchpad.net/bugs/1571233>
<mup> Bug #1571229 changed: localnet missing in ACL for maas-proxy (maas proxy fails to start) <MAAS:New> <https://launchpad.net/bugs/1571229>
<mup> Bug #1571252 opened: ppc64 cloud images (14.04, 15.10) don't restart network after a 'reboot' send from the CLI <MAAS:New> <https://launchpad.net/bugs/1571252>
<nooboob> hi all, does anyone know if MAAS runs on raspberry pi 3 and if pi's can be managed by it? Thanks.
#maas 2016-04-17
<jokowiuk> hello
<jokowiuk> looking for some advise on maas
<jokowiuk> i have my server setup with LSI Raid card..
<jokowiuk> when commisioning the node..it does not detect the disk
<jokowiuk> when i check i can see it is there
<jokowiuk> so i manually add using cli
<jokowiuk> however, when deploy autopilot..
<jokowiuk> i get an error saying that the serial number that i key in is not valid
<jokowiuk> or cant find the disk with the serial number
<jokowiuk> can we use the id_path instead..
<jokowiuk> and what is the best/most common value that we put inside id_path?
<mup> Bug #1571252 changed: ppc64 cloud images (14.04, 15.10) don't restart network after a 'reboot' send from the CLI <cloud-init:New> <MAAS:Invalid> <https://launchpad.net/bugs/1571252>
#maas 2017-04-10
<mup> Bug #1662852 changed: Machines configured with non-MAAS IPMI credentials do not commission <MAAS:Expired> <https://launchpad.net/bugs/1662852>
<mup> Bug #1681322 opened: Architecture filter for New machines <MAAS:New> <https://launchpad.net/bugs/1681322>
<mup> Bug # opened: 1681369, 1681378, 1681379, 1681383
<mup> Bug #1681386 opened: [UI, 2.2.0rc2] Pod overview-Add Pod - Empty state is not displayed all users see is an empty table <ui> <MAAS:New> <https://launchpad.net/bugs/1681386>
<mup> Bug #1681387 opened: [UI, 2.2.0rc2] Node details events - view full history button should be a link <MAAS:New> <https://launchpad.net/bugs/1681387>
<mup> Bug #1681388 opened: [2.2.0rc2, UX Improvement - Node listing] After I delete one or more nodes the machine list after the action is still filtered by selected but it will always be empty (since I deleted all the selected) <ui> <MAAS:New> <https://launchpad.net/bugs/1681388>
<mup> Bug #1681386 changed: [UI, 2.2.0rc2] Pod overview-Add Pod - Empty state is not displayed all users see is an empty table <ui> <MAAS:New> <https://launchpad.net/bugs/1681386>
<mup> Bug #1681387 changed: [UI, 2.2.0rc2] Node details events - view full history button should be a link <MAAS:New> <https://launchpad.net/bugs/1681387>
<mup> Bug #1681388 changed: [2.2.0rc2, UX Improvement - Node listing] After I delete one or more nodes the machine list after the action is still filtered by selected but it will always be empty (since I deleted all the selected) <ui> <MAAS:New> <https://launchpad.net/bugs/1681388>
<mup> Bug # opened: 1681386, 1681387, 1681388, 1681389, 1681390, 1681395
<mup> Bug #1681399 opened: [UI, 2.2.0rc2] Adding fabric / VLAN / Space <ui> <MAAS:New> <https://launchpad.net/bugs/1681399>
<mup> Bug #1681401 opened: [UI, 2.2.0rc2] Pods overview - Pods table broken at 1024px resolution, 'composed machines' row heading truncates below table in centre <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1681401>
<mup> Bug #1681407 opened: [UI, 2.2.0rc2] Footer link 'View release notes' is broken and points to 404 page <ui> <MAAS:New> <https://launchpad.net/bugs/1681407>
<mup> Bug #1681409 opened: [UI, 2.2.0rc2] Footer link 'View documentation' is broken and points to 404 page <ui> <MAAS:New> <https://launchpad.net/bugs/1681409>
<mup> Bug #1681407 changed: [UI, 2.2.0rc2] Footer link 'View release notes' is broken and points to 404 page <ui> <MAAS:New> <https://launchpad.net/bugs/1681407>
<mup> Bug #1681409 changed: [UI, 2.2.0rc2] Footer link 'View documentation' is broken and points to 404 page <ui> <MAAS:New> <https://launchpad.net/bugs/1681409>
<mup> Bug #1681407 opened: [UI, 2.2.0rc2] Footer link 'View release notes' is broken and points to 404 page <ui> <MAAS:New> <https://launchpad.net/bugs/1681407>
<mup> Bug #1681409 opened: [UI, 2.2.0rc2] Footer link 'View documentation' is broken and points to 404 page <ui> <MAAS:New> <https://launchpad.net/bugs/1681409>
<Guest49179> hi All ... I wanted to create my own image store using simplestreams and wanted some guidance on how kernel images can be uploaded into the simplestreams image store. Any quick help would be very much appreciated.
<mup> Bug #1681414 opened: [2.2.0rc2-Test hardware] When I scroll at the top or bottom of he hardware test selection dropdown, the page scrolls as well <ui> <MAAS:New> <https://launchpad.net/bugs/1681414>
<mup> Bug #1681414 changed: [2.2.0rc2-Test hardware] When I scroll at the top or bottom of he hardware test selection dropdown, the page scrolls as well <ui> <MAAS:New> <https://launchpad.net/bugs/1681414>
<mup> Bug #1681414 opened: [2.2.0rc2-Test hardware] When I scroll at the top or bottom of he hardware test selection dropdown, the page scrolls as well <ui> <MAAS:New> <https://launchpad.net/bugs/1681414>
<Guest64748> Hi All - any pointers on using simplestreams for custom image management?
<mup> Bug #1620064 changed: [2.0+] web UI has incorrect links to documentation <docteam> <MAAS:Fix Released by nobuto> <https://launchpad.net/bugs/1620064>
<mup> Bug #1681395 changed: [UI, 2.2.0rc2] Pods-Add Pod - When adding a 'Pod' the top right header action is displayed incorrectly <ui> <MAAS:Incomplete> <https://launchpad.net/bugs/1681395>
<mup> Bug #1681409 changed: [UI, 2.2.0rc2] Footer link 'View documentation' is broken and points to 404 page <ui> <MAAS:Invalid> <https://launchpad.net/bugs/1681409>
<mup> Bug #1681423 opened: [2.2.0rc2, UI, Test hardware] When I select the first script the placeholder text "Select script" should hide <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1681423>
<mup> Bug #1674959 opened: [UI] Close Add Pod button is redundant on pods page <ui> <ux> <MAAS:Triaged> <https://launchpad.net/bugs/1674959>
<mup> Bug #1681442 opened: [2.2.0rc2, UI, Test hardware] When the selected scripts wrap to a second row, the dropdown obscures the second row of the selected tests  <ui> <MAAS:Triaged by ricgard> <https://launchpad.net/bugs/1681442>
<vogelc> pmatulis: Where could I post a doc for you to review the issue we are seeing with DHCPrelay?
<Guest6464> I have mirrored images.maas.io to a local repo and now want to push my custom kernel image to this local repo. Has someone tried something similar earlier?
<pmatulis> vogelc, what sort of doc? would a pastebin work?
<pmatulis> vogelc, if not, then google doc?
<vogelc> pmatulis: if you want to send me a private email I can send you a link to the google doc.  vogelc@gmail.com
<kiko> vogelc, please add me as well, christian.robottom.reis@canonical.com? thanks
<pmatulis> vogelc, peter.matulis@canonical.com
<mup> Bug #1681464 opened: [UI, 2.2.0rc2] Footer - External links on mobile should be in own row <ui> <MAAS:New> <https://launchpad.net/bugs/1681464>
<mup> Bug #1681467 opened: [2.2 beta5] not able to create new tags - Conflict error. Try your request again, as it will most likely succeed. <cdo-qa-blocker> <oil> <MAAS:New> <https://launchpad.net/bugs/1681467>
<vogelc> pmatulis: You should get a link soon.
<vogelc> kiko: You should get a link soon
<pmatulis> vogelc, got it
<mup> Bug #1681477 opened: [2.2.0rc2, UI, Test hardware] Clicking in the hardware test selection dropdown the far right doesn't open the dropdown <ui> <MAAS:New> <https://launchpad.net/bugs/1681477>
<mup> Bug #1681489 opened: [2.2.0rc2, UI, Test hardware] When I have selected all available scripts, the dropdown list does not open anymore <ui> <MAAS:New> <https://launchpad.net/bugs/1681489>
<mup> Bug #1681505 opened: [2.2.0rc2, UI, Test hardware] When I select a destructive test, I expect MAAS to ask for validation before I continue into testing <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1681505>
<cmd_pancakes> is /etc/maas/preseeds/enlist_userdata the config that gets executed when a host first PXE boot under maas? im trying to troubleshoot a potential bug of a iscsi initiator overwriting the default boot one which causes the host to fail mounting maas iscsi properly
<mup> Bug #1666096 changed: [2.1] Database migrations failed when updating from MAAS 2.0 <MAAS:Invalid> <https://launchpad.net/bugs/1666096>
<cmd_pancakes> so yeah there is definitely a conflict somewhere between my HBA and the iscsi mounting from the rack controller
<cmd_pancakes> but im not sure how to diagnose it since the shell that the enlisting process eventually drops into is pretty limited
<cmd_pancakes> roaksoax: i think you had mentioned that suggestion to me last week
<cmd_pancakes> im going to see how commissioning handles the HBA
<cmd_pancakes> no good either...it hangs in the same way enlistment did
<cmd_pancakes> i also get a kernel panic when waiting for 'scsi_complete_async_scans'
<cmd_pancakes> well an exception...not really a panic
#maas 2017-04-11
<mup> Bug #1681611 opened: Page must be refreshed when scripts updated via the API/CLI <MAAS:In Progress by ltrager> <https://launchpad.net/bugs/1681611>
<mup> Bug #1681694 opened: [2.2] Xenial/ARM64 images fail to download - appear to be looking under the wrong date <MAAS:Triaged> <https://launchpad.net/bugs/1681694>
<mup> Bug #1681738 opened: [2.2.0rc2, UI, Test hardware] Change the wording of the error message for hardware testing a deployed machine <ui> <MAAS:New> <https://launchpad.net/bugs/1681738>
<mup> Bug #1681745 opened: [UI, 2.2.0rc2] Device discovery table - Devices names in row are not aligned to top as seen other columns <ui> <MAAS:New> <https://launchpad.net/bugs/1681745>
<mup> Bug #1681757 opened: [2.2.0rc2, UI, Machine actions] All the actions' confirmation buttons (Cancel/[Action] in the machine details page are placed on the left <ui> <MAAS:New> <https://launchpad.net/bugs/1681757>
<mup> Bug #1681771 opened: Device discovery page has no maximum limit of devices shown <landscape> <MAAS:New> <https://launchpad.net/bugs/1681771>
<mup> Bug #1681414 changed: [2.2.0rc2-UX improvement-Test hardware] When I scroll at the top or bottom of he hardware test selection dropdown, the page scrolls as well <ui> <MAAS:Won't Fix by ricgard> <https://launchpad.net/bugs/1681414>
<mup> Bug # opened: 1681775, 1681777, 1681780, 1681783, 1681785
<mup> Bug # opened: 1681789, 1681790, 1681800, 1681801
<mup> Bug #1681808 opened: [2.2.0rc2, UI, Machine details] When I scroll down in the machine details page and I click the Take action button, the dropdown shows behind the header <ui> <MAAS:New> <https://launchpad.net/bugs/1681808>
<mup> Bug #1681808 changed: [2.2.0rc2, UI, Machine details] When I scroll down in the machine details page and I click the Take action button, the dropdown shows behind the header <ui> <MAAS:New> <https://launchpad.net/bugs/1681808>
<mup> Bug #1681808 opened: [2.2.0rc2, UI, Machine details] When I scroll down in the machine details page and I click the Take action button, the dropdown shows behind the header <ui> <MAAS:New> <https://launchpad.net/bugs/1681808>
<mup> Bug #1681817 opened: [UI, 2.2.0rc2] Device discovery - Mobile table - Device name bleeds outside the card <ui> <MAAS:New> <https://launchpad.net/bugs/1681817>
<mup> Bug #1681820 opened: [2.2.0rc2, UI, Secondary nav] There is a small gap between the header and the secondary nav and you can see the content scrolling behind <ui> <MAAS:New> <https://launchpad.net/bugs/1681820>
<mup> Bug #1681808 changed: [2.2.0rc2, UI, Machine details] When I scroll down in the machine details page and I click the Take action button, the dropdown shows behind the header <ui> <MAAS:New> <https://launchpad.net/bugs/1681808>
<mup> Bug #1681856 opened: [2.2.0rc2, UI, Machine details] The Edit button is placed on the bottom right instead of the top right in the summary page <ui> <MAAS:Triaged by ricgard> <https://launchpad.net/bugs/1681856>
<mup> Bug #1681869 opened: [2.2.0rc2, UI, Machine details] The tables that have a contextual row menu, should have a column header <ui> <MAAS:New> <https://launchpad.net/bugs/1681869>
<mup> Bug #1681869 changed: [2.2.0rc2, UI, Machine details] The tables that have a contextual row menu, should have a column header <ui> <MAAS:New> <https://launchpad.net/bugs/1681869>
<mup> Bug #1681869 opened: [2.2.0rc2, UI, Machine details] The tables that have a contextual row menu, should have a column header <ui> <MAAS:New> <https://launchpad.net/bugs/1681869>
<mup> Bug #1681872 opened: [2.2.0rc2, UI, Machine details] When I edit an interface, there is no padding under the tags input field <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1681872>
<mup> Bug #1681876 opened: [2.2.0rc2, UI, Machine details] If I add a tag for an interface, the next tag that I try to add sometimes cannot be saved <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1681876>
<mup> Bug #1681878 opened: [2.2.0rc2, UI, Machine details] Remove Power header from the Power section <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1681878>
<mup> Bug #1681881 opened: [2.2.0rc2, UI, Machine details] In the machine summary the tags input field is not in the right position and doesn't have the right size <ui> <MAAS:New> <https://launchpad.net/bugs/1681881>
<mup> Bug #1681881 changed: [2.2.0rc2, UI, Machine details] In the machine summary the tags input field is not in the right position and doesn't have the right size <ui> <MAAS:New> <https://launchpad.net/bugs/1681881>
<mup> Bug #1681887 opened: [2.2.0rc2, UI, Nodes] The remove filter button (x) and filter name alignment is a bit off <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1681887>
<mup> Bug #1681937 opened: MaaS API processes input slowly: network config at customer sites takes 45min <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1681937>
<mup> Bug #1681937 changed: MaaS API processes input slowly: network config at customer sites takes 45min <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1681937>
<mup> Bug #1681937 opened: MaaS API processes input slowly: network config at customer sites takes 45min <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1681937>
#maas 2017-04-12
<mup> Bug #1681976 opened: [2.2 rc2] dependencies issues while trying to do a fresh install - Unable to correct problems, you have held broken packages <oil> <MAAS:New> <https://launchpad.net/bugs/1681976>
<mup> Bug #1681976 changed: [2.2 rc2] dependencies issues while trying to do a fresh install - Unable to correct problems, you have held broken packages <oil> <MAAS:Invalid> <https://launchpad.net/bugs/1681976>
<xygnal> does maas prune its events table periodically? noticed log events going back months.
<roaksoax> xygnal: no it doesn't
<xygnal> WhatsAppâ the maas safe way to prune it?
<xygnal> hah thanks a/c. What's
<mup> Bug #1681694 changed: [2.2] Xenial/ARM64 images fail to download - appear to be looking under the wrong date <MAAS:Invalid> <https://launchpad.net/bugs/1681694>
<mup> Bug #1682079 opened: [2.2.0rc2, Device discovery] Even though I disabled device discovery from Settings, when I go to the dashboard, I can see the spinner loading and devices look like they are being discovered <ui> <MAAS:New> <https://launchpad.net/bugs/1682079>
<mup> Bug #1682082 opened: [2.2.0rc2, Settings/Device discovery] When device discovery is disabled, the Active subnet mapping interval should automatically be set to Never (disabled) <ui> <MAAS:New> <https://launchpad.net/bugs/1682082>
<mup> Bug #1682083 opened: When adding two machines consecutively they land on the same instance <juju:New> <MAAS:New> <https://launchpad.net/bugs/1682083>
<mup> Bug #1682090 opened: [2.2.0rc2, UI, Machine details-Storage] I cannot select another boot disk and I have no idea whether it is not possible or it's a bug  <ui> <MAAS:New> <https://launchpad.net/bugs/1682090>
<mup> Bug #1682099 opened: [2.2.0rc2, UI, Images] In custom source the "Advanced options button changes position when I click  Show/Hide <ui> <MAAS:New> <https://launchpad.net/bugs/1682099>
<vogelc> pmatulis: morning, any thoughts on why our relay doesnt seem to work?
<pmatulis> vogelc, sorry, not yet
<mup> Bug #1682079 changed: [2.2.0rc2, Device discovery] Even though I disabled device discovery from Settings, when I go to the dashboard, I can see the spinner loading and devices look like they are being discovered <ui> <MAAS:Opinion> <https://launchpad.net/bugs/1682079>
<mup> Bug #1682082 changed: [2.2.0rc2, Settings/Device discovery] When device discovery is disabled, the Active subnet mapping interval should automatically be set to Never (disabled) <ui> <MAAS:Won't Fix> <https://launchpad.net/bugs/1682082>
<mup> Bug #1682079 opened: [2.2.0rc2, Device discovery] Even though I disabled device discovery from Settings, when I go to the dashboard, I can see the spinner loading and devices look like they are being discovered <ui> <MAAS:Opinion> <https://launchpad.net/bugs/1682079>
<mup> Bug #1682082 opened: [2.2.0rc2, Settings/Device discovery] When device discovery is disabled, the Active subnet mapping interval should automatically be set to Never (disabled) <ui> <MAAS:Won't Fix> <https://launchpad.net/bugs/1682082>
<vogelc> pmatulis: OK, thanks for the follow up.  We continue to try different configurations, no break thru's yet.
<mup> Bug #1682079 changed: [2.2.0rc2, Device discovery] Even though I disabled device discovery from Settings, when I go to the dashboard, I can see the spinner loading and devices look like they are being discovered <ui> <MAAS:Opinion> <https://launchpad.net/bugs/1682079>
<mup> Bug #1682082 changed: [2.2.0rc2, Settings/Device discovery] When device discovery is disabled, the Active subnet mapping interval should automatically be set to Never (disabled) <ui> <MAAS:Won't Fix> <https://launchpad.net/bugs/1682082>
<mup> Bug #1682139 opened: AttributeError: 'ACKDatagram' object has no attribute 'mode'  <MAAS:In Progress by andreserl> <https://launchpad.net/bugs/1682139>
<mup> Bug #1682141 opened: [2.2.0rc2, UI, Images] In custom source when I add invalid URL format the error message is too disconnected from the field, has wrong icon, needs wording update <ui> <MAAS:New> <https://launchpad.net/bugs/1682141>
<mup> Bug #1682139 changed: AttributeError: 'ACKDatagram' object has no attribute 'mode'  <MAAS:In Progress by andreserl> <https://launchpad.net/bugs/1682139>
<mup> Bug #1682141 changed: [2.2.0rc2, UI, Images] In custom source when I add invalid URL format the error message is too disconnected from the field, has wrong icon, needs wording update <ui> <MAAS:New> <https://launchpad.net/bugs/1682141>
<mup> Bug #1682139 opened: AttributeError: 'ACKDatagram' object has no attribute 'mode'  <MAAS:In Progress by andreserl> <https://launchpad.net/bugs/1682139>
<mup> Bug #1682141 opened: [2.2.0rc2, UI, Images] In custom source when I add invalid URL format the error message is too disconnected from the field, has wrong icon, needs wording update <ui> <MAAS:New> <https://launchpad.net/bugs/1682141>
<mup> Bug #1682148 opened: [2.2.0rc2, UI, Machine details] In interfaces table, the error placement for invalid input doesn't follow the pattern <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1682148>
<mup> Bug #1682150 opened: MAAS node memory detection problem : 0.0GiB  <MAAS:New> <https://launchpad.net/bugs/1682150>
<mup> Bug #1682148 changed: [2.2.0rc2, UI, Machine details] In interfaces table, the error placement for invalid input doesn't follow the pattern <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1682148>
<mup> Bug #1682150 changed: MAAS node memory detection problem : 0.0GiB  <MAAS:New> <https://launchpad.net/bugs/1682150>
<DesktopMan> hmm think I found a race condition in commisioning. The IPMI-password is changed before commissioning completes, commisioning fails (couldn't contact apt-repository), and now I can't control the machine from MAAS any more
<mup> Bug #1682148 opened: [2.2.0rc2, UI, Machine details] In interfaces table, the error placement for invalid input doesn't follow the pattern <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1682148>
<mup> Bug #1682150 opened: MAAS node memory detection problem : 0.0GiB  <MAAS:Incomplete> <https://launchpad.net/bugs/1682150>
<mup> Bug #1682152 opened: [2.2, UI] Deploy action options are misaligned <regression> <MAAS:Triaged by ricgard> <https://launchpad.net/bugs/1682152>
<mup> Bug #1682152 changed: [2.2, UI] Deploy action options are misaligned <regression> <MAAS:Triaged by ricgard> <https://launchpad.net/bugs/1682152>
<mup> Bug #1682152 opened: [2.2, UI] Deploy action options are misaligned <regression> <MAAS:Triaged by ricgard> <https://launchpad.net/bugs/1682152>
<go0fy42> Hiâ¦ I have a machine, which seems to deploy just fine (curtin successfully completes) but then just hangs on the reboot wth âBooting local diskâ¦ Bootingâ¦â. If I reconfigure the BIOS to just skip network booting the server boots just fine into the newly deployed OS.
<go0fy42> How do I go about troubleshooting this?
<mup> Bug #1682163 opened: [2.2.0rc2, UI, Images] In custom source when I add invalid URL format the error message wording needs to be updated <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1682163>
<mup> Bug #1682163 changed: [2.2.0rc2, UI, Images] In custom source when I add invalid URL format the error message wording needs to be updated <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1682163>
<mup> Bug #1682163 opened: [2.2.0rc2, UI, Images] In custom source when I add invalid URL format the error message wording needs to be updated <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1682163>
<mup> Bug #1682174 opened: [2.2.0rc2, Responsive, Nodes] Select all checkbox label wraps in a new row and the checkbox sits on top of the label  <ui> <MAAS:Triaged by ricgard> <https://launchpad.net/bugs/1682174>
<mup> Bug #1682189 opened: [web UI] Image OS shows up twice in dropdown when deploying <docteam> <MAAS:Triaged> <https://launchpad.net/bugs/1682189>
<mup> Bug #1682204 opened: When using LVM, wrong partition type code is used <MAAS:New> <https://launchpad.net/bugs/1682204>
<mup> Bug #1682204 changed: When using LVM, wrong partition type code is used <MAAS:New> <https://launchpad.net/bugs/1682204>
<mup> Bug #1682206 opened: [2.2 rc1] commissioning does not timeout for systems that fail to PXE <oil> <MAAS:New> <https://launchpad.net/bugs/1682206>
<mup> Bug #1682251 opened: [2.2] Adding custom image with ddxz filetype seems to think it is root-tgz <MAAS:Triaged> <https://launchpad.net/bugs/1682251>
<mup> Bug #1682255 opened: [2.2] Removing a custom image yields misplaced confirmation message <MAAS:Triaged by ricgard> <https://launchpad.net/bugs/1682255>
<mup> Bug #1682290 opened: [2.2] Cannot delete custom image <MAAS:Triaged> <https://launchpad.net/bugs/1682290>
#maas 2017-04-13
<mup> Bug #1682317 opened: [2.1] Compact API request to get a limited set of information, such as hostname and system_id <MAAS:New> <https://launchpad.net/bugs/1682317>
<mup> Bug #1682374 opened: [2.2.0rc2, Responsive] The navigation does work on mobile <ui> <ux-qa-2.2> <MAAS:New> <https://launchpad.net/bugs/1682374>
<babbageclunk> brendand: ping?
<mup> Bug #1682379 opened: [2.2.0rc2, Responsive, Nodes] In the machine card, there is an empty row between Power state and status <ui> <ux-qa-2.2> <MAAS:New> <https://launchpad.net/bugs/1682379>
<mup> Bug #1682387 opened: [2.2.0rc2, Responsive, UX improvement] When the owner has not been assigned to a machine the value should be "(Unassigned)" instead of empty <ui> <ux-qa-2.2> <MAAS:New> <https://launchpad.net/bugs/1682387>
<mup> Bug #1682390 opened: [Responsive, UX Improvement] The UX for machine selection and Take action needs to be improved <ui> <MAAS:New for m-vrachnis> <https://launchpad.net/bugs/1682390>
<mup> Bug #1682394 opened: [2.2.0rc2, Responsive] In controller details page, in the Events section there is a horizontal scrollbar <ui> <ux-qa-2.2> <MAAS:New> <https://launchpad.net/bugs/1682394>
<mup> Bug #1682395 opened: Custom images cannot be removed <MAAS:New> <https://launchpad.net/bugs/1682395>
<mup> Bug #1682394 changed: [2.2.0rc2, Responsive] In controller details page, in the Events section there is a horizontal scrollbar <ui> <ux-qa-2.2> <MAAS:New> <https://launchpad.net/bugs/1682394>
<mup> Bug #1682395 changed: Custom images cannot be removed <MAAS:New> <https://launchpad.net/bugs/1682395>
<mup> Bug #1682394 opened: [2.2.0rc2, Responsive] In controller details page, in the Events section there is a horizontal scrollbar <ui> <ux-qa-2.2> <MAAS:New> <https://launchpad.net/bugs/1682394>
<mup> Bug #1682395 opened: Custom images cannot be removed <MAAS:New> <https://launchpad.net/bugs/1682395>
<mup> Bug #1682399 opened: [2.2.0rc2, Responsive, Secondary nav] The secondary nav in Nodes listing/machine details has different selected style than the secondary nav in controller details page. <ui> <ux-qa-2.2> <MAAS:New> <https://launchpad.net/bugs/1682399>
<mup> Bug #1682403 opened: [2.2.0rc2, Responsive, Machine details] In the Commissioning section there is a small part of a card that appears on the screen <ui> <ux-qa-2.2> <MAAS:New> <https://launchpad.net/bugs/1682403>
<mup> Bug #1682406 opened: [2.2.0rc2, Responsive, Machine details] The confirmation buttons for the take action actions are not full width <ui> <ux-qa-2.2> <MAAS:New> <https://launchpad.net/bugs/1682406>
<mup> Bug #1682432 opened: [web UI] New user dashboard link instability <docteam> <MAAS:Triaged> <https://launchpad.net/bugs/1682432>
<mup> Bug #1682141 changed: [2.2.0rc2, UI, Images] Invalid URL in custom Image source error is disconnected from field and wrong icon. <ui> <MAAS:Won't Fix by ricgard> <https://launchpad.net/bugs/1682141>
<mup> Bug #1682141 opened: [2.2.0rc2, UI, Images] Invalid URL in custom Image source error is disconnected from field and wrong icon. <ui> <MAAS:Won't Fix by ricgard> <https://launchpad.net/bugs/1682141>
<mup> Bug #1682141 changed: [2.2.0rc2, UI, Images] Invalid URL in custom Image source error is disconnected from field and wrong icon. <ui> <MAAS:Won't Fix by ricgard> <https://launchpad.net/bugs/1682141>
<mup> Bug # opened: 1682476, 1682483, 1682489, 1682490
<Teejay> Hello everyone
<mup> Bug #1682395 changed: [2.2 UI] Custom images cannot be removed <MAAS:Triaged> <https://launchpad.net/bugs/1682395>
<mup> Bug #1682395 opened: [2.2 UI] Custom images cannot be removed <MAAS:Triaged> <https://launchpad.net/bugs/1682395>
<mup> Bug #1682395 changed: [2.2 UI] Custom images cannot be removed <MAAS:Triaged> <https://launchpad.net/bugs/1682395>
<mup> Bug #1682661 opened: [2.1.5] MAAS should be able to route to BMCs <MAAS:Incomplete> <https://launchpad.net/bugs/1682661>
<mup> Bug #1682663 opened: [2.2] Subnets list does not update when a VLAN's space is changed <regression> <ui> <MAAS:Triaged by mpontillo> <https://launchpad.net/bugs/1682663>
#maas 2017-04-14
<Hetfield> good morning. i have an issue with maas deploying a physical lenovo node. if i boot in UEFI mode, pxe, commission and deploy a 16.04 image it doesn't boot saying: No MBR magic. Warning: treating disk as raw.
<Hetfield> if i go in uefi mode, i get the grub2 prompt with local and it complains about not finding /efi/ubuntu/shimx64.efi
<Hetfield> any idea?
<Hetfield> no one?
<mup> Bug #1682661 changed: [2.1.5] MAAS should be able to route to BMCs <MAAS:Invalid> <https://launchpad.net/bugs/1682661>
<mup> Bug #1682661 opened: [2.1.5] MAAS should be able to route to BMCs <MAAS:Invalid> <https://launchpad.net/bugs/1682661>
<mup> Bug #1682661 changed: [2.1.5] MAAS should be able to route to BMCs <MAAS:Invalid> <https://launchpad.net/bugs/1682661>
<mup> Bug #1682823 opened: Package repositories feature lacks profiles <docteam> <MAAS:Triaged> <https://launchpad.net/bugs/1682823>
<vogelc> kiko: I was researching using maas to deploy esxi, I found a post from you back in 2015 talking about it.  Has there been any additional discussions or development of the feature?
<cnf> vogelc: if you find out how, please do tell me :P
<Guest21759> any maas expert here?
<mup> Bug #1682938 opened: [2.1.3] maas cli cannot delete a partition <MAAS:New> <https://launchpad.net/bugs/1682938>
<mup> Bug #1682938 changed: [2.1.3] maas cli cannot delete a partition <MAAS:New> <https://launchpad.net/bugs/1682938>
<mup> Bug #1682938 opened: [2.1.3] maas cli cannot delete a partition <MAAS:New> <https://launchpad.net/bugs/1682938>
#maas 2017-04-15
<mup> Bug #1683047 opened: MAAS 2.2 generates duplicate zone records if overlapping subnets are used which leads to bind9 failures: '36.232.10.in-addr.arpa': already exists previous definition <MAAS:New> <https://launchpad.net/bugs/1683047>
#maas 2018-04-09
<mup> Bug #1762344 opened: JS tests random failure with "test caused a page reload" error <MAAS:New> <https://launchpad.net/bugs/1762344>
<mup> Bug #1762461 opened: [2.4] MAAS becomes unresponsive when there's RPC errors <MAAS:New> <https://launchpad.net/bugs/1762461>
<srihas> hi guys, I am new to maas. Is there a way that I can change the default DNS record "maas(default)" to a custom record?
<Hey_> is there a way to exclude subnets from the Dashboard?
<Hey_> Also.. why do I not see Observed Nodes in the Dashboard?
<roaksoax> Hey_: you can disable active discovery from the dashboard, but only if active discovery is enabled
<roaksoax> srihas: yes, change the domain name over the api
<srihas> roaksoax: "over the api" means? :)
<roaksoax> srihas: you can update the domain name over the api
<Hey_> roaksoax: But I have 3 subnets.. I only want to disable it for 2 subnets
<srihas> roaksoax: as GUI talks over API. it can update as well, right?
<roaksoax> Hey_: you can do that under each subnet if active discovery is enabled. passive discover only listens for arp broadcasts
<roaksoax> srihas: the GUI doesn't support changing the domain name
<roaksoax> srihas: you have to do it via the API (or the CLI, which is just a client to the API)
<srihas> roaksoax: aha, I will look for commands, thank you
<srihas> one more thing, I cannot delete "fabric-1" , its showing like "Can't delete fabric; the following interfaces are still connected: eth0 (unknown) on <unknown-node>"
<srihas> can it be forced from CLI as well?
<Hey_> roaksoax: so.. under subnet, I should Enable Managedallocation and disable active mapping?
<Hey_> at the moment.. I have them bot disabled for the subnets I don't want to see in Dashboard
<Hey_> Managed Allocation, Active Mapping / Disabled
<roaksoax> Hey_: you can't disable passive discover per subnet
<roaksoax> Hey_: becuase that listens to arps across all the network
<roaksoax> Hey_: you can only disable "active" mapping, which either does ping or nmap on your subnet
<Hey_> roaksoax: ohh.. understood.
<roaksoax> Hey_: so you could enable active mapping in the settings page, but disable it on the subnets you want disabled
<roaksoax> Hey_: IIRC, that should not do "passive" mapping
<Hey_> roaksoax: under the subnets..I see observed nodes.. but I don't see some of those nodes in the dashboard
<roaksoax> Hey_: there's an open bug for that, but those obversed nodes are nodes that dhcpd' from maas
<Hey_> I want to image those
<Hey_> roaksoax, do I need to create a comissioning script for my custom win10 image?
<Hey_> The partition scheme is default
<roaksoax> Hey_: windows images are only support if created by canonical
<Hey_> roaksoax, I was able to create an image successfully.
<Hey_> ohh.. your saying you won't discuss it.
<Hey_> understood.
<mup> Bug #1762555 opened: ipmi-config connection timeout <ipmi> <maas> <maas (Ubuntu):New> <https://launchpad.net/bugs/1762555>
<mup> Bug #1762555 changed: ipmi-config connection timeout <ipmi> <maas> <maas (Ubuntu):Incomplete> <https://launchpad.net/bugs/1762555>
<wdennis> Two MAAS 2.3 questions:
<wdennis> 1) Once deployed, can the machines be disassociated from MAAS? (i.e., not try to cloud-init contact the MAAS server)
<mup> Bug #1762555 opened: ipmi-config connection timeout <ipmi> <maas> <maas (Ubuntu):Incomplete> <https://launchpad.net/bugs/1762555>
<roaksoax> wdennis: sure, you should be able to uninstall cloud-init from the deployed machine
<roaksoax> wdennis: a deployed system, AFAIK,is not re-running anything in cloud-init on boot
<wdennis> 2) there's just no way of spec-ing a different root disk partition?
<wdennis> roaksoax: It seems that cloud-init drops a .cfg file into /etc/network/interfaces.d that will have the wrong IP for my target deploy network... Have to re-write/erase it
<roaksoax> wdennis: for ubuntu there is
<roaksoax> wdennis: ? cloud-nit should be writing correct networking based on what maas is configured
<wdennis> It does write correct Ip for the network I do OS installs on, which is not the same as the target deployment network, which is elsewhere
<wdennis> Maybe MAAS is not the correct tool to do deploys for machines that will not stay connected to MAAS?
<wdennis> Also, it seems that the machine does run cloud-init each time it boots, but now where it's deployed, all the messages say "handlers.py[WARNING]: failed posting event: {...etc...}"
<roaksoax> wdennis: cloud-init, in maas or everwhere else, will run on first boot
<roaksoax> wdennis: that said cloud-init is configured to report back to maas messages
<roaksoax> wdennis: that's what you see there
<roaksoax> wdennis: after a mcahine is 'deployed'
<roaksoax> you can uninstall cloud-init
<roaksoax> wdennis: as far as the networking, i'm not quite sure what you mean nor have enough context of what you are doing
<wdennis> roaksoax: I'm deploying machines' OS on a lab network, then will post-configure them with Ansible on that same network, and then disconnecting them from that network, and deploying them on the target network which has no access to the lab (MAAS) network
<wdennis> I also now see that it configures Ubuntu to get updates from the (now-inaccessible) MAAS server
<wdennis> So, it seems like there's almost a requirement (perhaps assumption) that the delpoyed machine will stay in contact with the MAAS rack server
<roaksoax> wdennis: ok, so you disconnect the machine from the maas network and then you basically reconfigure networking ?
<wdennis> yes
<roaksoax> wdennis: ok, and is this with centos
<roaksoax> ?
<wdennis> No, Ubuntu
<roaksoax> wdennis: ok, and if you reconfigure the network, and you reboot the machine, it gets reconfigured back to how it ws deployed by MAAS and your changes are lost ?
<roaksoax> wdennis: on the updates part. MAAS configures an APT proxy. You *can* disbale the use of the proxy or you can change the proxy to a different one
<wdennis> No, I was not expecting (due to MAAS n00b status) that MAAS was dropping an interface config via cloud-init (which I'm also a n00b on) into /etc/network/interfaces.d, and also trying to post back cloud-init results to MAAS
<wdennis> So I have to re-write networking config (differently from what I was doing) and also 'apt-get purge cloud-*' to remove all the cloud-init stuff
<wdennis> SO I think I get what needs to be done there
<wdennis> Also need to remove the apt proxy
<wdennis> Now I'm wondering what else?
<wdennis> I'm just wondering if I'm fighting against the design of MAAS (i.e. if MAAS assumes continued connectivity/mgmt of the nodes it's deployed)
<wdennis> Was previously using Cobbler to deploy nodes, but it's not really that Ubuntu-friendly, and development seems to be on life support...
<wdennis> Cobblem didn't seem to assume ongoing connecitivity/mgmt of the nodes it deployed, though
<roaksoax> well, MAAS is a cloud-like system that has a metadata server
<roaksoax> so maas works very similarly to how instances in the cloud work via cloud-init
<roaksoax> wdennis: that said, it has sane defaults, like the proxy case (you can disable it in the Settings page)
<wdennis> Yup, I see... Cloud instances have an external controller by needs
<roaksoax> wdennis: right, the one thing, however, is that once the machine is deployed (after it boots for the first time onto the installed os)
<roaksoax> cloud-init just basically does nothing with MAAS
<wdennis> OK, except try to report back status, right?
<roaksoax> wdennis: yeah, but on if it failes to report status back, after it deployed, it doens't really matter since cloud-init wont really fial if it cannot report status back
<roaksoax> wdennis: you can see those messages in the machine event log (e.g. Machine details page > 'Events' tab
<mup> Bug #1762575 opened: bmc-config fails to set maas user password on Cisco IMC during commission on MAAS 1.9.5 <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1762575>
<mup> Bug #1762579 opened: HA region controllers offer different NTP servers <MAAS:New> <https://launchpad.net/bugs/1762579>
#maas 2018-04-10
<mup> Bug #1748010 changed: "Unconfigured" interface in MAAS becomes DHCP interface on deployed node <MAAS:Expired> <https://launchpad.net/bugs/1748010>
<mup> Bug #1762673 opened: maas insists on running the proxy, even when it's disabled <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1762673>
<mup> Bug #1762673 changed: maas insists on running the proxy, even when it's disabled <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1762673>
<mup> Bug #1762673 opened: maas insists on running the proxy, even when it's disabled <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1762673>
<mup> Bug #1762579 changed: HA region controllers offer different NTP servers <MAAS:New> <https://launchpad.net/bugs/1762579>
<mup> Bug #1762673 changed: maas insists on running the proxy, even when it's disabled <cdo-qa> <MAAS:Won't Fix> <https://launchpad.net/bugs/1762673>
<mup> Bug #1762673 opened: maas insists on running the proxy, even when it's disabled <cdo-qa> <MAAS:Triaged> <https://launchpad.net/bugs/1762673>
<bladernr> Hey guys, silly question, but in a MAAS subnet, if I set up a reserved range, say 172.0.0.1 to 172.0.0.100, MAAS WILL NOT issue any IP addresses from that range, correct?
<bladernr> also, if that range includes static assigned IPs for BMCs does that mean MAAS can no longer access those BMCs?
<bladernr> roaksoax, ^^
<bladernr> just trying to figure out why I suddenly can not access either BMC (directly) nor can MAAS.  It coudl be a lab issue though.
<mup> Bug #1762836 opened: 2.4 DHCP service not started till system restarted <MAAS:New> <https://launchpad.net/bugs/1762836>
<mup> Bug #1762836 changed: 2.4 DHCP service not started till system restarted <MAAS:New> <https://launchpad.net/bugs/1762836>
<Hey_> I cna't seem to comission a node.
<Hey_> Node says power On
#maas 2018-04-11
<ananke> my first time with maas, and a stack of dell PE R710 systems. all systems are set to boot from pxe, and they enlist then power off. mass doesn't seem to be able to power them back on for comissioning though
<ananke> it seems the nodes are shown in maas to use ipmi 2.0 over lan with IP 192.168.0.120, which is the default idrac setting. however, there are no interfaces on the maas controller that would talk to that subnet. what gives? shouldn't maas set the IPs for idrac during enlisting?
<mup> Bug #1754335 changed: [2.4, UI] Node action form takes a long time to disappear <ui> <MAAS:Invalid> <https://launchpad.net/bugs/1754335>
<Hey__> smartctl validate empty file  what does this mean?
<Hey__> I am hitting the ipmi successfully.
<Hey__> it says power on and its green
<Hey__> but when it tries to comission.. nothing happens.. or the result is it fails.
<Hey__> I manually added the node as I didn't see it in the Dashboared.
<mup> Bug #1754335 opened: [2.4, UI] Node action form takes a long time to disappear <ui> <MAAS:Incomplete> <https://launchpad.net/bugs/1754335>
<mup> Bug #1763010 opened: Block devices not discovered during commissioning <MAAS:New> <https://launchpad.net/bugs/1763010>
<mup> Bug #1763010 changed: Block devices not discovered during commissioning <MAAS:Invalid> <https://launchpad.net/bugs/1763010>
<parlos_> Good Morning
<mup> Bug #1763010 opened: Block devices not discovered during commissioning <MAAS:Incomplete> <https://launchpad.net/bugs/1763010>
<ananke> is maas supposed to set up automatically NAT between the controller and fabrics? my enlisting and comissioning fails, while the logs indicate that the nodes can't reach outside world
<ananke> documentation is a bit sparse, or perhaps I'm not looking in the right place
<roaksoax> ananke: nope
<roaksoax> ananke: maas won't setup NAT
<ananke> thank you, that may explain a lot of the issues I'm having
<ananke> looks like eventually the nodes fetch stuff directly from maas, presumably using it as a proxy. however, once enlisted, maas doesn't show any relevant data as to the amount of cores/mem/etc on the nodes. it does have the right IPMI setup, and it can power cycle them
<parlos_> Can/Does an deployed MAAS change/update how nodes are commissioned? Got a challenge... Suddenly nodes could not be commissioned, ended up in busybox... complaining some missing driver. But the nodes were commissioned before...
<parlos_> No change on my behalf.. and now, when testing the issue again, they commission just fine..
<ananke> parlos_: hah. I have yet been able to comission a single node
<ananke> each node boots, loads the image, but then logs on maas show a metric ton of ureadahead errors
<parlos_> Took me a while before I got it working too. Had a way too complicated network environment, >2 nics
<ananke> eg: Apr 11 14:13:45 fast-stork ureadahead[1052]: ureadahead:/usr/lib/tmpfiles.d/x11.conf: Error retrieving chunk extents: Operation not supported
<ananke> parlos_: I just have two nics: one for external network, another for internal (where all the nodes reside)
<parlos_> Is this at the first boot? I.e. pre-commisson?
<ananke> this is during comission. however, I'm not convinced enlisting works correctly either
<ananke> because the nodes don't show cores/cpu/etc in the maas interface
<parlos_> during enlistment it will not show any hw specs...(AFAIK)
<ananke> ahh, ok
<ananke> maas UI shows comissioning failed, and then for each module it has an empty log file
<parlos_> :(
<parlos_> do you have access to the console of the devices?
<parlos_> my experience from first MAAS deployment, was that viewing the console helped.
<ananke> I do, but I honestly am not sure what I would be looking at. for example the system just spent 5 mins waiting for something, then mass comissioning image proceeded with shutdown
<parlos_> in my case, the device, me and maas disagreed on what was the first interface. Hence, it did the enlistment on interface X, then during commisioning it thought X was now Y...
<parlos_> If it waits, then i guess it tries to reach an IP and it cant...
<ananke> so here's full dump of /var/log/maas/rsyslog/<sample node>/date/messages: http://ix.io/17wV
<ananke> I'm not sure if that's the right place to look at to determine what actual aspects of comissioning failed or not
<roaksoax> ananke: yes maas has a caching proxy and by default apt would attempt to use it unless you disabled it
<roaksoax> parlos_: could be a kernel issue
<parlos_> did not change kernel...
<ananke> roaksoax: nope, didn't disable it. however, it seems to try direct route first, before it tries the proxy. this is a fresh install of ubuntu 16.04 with maas 2.3.0
<parlos_> ananke, are there multiple boots in that log?
<ananke> parlos_: just one
<ananke> ~9 minutes from start to finish
<parlos_> Ok, its a bit confusing.. at 14:12:58 its looks that its the kernel boot, but prior to this we got ssh keys (before kernel??) could be wrong..
<ananke> parlos_: indeed, that does look confusing. however, that's how the rsyslog on the maas controller seems to have recorded this
<ananke> what user can I ssh as to the given node while it's being comissioned?
<parlos_> nope....
<parlos_> can you get a console via the BMC?
<ananke> so what's the point of having 'Allow SSH access and prevent machine from powering off' check box for comissioning?
<parlos_> dunno, have never tried it..
<parlos_> I have the luxury to use iDrac so I have console access..
<ananke> ahh: 'As long as you've added your SSH key to MAAS, you can simply connect with SSH to the node's IP with a username of ubuntu.'
<ananke> parlos_: these systems have idrac express, so no remote console
<parlos_> i got those too.. then I walk into the noisy room, and the KVM...
<parlos_> What is your network cfg?
<parlos_> for the nodes?
<ananke> I have a dozen R710s that we were going to surplus, and instead I figured I can try maas/openstack/openshift/whatever on them
<parlos_> :) got R715s..
<ananke> parlos_: i have one system to act as the maas controller. it has two NICs: external and internal. internal is connected to a basic switch with a flat network
<parlos_> and the nodes are connected to the switch with one nic, where is the BMC connecteD?
<ananke> the rest of the r710s are then connected to that switch, with their primary interface. i set them to use only pxe boot, from that first nic. idrac is set to be shared lan mode
<ananke> correct
<parlos_> did you disable the other nics?
<parlos_> (ok on idrac)
<ananke> nope, since my plan was to eventually use those other nics for something else (perhaps external network)
<ananke> and clearly, they do use that one interface, since they boot, get the initial image, and the maas controller receives logs from them
<parlos_> ok, my setup is similar. But nic2 is connected to another switch. 3+4 are disabled.
<ananke> so now the question is what exactly fails during the comissioning
<parlos_> agree, but the log is not clear...
<parlos_> Do you have some other HW  platform that you could test? as to see if there is an MAAS kernel to R710 issue?
<ananke> parlos_: unfortunately, not in that data center. I have another rack full of gear in another location, but I haven't finished the setup yet
<parlos_> I would however be surprised it it was a kernel-hw issue...  How are the discs configed?
<parlos_> hw raid?
<ananke> yes. perc 6i, two disks in each node with raid 1
<ananke> so a very basic setup
<ananke> I'll see if logging into the nodes while they're in the process of comissioning will yield any clues
<parlos_> not r710 directly, but another guy had an issue with HP dl380, and it was a bios issue..to new..
<ananke> I got all of the r710s up to bios 6.4.0/6.5.0, and tried to get all of the idracs updated too
<parlos_> There is an issue/bug at https://bugs.launchpad.net/ubuntu/+source/ureadahead/+bug/1628438
<parlos_> In MAAS does it list "Commision failed?"
<ananke> yes
<ananke> and I saw that bug earlier, sadly it leads to nowhere
<parlos_> I'd try to get console access, and view the output. From the syslog we do not see the thing that caused the Error that resulted in a fail...
<ananke> parlos_: I'm not sure I can even login to the console though
<parlos_> you dont have to login, just watch the output..
<ananke> as in, it's not like there is a login prompt
<ananke> that's the thing. there's nothing out of the ordinary. and comissioning failed errors appear on the maas controller long time before the nodes finish and shut down
<parlos_> It sounds to me that then node cannot properly talk to the maas server.. (for some reason).
<parlos_> afaik, so it boots, starts some actions (based on the tftp/pexe info), then as some point it need to talk to the maas. The maas waits for this, and if this does not happen
<parlos_> MAAS calls it failed, while the node timesout and tries again...eventually it gives up and shuts down.
<parlos_> ok,. have to go. Have a nice day, and good luck!
<srihas> hi guys, currently the network configuration on the depoloyed node is in /etc/network/interfaces.d/*.cfg rather than /etc/network/interfaces. Is there a way to tell MAAS to do it at  /etc/network/interfaces? thank you
<mup> Bug #1763059 opened: [2.4] DHCP is being configured on a rack controller that is not set to run DHCP <MAAS:In Progress by blake-rouse> <https://launchpad.net/bugs/1763059>
<roaksoax> srihas: no, network config is done by cloud-init and does it in interfaces.d/*.cfg
<roaksoax> parlos: hceck that rackd.conf:maas_url has the IP of the region instead of localhost
<srihas> roaksoax: I saw a bug that JUJU is looking at interfaces file, will it be a problem if I am going to dpeloy OpenStack with JUJU later on this node?
<roaksoax> srihas: juju should be handling e/n/i.d/*.cfg just fine
<srihas> roaksoax: thank you :)
<ananke> is there a way to login from the console of a system that's in the process of being comissioned, other than the ssh?
<ananke> ahh ffs, I see one of the potential problems
<ananke> when I hit 'comission', maas powers on the system. before that system has a chance to even fully POST, maas issues a forced reboot via the ipmi
<ananke> wtf
<ananke> then it claims they failed comissioning, while the nodes are booted into some maas image
<ananke> that's insane
<ananke> why would maas wait so little time for them to post? is that a configurable option?
<ananke> it power cycles them after roughly 60 seconds. that's crazy
<ananke> I feel like this is a bug, since I never configured any timeout settings in maas
<ananke> ahh ffs: https://bugs.launchpad.net/maas/+bug/1635107
<roaksoax> ananke: /win 4
<roaksoax> err
<roaksoax> sry
<mup> Bug #1763093 opened: Gateway can be choose in wrong subnet <MAAS:New> <https://launchpad.net/bugs/1763093>
<Hey__> when I add a physical interface to a node I'm about to comission, I see Error: node must be connected to a network.
<Hey__> Does the node need to have internet access?
<Hey__> I mean.. its connected to an internal network with no internet access
<roaksoax> Hey__: no
<roaksoax> Hey__: if it is to *commission* no
<roaksoax> if it is to deploy, yes
<mup> Bug #1763147 opened: [2.4, UI] Overall service status' not updating correctly <MAAS:Triaged by blake-rouse> <https://launchpad.net/bugs/1763147>
<mup> Bug #1763169 opened: [2.4, enhancement] Add UI option to allow/disallow proxy usage <MAAS:New> <https://launchpad.net/bugs/1763169>
<mup> Bug #1763169 changed: [2.4, enhancement] Add UI option to allow/disallow proxy usage <MAAS:Triaged> <https://launchpad.net/bugs/1763169>
<mup> Bug #1763169 opened: [2.4, enhancement] Add UI option to allow/disallow proxy usage <MAAS:Triaged> <https://launchpad.net/bugs/1763169>
<Hey__> roaksoax, under Nodes > Interfaces I geat an error it says Error: Node  must be connected to a network.  but the node is connected
<bladernr> roaksoax, blake_r, newell_ do you guys remember what file is handed out when a Power8 box PXE boots via MAAS?  is it the same pxelinux.0 file that x86 gets?
<bladernr> or does it get a different file in /var/lib/maas/boot-resources/*
<newell_> bladernr: power8 uses powernv afair
<newell_> bladernr: which uses petitboot...which is the binary bootloader so no pxelinux.0 file needs to be downloaded.
<bladernr> hrmmm... yeah, that's what I recall.  I'm looking at an openpower box (well, looking at a dump of the petitboot menu) and it's grabbing pxelinux.0 from MAAS.
<bladernr> and then complains that some temp file is not a valid ELF binary
<bladernr> meh, was just checking, the whole thing's a bit of a mess.
<bladernr> thanks!
<roaksoax>  bladernr: /var/lib/maas/dhcpd.conf will tell you what file is for power 8
<bladernr> ahhh thanks roaksoax that's the confirmation I needed.
<roaksoax> bladernr: https://pastebin.ubuntu.com/p/fKNqvd9v7G/
<Hey__> I am having problems commissioning nodes.  I don't see the node in the Dashboard, I only see it in Observed under subnet. So I add it manually. adding the ipmi interfaces
<Hey__> When I Select Commission, it runs for a while then fails.
<Hey__> What logs do I check to see what the issue is?
<Hey__> Events show Queried node's BMC - Power state quried o:on
<Hey__> what power type do I use for hyper-v?
<Hey__> ohh..i see. for that VM, I had to do it manually
<mup> Bug #1763214 opened: [2.4, UI, vanilla]  Zone details page not formatted correctly <vanilla-transition> <MAAS:Triaged> <https://launchpad.net/bugs/1763214>
<mup> Bug #1763215 opened: [2.4, UI, vanilla] Group by on 'Subnets' tab is wrapped <vanilla-transition> <MAAS:Triaged> <https://launchpad.net/bugs/1763215>
<mup> Bug #1763216 opened: [2.4, UI, vanilla] Subnet in interfaces table is gone <vanilla-transition> <MAAS:Triaged> <https://launchpad.net/bugs/1763216>
<mup> Bug #1763217 opened: [2.4, UI, vanilla] Delete subnet text is wrapped and missing warning icon <MAAS:Triaged> <https://launchpad.net/bugs/1763217>
<mup> Bug #1763218 opened: [2.4, UI, vanilla] Delete range (inside subnet) text is wrapped <MAAS:Triaged> <https://launchpad.net/bugs/1763218>
<mup> Bug #1763219 opened: [2.4, UI, vanilla] Delete fabric confirmation text is misplaced <vanilla-transaition> <MAAS:Triaged> <https://launchpad.net/bugs/1763219>
<mup> Bug #1763220 opened: [2.4, UI, vanilla] Compose pod action form has misplaced buttons <MAAS:New> <https://launchpad.net/bugs/1763220>
#maas 2018-04-12
<mup> Bug #1761601 changed: [2.4] Multiple region/rack controller failures cause the UI to be very slow <MAAS:Triaged by ltrager> <https://launchpad.net/bugs/1761601>
<parlos> Good Morning!
<parlos> @ananke did you find a solution?
<mup> Bug #1763307 opened: MAAS unable to send power off to the node after commissioning it <MAAS:New> <https://launchpad.net/bugs/1763307>
<ananke> parlos: I did. it's a known bug with ipmi timeouts while booting dell systems with idracs in a shared mode
<ananke> parlos: https://bugs.launchpad.net/maas/+bug/1635107
<parlos> Great, so I should just be lucky that my shared idracs have worked out. :)
<ananke> parlos: interesting that you didn't run into that problem
<ananke> parlos: in my case I noticed that maas would power cycle the nodes roughly 60 seconds after turning them on. which is insane, because it's not even close to the amount of time required to POST
<ananke> and afterwards, eventhough they booted to something from maas, maas didn't consider that as a valid comissioning
<mup> Bug #1763307 changed: MAAS unable to send power off to the node after commissioning it <MAAS:Invalid> <https://launchpad.net/bugs/1763307>
<roaksoax> ananke: that indicates there's a firmware issue
<roaksoax> ananke: if the firmware is taking that log
<roaksoax> ananke: if the firmware is taking that long
<roaksoax> ananke: we have idrac's in our CI testing environments and non of these expose these issues
<mup> Bug #1763010 changed: Block devices not discovered during commissioning <MAAS:Invalid> <https://launchpad.net/bugs/1763010>
<ananke> roaksoax: firmware is up to date. however, the combination of the bios power cycling the shared NIC _and_ typical switch registering connection is causing the timeout to be long enough for maas to consider it a failure
<ananke> clearly, it affects other people too. and this isn't the first time we see problems with shared idrac configuration. ironically enough, dell's own whitepaper on deploying maas specifically recommends using sharing nic setup
<ananke> I may try the dedicated NIC for idracs and see how that behaves
<roaksoax> ananke: what do you mean "sharing nic" ?
<roaksoax> ananke: does that share a nic with the OS ?
<ananke> roaksoax: idrac has two modes of operation: either dedicated NIC, or sharing the primary NIC with the system
<ananke> and yes, the shared nic configuration does use the same nic that the OS would have access to
<roaksoax> ananke: ugh!! that's ugly... i wouldn't use that at all IMHO
<roaksoax> ananke: probably dell recommends it becuase they want ppl to use the "features" they built
<roaksoax> but if they wanna use that, you might as well use AMT
<roaksoax> ananke: and yes that's likely to cause a lot of issues
<ananke> roaksoax: do you use the dedicated idrac port? does maas work correctly with it?
<roaksoax> ananke: yeah we dont use shared nic at all
<roaksoax> ananke: i have various dell systems in CI without shared nic config that work just fine
<ananke> https://linux.dell.com/files/whitepapers/Deploying_Workloads_With_Juju_And_MAAS-14.04LTS-Edition.pdf . ohh, I think I might have misread that
<roaksoax> ananke: some recent (*e.g. 1 year old)
<ananke> 'r, as they will be powered on and off via IPMI commands, so be sure to turn on IPMI
<ananke> over LAN. I'
<roaksoax> ananke: some older (2/3 year old) systems
<ananke> not sure why I thought this said to use in shared mode
<ananke> I just now need a larger switch. I got 12 nodes in the stack currently, adding a couple more, and I only have a 24 port switch there
<ananke> I wish the culprit of this issue was easier to identify though. maas itself offered little clue, other than the nodes 'failed' to commission
<srihas> hi guys, How can I configure a sub-interface for ex. eth1.824 using MAAS ?
<roaksoax> srihas: you need to add the vlan 824 in the same fabric
<Hey__> Using a hyper-v VM.. my commmisining passes, however, it does not find storage. Do i simply Add Special and mount the drive?
<srihas> roaksoax: i will try, thank you
<ananke> hah, fio tests start at 1:00:00, eventhough they haven't ran yet
<Hey__> Maas changed my ipmi user and password: https://bugs.launchpad.net/maas/+bug/1523611
<Hey__> when commissining
<Hey__> now it's frozen
<Hey__> This happenened during capture-lldp
<Hey__> This is the second time it's happened.
<Hey__> today
#maas 2018-04-13
<Hey__> l
<Hey__> h'
<mup> Bug #1763825 opened: [2.4, KVM, pod] Default storage pool is power configuration <MAAS:In Progress by newell-jensen> <https://launchpad.net/bugs/1763825>
<mup> Bug #1763828 opened: [2.4] Storage Available disks and partitions table in machine details incorrect formatting <vanilla-transition> <MAAS:New> <https://launchpad.net/bugs/1763828>
<mup> Bug #1763831 opened: [2.4] Details page actions (e.g. machine details) has all actions instead of actions per status <vanilla-transition> <MAAS:Triaged by ya-bo-ng> <https://launchpad.net/bugs/1763831>
<mup> Bug #1763831 changed: [2.4, UI, regression] Details page actions (e.g. machine details) has all actions instead of actions per status <MAAS:Triaged by ltrager> <https://launchpad.net/bugs/1763831>
<mup> Bug #1763831 opened: [2.4, UI, regression] Details page actions (e.g. machine details) has all actions instead of actions per status <MAAS:Triaged by ltrager> <https://launchpad.net/bugs/1763831>
<mup> Bug #1763835 opened: [2.4, regression] Action errors are being shown as notifications <vanilla-transition> <MAAS:Triaged> <https://launchpad.net/bugs/1763835>
<roaksoax> /win/win 4
#maas 2020-04-06
<mup> Bug #1871003 opened: Update status_message to include latest "Mark broken" message <ui> <websocket-api> <MAAS:New> <https://launchpad.net/bugs/1871003>
<mup> Bug #1871021 opened: Mark broken / fixed issues <broken> <dhcp> <fixed> <mark> <MAAS:New> <https://launchpad.net/bugs/1871021>
<mup> Bug #1871021 changed: Mark broken / fixed issues <broken> <dhcp> <fixed> <mark> <MAAS:New> <https://launchpad.net/bugs/1871021>
<mup> Bug #1871021 opened: Mark broken / fixed issues <broken> <dhcp> <fixed> <mark> <MAAS:New> <https://launchpad.net/bugs/1871021>
<antonym> ltrager: k, yeah, i managed to use the packer templates and got one working, thanks
#maas 2020-04-07
<mup> Bug #1844544 changed: multiple gateways with ipv6 and routing-policy <ipv6> <MAAS:Expired> <https://launchpad.net/bugs/1844544>
<mup> Bug #1862103 changed: Cannot create KVM pod with bonded NICs <MAAS:Expired> <https://launchpad.net/bugs/1862103>
<mup> Bug #1844544 opened: multiple gateways with ipv6 and routing-policy <ipv6> <MAAS:Expired> <https://launchpad.net/bugs/1844544>
<mup> Bug #1862103 opened: Cannot create KVM pod with bonded NICs <MAAS:Expired> <https://launchpad.net/bugs/1862103>
<mup> Bug #1844544 changed: multiple gateways with ipv6 and routing-policy <ipv6> <MAAS:Expired> <https://launchpad.net/bugs/1844544>
<mup> Bug #1862103 changed: Cannot create KVM pod with bonded NICs <MAAS:Expired> <https://launchpad.net/bugs/1862103>
<mup> Bug #1844544 opened: multiple gateways with ipv6 and routing-policy <ipv6> <MAAS:Expired> <https://launchpad.net/bugs/1844544>
<mup> Bug #1862103 opened: Cannot create KVM pod with bonded NICs <MAAS:Expired> <https://launchpad.net/bugs/1862103>
<mup> Bug #1844544 changed: multiple gateways with ipv6 and routing-policy <ipv6> <MAAS:Expired> <https://launchpad.net/bugs/1844544>
<mup> Bug #1862103 changed: Cannot create KVM pod with bonded NICs <MAAS:Expired> <https://launchpad.net/bugs/1862103>
<mup> Bug #1864210 changed: no way to crash-cart the ephemeral - maas should pass ssh keys to ephemeral on boot <MAAS:Won't Fix> <https://launchpad.net/bugs/1864210>
<mup> Bug #1867935 changed: fix openwsman ftbfs (or remove openwsman and rdep wsmancli) <ftbfs> <rls-ff-incoming> <MAAS:Won't Fix> <openwsman (Ubuntu):Confirmed for ltrager> <wsmancli (Ubuntu):New> <https://launchpad.net/bugs/1867935>
<mup> Bug #1871356 opened: "maas init" doesn't create admin user <MAAS:Triaged> <MAAS 2.7:Triaged> <https://launchpad.net/bugs/1871356>
<mup> Bug #1871423 opened: MAAS snap can't parse the "BACKOFF" supervisord status <MAAS:New> <https://launchpad.net/bugs/1871423>
#maas 2020-04-08
<mup> Bug #1871582 opened: consider adding startsecs in supervisor "programs" configuration <MAAS:In Progress by ack> <MAAS 2.7:In Progress by ack> <https://launchpad.net/bugs/1871582>
<mup> Bug #1871584 opened: disabling DNS on the subnet where the regiond is breaks DNS <MAAS:New> <https://launchpad.net/bugs/1871584>
<mup> Bug #1871585 opened: subnet config option "Allow DNS resolution" is confusing <MAAS:New> <https://launchpad.net/bugs/1871585>
<mup> Bug #1674866 opened: Default gateway (per-subnet) should have a metric value <MAAS:New> <https://launchpad.net/bugs/1674866>
<mup> Bug #1674866 changed: Default gateway (per-subnet) should have a metric value <MAAS:New> <https://launchpad.net/bugs/1674866>
<mup> Bug #1674866 opened: Default gateway (per-subnet) should have a metric value <MAAS:New> <https://launchpad.net/bugs/1674866>
<mup> Bug #1871605 opened: Updating controller name shouldn't be allowed in the UI <ui> <MAAS:New> <https://launchpad.net/bugs/1871605>
<mup> Bug #1871606 opened: maas init hangs forever initializing database <MAAS:New> <https://launchpad.net/bugs/1871606>
#maas 2020-04-09
<mup> Bug #1871742 opened: Add owners_count to pod websocket object <websocket-api> <MAAS:New> <https://launchpad.net/bugs/1871742>
<mup> Bug #1871828 opened: Machines can't be commissioned/deployed if subnet.allow_dns is False <MAAS:Triaged> <https://launchpad.net/bugs/1871828>
<tosaraja> Shouldn't "maas <account> vlan read <fabric> <vid>" be "maas <account> vlan read <fabric> <id>" instead? The ID is the ID of the vlan, not the VID after all
<tosaraja> even the URL to that page is /MAAS/#/vlan/5001
<tosaraja> which is the ID and not the VID
#maas 2020-04-10
<mup> Bug #1872021 opened: commissioning fails due to hung tasks setting up ipmitool <MAAS:Incomplete> <ipmitool (Ubuntu):New> <https://launchpad.net/bugs/1872021>
<mup> Bug #1872021 changed: commissioning fails due to hung tasks setting up ipmitool <MAAS:Incomplete> <ipmitool (Ubuntu):New> <https://launchpad.net/bugs/1872021>
<mup> Bug #1872021 opened: commissioning fails due to hung tasks setting up ipmitool <MAAS:Incomplete> <ipmitool (Ubuntu):New> <https://launchpad.net/bugs/1872021>
<mup> Bug #1871606 changed: maas init hangs forever initializing database <MAAS:Invalid> <https://launchpad.net/bugs/1871606>
<mup> Bug #1674866 changed: Default gateway (per-subnet) should have a metric value <MAAS:Invalid> <https://launchpad.net/bugs/1674866>
<mup> Bug #1674866 opened: Default gateway (per-subnet) should have a metric value <MAAS:Invalid> <https://launchpad.net/bugs/1674866>
<mup> Bug #1674866 changed: Default gateway (per-subnet) should have a metric value <MAAS:Invalid> <https://launchpad.net/bugs/1674866>
