#maas 2013-05-20
<jtv> mgz: hi â would you be a good person to ask about the Tag model code in MAAS?
<mgz> yeah
<jtv> Excellent.  I was wondering why TagManager.get_nodes essentially duplicates NodeManager.get_nodes.  Was there a performance problem with the ordering of SQL "WHERE" constraints or something?
<mgz> not that I recall, probably just we weren't sure which would be more useful and ended up with both
<jtv> I suppose there would have been a comment if there were some compelling nonobvious reason...  I think I'll just eliminate the redundancy then.  Thanks.
<jtv> Could also be that it was written without a good "feel" for how filtering in this particular ORM works.
<mgz> I'd certainly expect tag getting nodes and getting nodes filtered on tag to generate equivalently performing sql
<jtv> Yes, ultimately the DB back-end ought to transform past any such ordering dependencies.
#maas 2013-05-21
<AskUbuntu> MaaS - Fatal Error inserting ipmi_si | http://askubuntu.com/q/298167
<AskUbuntu> Problem with node being "commissioning" and doesn't change to "ready" | http://askubuntu.com/q/298213
<roaksoax> rvba: howdy! was there something you needed me to take care of?
<rvba> roaksoax: hi;  yes, there is this problem with the saucy package, the maas services are not started by default for some reason.  Looks like something changed in upstart or something.
<roaksoax> rvba: ok, I'll investigate
<rvba> ta
<roaksoax> rvba: are *all* the services not being started?
<AskUbuntu> MAAS Node : Automatic Discovery - get [] list? | http://askubuntu.com/q/298367
<roaksoax> /win/win 15
<mwhudson> urgh
<mwhudson> why might pserv only be binding to localhost:tftp?
<mwhudson> that doesn't seem likely to be right
<mwhudson> brb
<mwhudson> what the heck
#maas 2013-05-22
<mwhudson> i deploy a node, the bootloader gets an ip address fine and it netboots but the installer fails to DHCP
<mwhudson> or rather, it doesn't think it's DHCPed successfully
<mwhudson> but i can ping it so...
<mwhudson> rraaaaaaaaararar
<bigjools> mwhudson: is your daughter at the keyboard again?
<mwhudson> no, just a slightly hacked off daddy
<mwhudson> bigjools: can you use maas-cli to release all nodes in one go?
<bigjools> mwhudson: I don't know off hand - I suspect not
<mwhudson> ok
<bigjools> we're adding mass-action support in the next week or so
<bigjools> at least in the UI
<mwhudson> well
<mwhudson> given that there is no ui at all for releasing ...
<mwhudson> you can parse json with awk, right?
 * mwhudson does evil
<bigjools> ha
<bigjools> roaksoax: did you backport raphael and yui3 to precise, or did we have to keep them in-tree for 1.2?
 * bigjools wonders about security updates ...
<mwhudson> aaaaaaaaaaaar
<mwhudson> bigjools: would you expect maas to support deploying raring to armhf yet?
<mwhudson> i see raring has appeared in the distro options
<mwhudson> but there's only precise and quantal in /var/lib/maas/ephemeral/
<bigjools> mwhudson: I don't know, it depends on whether the ephemeral images support it and that's largely out of my hands
<mwhudson> oh well
<mwhudson> i guess having
<mwhudson> RELEASES="precise quantal"
<mwhudson> in /etc/maas/import_pxe_files ain't gonna help
<mwhudson> bug 1115178
<ubot5> bug 1115178 in MAAS trunk "Raring ephemeral info not available on https://maas.ubuntu.com/images/" [Critical,Fix released] https://launchpad.net/bugs/1115178
<bigjools> http://maas.ubuntu.com/images/ephemeral/daily/raring/20130521/
<bigjools> images are there
<bigjools> the RELEASES are set deliberately tight otherwise you wait ages for a download of stuff you might never use
 * mwhudson chases bugs to https://bugs.launchpad.net/maas/+bug/1177932
<ubot5> Launchpad bug 1177932 in MAAS "Unable to select which pxe files to download by both series and architecture." [High,Triaged]
<bigjools> yeah that one's on our list of things to fix this cycle
<roaksoax> bigjools: they are speed with packaging
<roaksoax> shipped*
<bigjools> roaksoax: yeah, because they are in the tree :)
<bigjools> roaksoax: but what's the plan for security updates?
<roaksoax> bigjools: yeah so since they were removed on quabtal and i didn't wasn't to differ from that source then i had to put them in packaged as it was also recommended
<roaksoax> bigjools: for yui?
<bigjools> roaksoax: well anything that's in-tree but not packaged in precise
<bigjools> will the security team be aware and responsive?
<roaksoax> bigjools: evrything in 1.2 is in tree but the js files and i think python-tx-tftp
<roaksoax> but we dont need to keep python-tx-tftp in tree anymore
<bigjools> roaksoax: yes exactly - if there is any change to the upstream js we need a plan to fix it in maas
<roaksoax> bigjools: so yes if there's a security fix in yui or Raphael then it would need to be backported to raring quantal
<roaksoax> and precise on the maas packaging
<roaksoax> i think jdstrand is aware of us shipping the yui stuff there
<bigjools> roaksoax: will the maas-packaging be handled by the security team?
<bigjools> right
<bigjools> that's what I needed to know, thanks
<roaksoax> bigjools: so the branches wont be touchrd
<roaksoax> bigjools: the ones under ~maas-maintainers
<roaksoax> the securitu team works against the ones on the release
<roaksoax> so we are "upstream" for packaging
<roaksoax> so whatevrr fix that need to be backported will be done via patches on thr ubuntu packaging
<bigjools> right
<roaksoax> so say we fix something on 1.2, i will cherry pick and SRU as a patch in debian/patches
<bigjools> but we can include the same patch upstream
<roaksoax> bigjools: yes so i think we should fix upstream, and from there sru
<roaksoax> thats the normal procrss
<bigjools> cool
<roaksoax> bigjools: btw i would like to have a catch up call to agree in these thinga and see where you guys need ne
<roaksoax> me
<bigjools> roaksoax: sounds good
 * bigjools heads out for lunch
<rvba> roaksoax: that's right, none of the services are started.  I can start them manually (sudo service maas-pserv start) but they are not started right after the package gets installed.
<roaksoax> rvba: i installed saucy and then maas
<roaksoax> and all of the success seem to be running just fine
<roaksoax> upgrade saucy and test again
<rvba> that's weird, I just tested it with the daily pacakge (1.4+bzr1475+dfsg-0+1487+181~ppa0~saucy1).
<rvba> roaksoax: also (you'll tell me if it's normal or not) but ls /etc/init.d/maas*=> no file
<roaksoax> rvba: then maybe something change in upstream packaging and broke it?
<roaksoax> rvba: and i don't know, maybe something changed in upstart and is no longer creating that
<rvba> roaksoax: I suspect something changed in upstart indeedâ¦ but I was kinda relying on your expertise here :)
<rvba> roaksoax: If only I could get canonistack to work, then I could test with the latest saucyâ¦
<roaksoax> rvba: i'll tr again asi uploade\d something to sauycyc yesterday
<roaksoax> and shuldhave built with whatever is in saucy
<roaksoax> rvba: oh btw... there's what i believe a critical bug that needs attention
<rvba> roaksoax: which one?
<roaksoax> rvba: https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1153077
<rvba> roaksoax: btw, you said you had an output of lshw that was causing problems in MAAS.
<ubot5> Launchpad bug 1153077 in maas (Ubuntu) "rabbitmq queue fills up and celery stops executing tasks when upload_dhcp_leases is done every minute (by default)" [High,Confirmed]
<roaksoax> rvba: yes that too, let me get it
<smoser> roaksoax, ping
<smoser> i'm poking at a maas install... i basically dleted everything and upgraded to raring
<smoser> apt-get --purge remove maas-everythgin-here
<smoser> and then install maas
<smoser> booted nodes.
<smoser> they enlist fine
<smoser> but then i can't power them on as the ipmi detected creds are not correct
<roaksoax> smoser: let me think
<roaksoax> smoser: so during enlistment maas created the credentials
<smoser> yes. it did.
<roaksoax> smoser: they were sent back to maas
<roaksoax> smoser: but they don't work?
<smoser> the username that shows up in maas is 'maas'
<smoser> not 'maas-commission'
<roaksoax> smoser: that's correct
<smoser> well the user on the system is 'maas-commission'
<smoser> (per user lsit)
<roaksoax> smoser: right but maas should have create a user maas instead
<roaksoax> smoser: let me check
<roaksoax> smoser: ok, found the issue
<roaksoax> smoser: what is wrong with this: show_re = re.compile("Username.*%s\\b" % user)
<smoser> roaksoax, looks reasonable.
<roaksoax> smoser: doesn't seem to work, ANyway, I know how to fix it
<smoser> >>> bool(re.search("Username.*%s" % "maas", "Username foo"))
<smoser> False
<smoser> >>> bool(re.search("Username.*%s" % "maas", "Username maas"))
<smoser> True
<smoser> seems reasonable here.
<roaksoax> smoser: yeah but user=maas-commission, and that regex matches maas-commission *and* "maas"
<roaksoax> smoser: ok I have fixed it now
<roaksoax> smoser: you should be able to just enlist/commission and it will make suer that maas-commission is changed back to maas in the BMC
<smoser> well, enlist worked, but then maas doesn't power system on
<smoser> so i have to do that manually
<roaksoax> smoser: ok power them on manually and during the commissioning it will fix the user issue
<roaksoax> smoser: so for deployment they should be just fine
<smoser> whats the enlistment template
<roaksoax> smoser: ok so I started .17 to test this
<roaksoax> smoser: /usr/share/maas/preseeds/enlist_userdata
<smoser> whta is the enlistment template ?
<smoser> power on parameters do not affect the 'default' boot
<smoser> meaning i can't get '-- console=ttyS1,115200' to it
<smoser> roaksoax, you ahve to 'pxe-boot'. i'm not sure why, but they're not set to pxeboot
<smoser> and you didn't accept that node
<smoser> oh. you did do that.
<roaksoax> smoser: yeah just did the pxe-boot
<roaksoax> smoser: maas tells the machine to PXE when it controls them
<roaksoax> smoser: let me test in that node whether it worked or not
<smoser> that doesnt seem to work, roaksoax
<smoser> oh.
<smoser> i see
<smoser> well maybe it would have worked, but  maas can't power it on :)
<roaksoax> smoser: now it can:
<roaksoax> roaksoax@maas:~$ ipmipower -h 192.168.9.17 -u maas -p 3jaWUoCvrC34U --stat
<roaksoax> 192.168.9.17: off
<roaksoax> smoser: they either need to commission or enlisted again
<roaksoax> smoser: so that it gets fixed
<smoser> can i easily tell maas to forget all nodes ?
<roaksoax> smoser: i think so yes, I think allenap added a command to do so
<roaksoax> or maybe not
<smoser> and see question above... what is the preseed for "default" ?
<smoser> (enlist)
<smoser> er.. not preseed
<smoser> temlate. pxe boot template.
<roaksoax> smoser: what do you mean default?
<smoser> when its not known to maas
<smoser> and it boots into the enlistment
<smoser> what is that one
<roaksoax> smoser: the PXE template, should be this one: /usr/share/pyshared/provisioningserver/pxe/config.commissioning.template
<smoser> oh, really? that kind of sucks.
<roaksoax> smoser: file a bug and maybe we can get it changed
<smoser> i'll file a bug. you need to file one for your isssue that you sovled there also.
<smoser> Daviey, i think you had some script for "maas forget everythign"
<smoser> right ?
<Daviey> smoser: yes
<Daviey> delete-all ?
<Daviey> smoser: or you mean EVERYTHING?
<smoser> delete-all was it.
<smoser> did you have a "accept-all" ?
<smoser> never mind. i'll get it.
<smoser> roaksoax, is there a way to create a non-admin user ?
<smoser> from the cmdline
<smoser> and what is the difference from maas perspective on 'admin' ?
<smoser> rvba,
<Daviey> smoser: There was an accept all
<smoser> Daviey, just for later reference
<smoser> maas-cli maaslocal nodes accept-all
<smoser> roaksoax, did you open a bug ?
<smoser> i opened https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1182980
<ubot5> Launchpad bug 1182980 in maas (Ubuntu) "global parameters do not apply to enlistment" [Undecided,New]
<smoser> but you ened to open one for the issue you solved
<roaksoax> smosmofor my error yes just did (sorry i was caught up doing my first openstack mp)
<roaksoax> smoser: ^^
<smoser> roaksoax, do you know how to add a user other than 'admin" ?
<smoser> ie, there is maas createadmin
<smoser> but can i create *non* admin via cli?
<roaksoax> smoser: i don't think you can through the CLI
<smoser> roaksoax, so...
<smoser> i'm confused how maas interacts with dns
<roaksoax> smoser: ok...
<roaksoax> smoser: what confuses you?
<smoser> on this system, it seems to be somehow poopulating stuff in /var/lib/bind/
<smoser> but i'm not sure how
<roaksoax> smoser: did you wipe out the previous configuration?
<roaksoax> smoser: maas is not configured for DNS/DHCP
<roaksoax> [2013-05-22 21:07:08,910: INFO/PoolWorker-13] The DHCP leases file does not exist.  This is only a problem if this cluster controller is managing its DHCP server.  If that's the case then you need to install the 'maas-dhcp' package on this cluster controller.
<roaksoax> smoser: are you mlooking to manage DHCP/DNS with the MAAS server as well? there's no other DNS/DHCP server there right?
<roaksoax> smoser: IIRC, bind was manually configured by sabdfl to provide DNS
<roaksoax> don't know if that was kept
<smoser> well, something is odd.
<roaksoax> smoser: yes
<roaksoax> smoser: bind is manually configured
<smoser> becase timestamps on db.cloud in /var/lib/bind are very recent
<smoser> (2 hours ago)
<smoser> and i didn't touch those.
<roaksoax> smoser: yeah, it was manually configure
<Daviey> smoser: this is the manual integration i was saying.
#maas 2013-05-23
<roaksoax> bigjools: hey!
<bigjools> o/ roaksoax
<roaksoax> bigjools: so it is in my lsit to separate the the ipmi code into its own script
<bigjools> \o/
<roaksoax> bigjools: but since it needs to be used in both enlistment/commissioning, we need a way to make it available in both cases
<roaksoax> bigjools: which it seems that the easier way is to provide a maas-utils package
<roaksoax> that installs it
<bigjools> built from the maas source package?
<roaksoax> yep
<roaksoax> bigjools: i would also move the stuff from maas-enlist into that
<bigjools> is there any point doing that though, can't it just live in the cluster controller package?
<roaksoax> bigjools: no
<roaksoax> bigjools: how would you installit during vcommissioning/enlistment to be used?
<bigjools> oh sorry of course, it runs on the node
<bigjools> I'd rather keep this out of packages otherwise it locks core functionality into Ubuntu
<roaksoax> bigjools: why would it?
<bigjools> I still think templates are the way to go - and I'd be tempted to move maas-enlist too
<bigjools> because the node is required to install a package so it can program the bmc
<roaksoax> bigjools: i wanna put both maas-enlist & maas-ipmi-detect on a single place that can be re-used
<bigjools> I agree with that
<bigjools> I'm just not sure a package is the right place
<roaksoax> bigjools: well these are helper tools
<roaksoax> bigjools: either we source them somehow by both commissioning/enlistment preseeds
<bigjools> I'd say enlistment is more than a helper :)
<roaksoax> bigjools: the thing is thatat least maas-enlist can be used externally
<bigjools> I was thinking that we'd factor them into a single script that can be tested in its own right, and then pull that into the preseed template
<roaksoax> bigjools: and I would like to do the same with maas-ipmi-autodetect
<bigjools> or via metadata
<roaksoax> i guess we can do that, *but* i would still like to use them separately
<roaksoax> maas-enlist allows to remotely enlist a node
<bigjools> I have no objection to packaging them - but I do to making that the exclusive method for the node to get the code
<bigjools> seems like we agree :)
<roaksoax> and maas-ipmi-autodetect allows to configure them without having them in maas, but returns the credentials needed for maas, that can be sent with maas-enlist for example
<bigjools> right
<roaksoax> bigjools: ok, sounds good to me then, covering both escenarios is good
<bigjools> excellent!
<roaksoax> alright! i'm off
<roaksoax> have a good day :)
<bigjools> roaksoax: thanks - if you need help, just holler
<roaksoax> will do
<rvba> roaksoax: Hi Andres.  Sorry to bother you again with that problem but I really think there is a problem with the saucy daily package (the one in ppa:maas-maintainers/dailybuilds).  I tried installing it on a recent saucy instance on canonistack and I'm still not getting these services started.  Could you give me a hand with that?
<rvba> roaksoax: as you can see from the difference between the package (built from the same upstream and the same packaging branch) on precise and saucy, the services are not started on saucy but are fine on precise: http://paste.ubuntu.com/5692883/
<rvba> roaksoax: http://paste.ubuntu.com/5693704/ / http://paste.ubuntu.com/5693706/
<roaksoax> rvba i already looked and it is not the maas package
<rvba> roaksoax: oh?  What is it then?
<roaksoax> these are things that changed in Ubuntu related to how the init system is being handled
<roaksoax> so I'm looking into it
<rvba> Ah ok.  Thanks a lot.
<roaksoax> rvba: btw in you're backport announcement please clarify
<roaksoax> that there a new depencies thst will be uograded and new ones that are no in the precose archive which may cause other issues
<roaksoax> and that you guys are supporting/fixing bugs with any of those
<rvba> Well, I think the level of support is yet to be decided, it's just a ppa after all.
<roaksoax> rvba: right nut if you are telling users "use the latest with dependencies that are no in precise" you need to support that
<rvba> That's definitely not what I said.
<roaksoax> because theres bren cases wjere people report bugs in ubuntu
<roaksoax> when they are using ppa
<roaksoax> and they xould be reporting bugs out of new versions or packages that dont even exist in the release pocket of ubuntu
<roaksoax> tbh i would evem reduce that and would xontinue to ship yui in packaging for your backport and use python-txttftp from precise instead of ppa
<rvba> I understand.  Right now, the only thing that exist is a daily backport ppa.  Nothing more.  I really don't think it needs clarification about what kind of support we provide for that.
<roaksoax> i think it is important to minimize the delta
<rvba> Sounds sensible indeed.
<roaksoax> in caae we need to backport this to the actual release
<rvba> But tbh the yui package is really low risk.
<roaksoax> i agree but it os still a new pacakage not in ubuntu precise
<roaksoax> at least you need to clarify that in your email
<roaksoax> so users are aware how their systema can break
<rvba> If we were talking about package in the stable ppa, I would agree.  But this email was about a daily backport ppa, nothing more.  If a user decides to use a random package from a random ppa, there is not much we can do about it.
<rvba> But ok, I'll add a comment about the fact that we don't support it officially.
<rvba> roaksoax: done
<roaksoax> rvba: right, but my point being is that you need to warn your users what are the implications of them testing your "latest" stuff. Becuase you are telling them "hey use our latest stuff, we are making sure this is stable for you to use and we support it... it is backport" and then if something breaks, it would be "well... sorry.... you used a ppa..."
<roaksoax> rvba: so imho, users need to be aware of these things
<rvba> roaksoax: a *daily* ppa is obviously not something stable.
<roaksoax> rvba: right, but you are shipping extra dependencies that *are* "stable"
<roaksoax> rvba: that are *not* daily
<roaksoax> if you break users they are not gonna be happy and tyhey are going to blame *ubuntu*
<roaksoax> rvba: python-tx-tftp *is* in precise so you can also drop it from the PPA
<rvba> roaksoax: well, okay
<rvba> roaksoax: just checking that precise contains the right versionâ¦
<roaksoax> rvba: i had similar discussion with Daviey the other day in the fact that changes such as the GenericIpAddressField should have continue to be uspported in MAAS until the next LTS< so if we had to backport or even SRU MAAS again to Precise, we would have no other depndencies to worry about
<roaksoax> rvba: it does, has the same patches as what's in raring
<roaksoax> different version though
<roaksoax> rvba: i think freeipmi-tools is also *not* needed
<roaksoax> rvba: i would also suggest you remove juju from there and let users use it from juju
<roaksoax> rvba: i would also suggest you remove juju from there and let users use it from juju's ppa
<rvba> roaksoax: it's there so we can run the integration tests on that ppa.
<rvba> roaksoax: we have all the same packages in the daily (non-backport) ppa btw
<rvba> roaksoax: but obviously if some packages can be removed from these ppas (freeipmi-tools/python-tx-tftp) I'll do it.
<roaksoax> ok cool
<roaksoax> rvba: btw.. were you able to take a look to the celery/100% utilization bug?
<rvba> roaksoax: not yet, but one of us will have a look soon.
<roaksoax> cool thanks
<roaksoax> rvba: this is someone who is deploying in production has experienced
<smoser> roaksoax, how do i apply a tag to "all nodes" ?
<roaksoax> smoser: there's no way to do that
<roaksoax> rvba: ^^
<smoser> no?
<smoser> i thought you coudl just apply a xpath expression tthat essentiall matched '.'
<rvba> smoser: http://bazaar.launchpad.net/~maas-maintainers/maas/qa-lab-tests/view/head:/maas-integration.py#L523
<rvba> "definition=true()"
<rvba> That should do the trick.
 * rvba has to run.
<rvba> See you guys tomorrow!
<smoser> roaksoax, bother again
<roaksoax> smoser: shoot :)
<roaksoax> smoser: (btw.. above i mean, no "easy" way to do that)
<smoser> roaksoax, i'm not geting the right command line args to my nodes i dont think
<roaksoax> smoser: how so?
<adam_g> roaksoax, is there anythign that would override / rewrite  IPMI credentials i've manually set for a node via web ui
<adam_g> ?
<roaksoax> adam_g: commissioning would
<adam_g> roaksoax, but not provisioning, right?
<roaksoax> nope
<roaksoax> nothing would on provisioning
<adam_g> ok
#maas 2013-05-24
<frickler> hello
<frickler> i have a question about the maas service
<frickler> is it possible to run the environment ha ?
<frickler> is there any tutorial ?
<roaksoax> rvba: https://bugs.launchpad.net/ubuntu/+source/debhelper/+bug/1183807 --> that should fix the issues you were seeing on starting upstart jobs
<ubot5> Launchpad bug 1183807 in lxc (Ubuntu) "lxcbr0 is not created on package install" [High,Triaged]
#maas 2013-05-25
<AskUbuntu> newbie questions about ubuntu cloud, maas and storage | http://askubuntu.com/q/300005
#maas 2013-05-26
<subhranshu> Hello Everyone...
<subhranshu> I am trying to Deply MAAS and Juju base Openstack cluster on a 28 node infrastructure...
<subhranshu> Need Help
<subhranshu> Is it a right place to talk aout it
<subhranshu> about it>
#maas 2014-05-19
<jtv> gmb: that file was part of the simplestreams code drop, which lacked tests.
<jtv> We did some of the most basic cleanup, and there's an end-to-end test, but more unit tests are still needed.
<bigjools> gmb: loads of that import code is untested, we're adding it as we go
<bigjools> jtv: perhaps if you have some time you might want to take a look
<bigjools> https://code.launchpad.net/~julian-edwards/maas/report-subarches-in-bootimage/+merge/219987
<bigjools> at least someone please give me something I can work on tomorrow :)
<jtv> bigjools: is this just because when I commented on it earlier it was in the wrong channel, which _you_ picked?
<jtv> Or is this a different one?
<rvba> gmb: btw, I just noticed that you used django's BinaryField in BootSource.  It's all right but it means we now have 2 different BinaryFields in use: the one we created (back when the other one did not exist) and the one provided by Django.
<bigjools> jtv: same one
<jtv> If we had time, I'd love to look into abolition of our home-grown BinaryField...
<bigjools> jtv: doesn't need to be you, just *someone*, please!
<rvba> Yeah, that would be great.
<rvba> bigjools: I'll have a look later today.
<jtv> bigjools: as I said, needs documentation.  :)
<bigjools> jtv: next branch
<jtv> OK.  One thing that's still sadly lacking is a mention of what that meta file is _for_.
<jtv> (And if you're going to chide me for the terminal preposition, up shut)
<bigjools> jtv: an abomination up with which I shall not put
<jtv> On which, spot.
<jtv> It's awkward and off it pisses me.
<bigjools> I shall pop in some comments to explain for what the file is used
<jtv> Huh what?
<jtv> Oh, I see what you did there...
<jtv> bigjools: I think extract_image_params suffers a bit from the vagueness of that term "params."  It makes you call individual elements of params "param" despite it containing multiple parameters.
<jtv> Is there no more specific name you can give each of those dicts?
<bigjools> jtv: yes, like I said, the branch needs some tidying
<bigjools> it has evolved somewhat
<jtv> Just adding specifics, because you needed things to work on...
<bigjools> just bear in mind this is nothing I've added :)
<jtv> AFAICS "param" is new.
<bigjools> oh that bit yeah
<bigjools> well the function name started it I supposed
<bigjools> extract_image_params is returning a variable called... params.  Fancy :)
<bigjools> I need to EOD now, rather tired
<bigjools> all that coding has left me exhausted!
<jtv> Good night!
<bigjools> thanks for looking at the branch
<bigjools> I appreciate your comments
<jtv> Apart from the one about your face, obviously.
<jtv> Good night.  :)
<bigjools> you said nice things about it once
<jtv> You mean the one where it was too high for me to see?  :)
<bigjools> or maybe that was in one of your dreams
 * jtv wonders how bigjools would hear him talk in his sleep...
<bigjools> I am turning this PC off now before this gets too exciting
<jtv> *chuckle*
<bigjools> cheerio :)
<jtv> nn
<rvba> gmb: arg, it's getting worse: a BinaryField is non-editable.  Which means we can't use forms to accept base64-encoded input to change the value of that field.
<gmb> rvba: Damn.
<rvba> gmb: I'll figure a wayâ¦ but it will require changes to the modelâ¦
<gmb> Yeah.
<gmb> rvba: So, what about (this is horrible) storing the keyring data as a (base64-encoded) string, and using a file upload field to get the keyring data in there (and then dealing with the file behind the scenes).
<gmb> Could that work with the API/CLI?
 * gmb doesnât know whether we do file-stuff already within the CLI.
<rvba> I seem to remember the CLI supports file upload nowâ¦
<jtv> It does
<rvba> gmb: it would be better to figure out a way that work with Django's binary field though.
<rvba> works*
<gmb> rvba: Definitely. Iâll happily defer to your Django experience rather than my hacktastic approach :).
<jtv> gmb: BootSource.objects.get_boot_sources_for_cluster() takes more typing than doing the query yourself.  Maybe we should just have a 1:n attribute on NodeGroup.
<gmb> jtv: Totally WFM.
<gmb> jtv: Iâll stick a card on the board.
<jtv> Low priority though.  :)  This is tech debt.
<jtv> Fairly easy to pay off.
<gmb> Yeah.
<gmb> jtv: Actually, IIUI, it should be there already as NodeGroup.bootsources_set.
<gmb> But Iâd forgotten that when I wrote the function :)
<jtv> Might be, actually.  I forget whether that needed any work.
<gmb> I think itâs automatic.
 * gmb -> Dinner (by which I mean Northern âdinner,â which Southerners call âLunchâ).
 * jtv very confuse
<rvba> gmb: I think I spotted another problem.  We use a FilePathField for BootSource.keyring_filename.  If you have a look at the doc you'll see that this will validate against the *region*'s file system.  Where in fact this file only has meaning in the context of the cluster.
<jtv> I thought it was intended for use to refer to a region-side file..?
<jtv> IIRC the region then reads that file and sends the _contents_ to the import code.
<rvba> Then I don't understand why we have bot a keyring_filename and a keyring_data field.
<rvba> both*
<jtv> My understanding was: if you set a filename, it will get read from the filesystem every time the imports are run, which means the keyring could come with a package, and get automatic updates.
<jtv> Whereas if you have a custom keyring, you can pass the keyring contents centrally and have the import code use that instead, and you manage updates yourself.
<jtv> But I'm only guessing, really.
<rvba> That would make sense.  I'll let gmb confirm that it's what he had in mind.
<jtv> And document.  :)
<rvba> jtv: then I guess we need to think about migrating the config from the cluster's config file to the region's DB.  Because the meaning of the keyring_filename is changing (from a file on the cluster to a file on the region).
<jtv> I thought the plan was not to migrate those files.
<rvba> So, use the default?
<jtv> Yes, download the world.
<jtv> (For Precise/Trusty).
<jtv> With a UI for those who want to pare it down.
<rvba> I see.
<jtv> gmb: could you also confirm to us that there is no plan to migrate existing bootresources.yaml files?  I've been working on the assumption that we always start off with The World.
<jtv> (Things get a lot more complicated otherwise.)
<jtv> gmb: I see there's a card for removing parts of bootresources.yaml.  I'd just leave the file alone until we delete it.  Changing it further only invites yet more conflicts during upgrade.
<gmb> jtv: +1; that cardâs from before I knew what we needed to do :)
<jtv> OK
<jtv> And can you confirm that we have no plans to migrate existing bootresources.yaml settings?  It wasn't meant to be very end-user-ish anyway, so I'm not sorry.
<jtv> The initialisation code I have up for review gives a user a clean slate, even after upgrading.
 * jtv steps out for real
 * gmb -> switching locations
<jtv> allenap, gmb, rvba: I get the impression that "./bin/test.pserv provisioningserver.import_images.tests.test_boot_resources" actually downloads images...
<allenap> Belt, braces, and belly.
<jtv> It goes into the ppc64el boot method, whose install_bootloader starts downloading.
<jtv> allenap, gmb, rvba: fix is included in https://code.launchpad.net/~jtv/maas/no-bootresources-rewrite/+merge/220046 â who will review it for me?
<allenap> jtv: +1d
<jtv> Thanks!
<jtv> gmb: does the plan for ditching bootresources.yaml involve migrating existing config?
<gmb> jtv: It doesnât ATM. It definitely *could*, whether itâs an absolute necessity Iâm not sure.
<gmb> (I wonder how many people will have touched their bootresources.yaml)
<jtv> I see some complications, e.g. "should we also try to migrate from pre-existing images" and "must we go through an API exchange right before importing, just for this upgrade?"
<rvba> gmb: the API work for boot source is up for review.
<gmb> rvba: I saw. Thanks :). Thatâs going to be a nice task to take me to EoD :)
<rvba> gmb: good luck :)
<rvba> gmb: I'm sure you can leave some of it for Julian.
<gmb> Now thereâs a thoughtâ¦
<jtv> gmb: NodeGroup.bootsource_set.  :)
<AskUbuntu> not getting impi after installing 14.4 maas, and commisioning servers | http://askubuntu.com/q/469306
#maas 2014-05-20
<rvba> Thanks for the reviews gmb.
<gmb> np
<bigjools> jtv: ha, just had this discussion with gmb.  He sent mockups to the devel list
<bigjools> a while ago
<bigjools> rvba: FYI I just said to gmb not to bother with pushing keyring blobs through
 * gmb was about to type exactly the same thingâ¦
<rvba> bigjools: Do you mean getting rid of BootSource.keyring_data?
<bigjools> don't get rid of it, we just don't need it yet, a file will suffice
<bigjools> file name
<bigjools> because the keyring is already installed for all known sources as of this point in time
<rvba> Well, I already did the work in the API to support it.
<bigjools> how much is left to finish this then? I thought it wasn't near completion
<rvba> All the API for BootSource is done.  I need to add support for BootSourceSelection and we're done.
<jtv_> Leaving UI.
<rvba> Yeah, I'm only talking about the API.
<jtv_> Didn't mean to derail you there.
<rvba> Don't worry, you didn't :).
<jtv_> :)
<bigjools> [17:27:16] <bigjools> jtv: ha, just had this discussion with gmb.  He sent mockups to the devel list
<bigjools> jtv_: ^
<bigjools> bloody netsplits
<jtv_> Yeah.  That was my other nick.  I'll check email.
<bigjools> jtv_: they were sent a while ago
<bigjools> "Getting rid of bootresources.yaml (sort of)"
<bigjools> rvba, gmb: sorry, so how much work is left to push these keyring blobs through? gmb made it sound like a lot of work
<gmb> bigjools: My badâ¦ thereâs not a massive amount of work, itâs just tedioous.
<bigjools> and how do you plan on getting the keyring blobs *into* the DB?
<gmb> Maybe a dayâs worth.
<gmb> The only complex part is deciding where to write the keyring data out.
<gmb> s/complex/thinko-ridden
<gmb> bigjools: File upload, read the file, stick the contents in the DB
<bigjools> gmb: in the web UI?
<bigjools> what about the default config?
<bigjools> this is one of the reasons I was sceptical when I saw you were doing this :)
<gmb> bigjools: Default config will use the default cloud image keyring
<bigjools> gmb: and is that going to be installed on each appserver?
<gmb> Hmm, good point.
<bigjools> check the package dependencies
<bigjools> but I would seriously consider just using what's on the cluster machine for now
 * bigjools heads for dinner, back later
<gmb> k
<jtv_> What does the "remove default config file value for MIPF" mean exactly?
<rvba> jtv_: just changing the import script so that it doesn't use /etc/maas/bootresources.yaml by default.
<jtv_> Thanks.  I'll annotate the card.
<jtv_> Or, unless anybody minds, change it to "Wean import script off bootresources.yaml."
 * gmb -> location switch
<gmb> allenap: So, to clarify: weâre going to 1) Add a dependency for maas-region-controller->ubuntu-cloud-image-keyring ; 2) Read the cloud-image-keyring into the DB as part of ensure_boot_source on the cluster 3) Proceed as specified with blobbity stuff.
<gmb> allenap: I was a bit distracted at the end of the call; so could use confirmation from someone elseâs brain :)
<gmb> rvba, jtv: Your memories will also be more accurate than mine on this score ^^ :)
<jtv_> I don't think we can do that as part of ensure_boot_source_definition.
<jtv_> Didn't we say we'd just let the cluster register the installed keyring as a blob?
<jtv_> We can of course install a _region-side_ keyring in ensure_boot_source_definition.
<jtv_> As the default value, that is.
<jtv_> Re-reading in that light, I think the only thing I'm objecting to is where you say "on the cluster."
<gmb> jtv_: Sorry, I wasnât clear: âon the clusterâ meant âon the cluster model when the cluster is created"
<gmb> So the region is the canonical source for the keyring(s).
<jtv_> Right ho then.
<jtv_> It won't actually be on the cluster model, of course, but rather on the BootSource one.
<gmb> jtv_: Right. Complete confusion on my part.
 * gmb likes the throw-it-at-the-wall model of conversation
 * jtv_ learned the hard way about anchoring shared understanding
<gmb> Yeah.
<allenap> gmb: Yes, except for the bit about loading the keyring into the database. When a keyring is identified by a filename it should be, imo, loaded from that file.
<allenap> Every time, not cached in the database.
<AskUbuntu> Setting up MAAS on 14.04LTS Region + Cluster on same server DHCP not working | http://askubuntu.com/q/469649
<rvba> gmb: if you feel like reviewing the rest of the API work, I just put it up for review.
<gmb> rvba: I just saw :). Iâll take a look in a mo. Just unknotting something.
<rvba> Cool.
<gmb> allenap: I have a question about mocking for you.
<gmb> allenap: By which I mean âusing the mockâ module, not âbelittling peopleâ
<l1l> Ok folks, I am having a problem with maas-dns. The reverse dns isn't working and I am seeing a error in the celery-region.log
<l1l> rndc_command: Command `rndc -c /etc/bind/maas/rndc.conf.maas reload 16.172.in-addr.arpa` returned non-zero exit status 1:
<l1l> None
<AskUbuntu> Juju bootstraping gomaasapi timestamp error | http://askubuntu.com/q/469778
<AskUbuntu> JUJU MAAS Bootstrap all on VM | http://askubuntu.com/q/469810
<AskUbuntu> Can't Deploy Wordpress | http://askubuntu.com/q/469848
<phillw> Hi good people, I'm following http://maas.ubuntu.com/docs1.5/install.html#pkg-install and it seems very badly broken (the ppa doesn't work, the mass-dhcp and mass-dns do not exist. Is there a working set of instructions for installing cloud onto a trusty server?
<mwhudson> hm
<mwhudson> i definitely managed to install maas on trusty recently :-)
<phillw> mwhudson: well, any hints / tips or a set of working instructions would be gratefully received :)
<mwhudson> i'm trying to remember
<mwhudson> phillw: what do you mean maas-dns doesn't exist?
<mwhudson> it looks installable to me
<mwhudson> i'm not sure you need the ppa if you're running trusty but don't take my world for that
<mwhudson> well certainly you don't need the ppa to install it
<gaughen> mwhudson, phillw I am running trusty and have maas on my system.. maas-dhcp and maas-dns too (v1.5)
<phillw> the system reported back that I do not need the ppa, but it also could not find maas-dhcp or maas-dns
<gaughen> and yes, no ppa required
<mwhudson> phillw: can you pastebin the error message?
<phillw> it seems to have woken up!!!! 209 apps to install :)
<mwhudson> heh
<mwhudson> it's the usual thing, complain about something in public and it instantly fixes itself
<phillw> it is a very new VM, maybe it had not fully linked to the world :)
<phillw> and, it's not a typ, as I scrolled back through my commands to re-issue :)
<gaughen> phillw, I suspect it may not have been linked to the world because I just created a new vm with trusty and did an apt-get on those three packages and it's going fine
<gaughen> like mwhudson said complain in public and it fixes itself ;-)
<phillw> indeed... well it may be because I told the student eagerly awaiting it that I was going to bed and would have another attempt later today (I'm UK time)
#maas 2014-05-21
<AskUbuntu> juju sync-tools on maas 502 bad gateway error | http://askubuntu.com/q/469869
<jtv> gmb: the maas-devel mailing list might be a good place for design notes, so interested people can get some early notice of the coming changes.
<gmb> jtv: Agreed â thatâs why I started the original thread there in the first place. Iâll post my notes from the call presently.
 * gmb -> short break; bbiab
<gmb> jtv, rvba, allenap: https://code.launchpad.net/~gmb/maas/mipf-understands-blobs/+merge/220380 needs a review, if you have the time.
<jtv> gmb: by the way, I'm reviewing that branch.
<gmb> jtv: Sweet, thanks.
<jtv> gmb: more work to be done â with sincere apologies for being difficult.
<gmb> jtv: No worries; I did rather feel by the end of it like I was missing stuff, but I was getting tunnel vision. No such thing as too difficult; itâs how I learn to do better :)
<jtv> Ah yes, I recognise that feelint.
<jtv> feeling.
<jtv> Not the best keyboard, this.
<AskUbuntu> booting a node off san (iscsi storage) | http://askubuntu.com/q/470132
<rvba> Anyone available for a tiny review? https://code.launchpad.net/~rvb/maas/update-troubleshooting-doc/+merge/220423
<jtv> Oh I love seeing Launchpad's inline-review-comments feature improve between reviews.  One day I curse a shortcoming, the next I notice it's gone.
<jfarschman> @DaveHatton can you rpm -q and take a look?
<chris_____> I am trying to setup maas + juju lab on a esxi box.  All of nodes I am trying to join are on the same esxi host. Power type is virsh.  Power is the name of the VM i get from a virsh list --all.  What do i use for the power address?
<jhobbs> chris_____: see http://maas.ubuntu.com/docs/nodes.html
<chris_____> thanks
#maas 2014-05-22
<jtv> bigjools, up for a pre-imp?
<bigjools> jtv: sure
<jtv> Thanks. Calling...
<bigjools> distinct lack of notifications from google
<jtv> Wait till the call is over... everything will start ringing.
<gmb> jtv: Iâve fixed https://code.launchpad.net/~gmb/maas/mipf-understands-blobs/+merge/220380 per your excellent review. Thanks!
<jtv> gmb: did your diff just shrink radically or is it just the contrast to that big branch I've been looking at?
<gmb> jtv: Contrast, Iâm sure.
<jtv> gmb, one unaddressed note: shouldn't the "keyring" parameter to download_boot_resources now be "keyring_file" or somesuch?
<jtv> (Also, the docstring for download_all_boot_resources still documents "now")
<gmb> jtv: Good catch (on both counts).
<rvba> jtv: I'll review your remove-storage-setting branch.
<jtv> Thanks.
<rvba> jtv: why didn't you get rid of the config items (ConfigTFTP.resource_root and ConfigBoot.storage) completely?
<jtv> rvba: because I didn't want to be too radical.  I haven't looked into whether some weirdo out there might tweak the TFTP setting without tweaking the storage location.
<jtv> That's for the TFTP one.
<jtv> I didn't remove the one from bootresources.yaml because AFAIR that would just raise "unknown configuration item" errors in existing installations.
<rvba> Right, good point.
<rvba> It's a bit messy to leave unused config items like that but I guess we don't really have a choice.
<jtv> For the one in bootresources.yaml I console myself with the file's impending doom.
<jtv> gmb: should we now pass "sources" instead of "config" to the import code?  The answer may differ for the command-line script and the Celery task...
<gmb> jtv: Iâm working on that now. At the moment Iâm still passing âconfigâ â and trusting to the defaults in BootConfig to ensure that missing keys get filled in â but I think that the best thing to do as you say is pass âsourcesâ to import_images.
<gmb> jtv: In fact, the only other thing that import_images uses directly from config[âbootâ] is âstorageâ, and thatâs dead or dying, right?
<jtv> Dead.
<gmb> Wewt.
<jtv> So we _could_ just demand yaml for a list of sources.
<gmb> Yep.
<gmb> And that makes life much easier all round, actually.
<jtv> Of course if we then come back and add a new config option, we can't squeeze it into the list of sources.
<gmb> Mmm.
<gmb> jtv: Iâm tempted to say YAGNI. We want to do away with the direct run anyway, and all the configuration is about where to get stuff from and how to validate it.
<jtv> Agreed.
<gmb> Cool.
<gmb> jtv: Do you need that change (config->sources) for your current branch?
<jtv> gmb: I can do either way, but  obviously to have it would be easier.  I'm giong for lunch first though.
<gmb> jtv: I can get my branch up for review whilst youâre at lunch, with that change in place.
<jtv> Perfect.
<gmb> jtv: Ah, actually, scratch thatâ¦ for me to make that change Iâd have to essentially do what youâre doing now
<gmb> (re: storage)
<gmb> Oh, or is that branch in review?
<jtv> Mine?  No.
<jtv> The one that removes the storage setting is already landed.
<gmb> Ah, cool.
<gmb> jtv: So, yes, Iâll go ahead whilst you lunch :)
<jtv> Very well.
<AskUbuntu> how to find out what versions of maas maas-dns and maas-dhcp from terminal | http://askubuntu.com/q/470575
<gmb> jtv: Branch is up here: https://code.launchpad.net/~gmb/maas/config-becomes-sources/+merge/220621
<gmb> Feels oddly lightweight for some reason, but Iâm perhaps being paranoid.
 * gmb lunches
<jtv> gmb: approved, with thanks.
<jtv> Correction:
<jtv> "I'm terribly sorry, but I have taken the liberty to approve your branch.  Sorry!"
<rvba> Anyone up for a tiny packaging review? https://code.launchpad.net/~rvb/maas/add-pexpect/+merge/220630
<gmb> jtv: Haha. Iâm terribly sorry to have troubled you with the review, and intensely grateful that you were able to take the time out of your day :)
<jtv> gmb: to be honest, I wasn't so much apologising as establishing that your time was a consideration which wouldn't have been overridden without compelling need.
<gmb> jtv: How about we both just be grateful and move onâ¦ the English stand-off, as allenap will tell you, isnât conducive to actually doing anything.
<jtv> Right ho.
<jtv> "Don't ask to ask.  Don't apologise for apologising."
<rick_h_> I've been listenting to the tale of two cities on audible and would greatly admire if the two gentlemen could use an older and much prouder form of english to express such congenial discourse and gratitudes.
<jtv> Thou art full of the unmentionable.
<rick_h_> hah
<rvba> gmb: I thought this was called a "Canadian Standoff."
<jtv> eh?
<gmb> rvba: In Amerkiy, sure. But weâre in Europe now, old boy.
<rvba> heh
<rick_h_> Amerkiy?
<rick_h_> really?
<gmb> rvba, allenap, jtv: https://code.launchpad.net/~gmb/maas/celery-pass-blob-to-mipf/+merge/220650 could do with a review if you have a few minutes.
<jtv> I have one up as well.
<rvba> jtv: you do gmb's, I'll do yoursâ¦ deal?
<jtv> rvba: yup, was already doing it.
<jtv> Constructive sabotage: review somebody's branch to stop the next reviewer to come along from doing theirs before yours.
<rvba> -rw-r--r-- 2 root root  23M May 22 14:04 boot-initrd
<rvba> -rw-r--r-- 3 root root 5.6M May 22 14:04 boot-kernel
<rvba> -rw-r--r-- 2 root root  19M May 22 14:04 di-initrd
<rvba> -rw-r--r-- 3 root root 5.6M May 22 14:04 di-kernel
<rvba> -rw-r--r-- 2 root root 1.4G May 22 14:03 root-image
<rvba> -rw-r--r-- 2 root root 301M May 22 14:04 root-tgz
<rvba> allenap: ^
<rvba> This is uncompressed.
<rvba> allenap: ~400Mb compressed.
<allenap> rvba: Cool, ta.
<jtv> allenap: ls isn't going to tell you the right sizes for sparse files
<jtv> tbh I don't even know whether wc will...
<jtv> rvba: not seeing your inline comments...
<rvba> o_O
<jtv> Ouch.  They're in the email but not in the MP.
<rvba> jtv: could it be that you pushed a new revision *after* I published them?
<rvba> In which case you need to use the dropdown at the top of th diff.
<jtv> Ah.  I pushed an update _before_ you posted, but apparently _after_ you loaded the page.
<jtv> (Just changing "path" to "url")
<rvba> Right.
<rvba> gmb: I'm investigating a problem in the lab where the import script fails to import images and I spotted a warning in celery's log:
<rvba> [2014-05-22 15:20:59,515: WARNING/Worker-4] Both a keyring file and keyring data were specified; ignoring the keyring file.
<rvba> gmb: looks related to the recent changes ^
<rvba> gmb: I suspect keyring_data = '' was used instead of the filename.
<gmb> rvba: Yeah, Iâve seen it too; itâs because the default value is an empty string. Iâll tweak it.
<rvba> gmb: matsubara filed https://bugs.launchpad.net/maas/+bug/1322256
<ubot5> Ubuntu bug 1322256 in MAAS "Import boot resources failing to verify keyring" [Critical,Triaged]
<gmb> k
<hamed> I am on maas 1.5.1+bzr2269 using Dell servers as nodes. Their powertype doesn't get detected. They are mostly poweredge 850,2850 and 1850. Manually starting the node will finish the commissioning but then JuJu can't start services on those nodes.
<gmb> rvba: This should fix that bug: https://code.launchpad.net/~gmb/maas/tweak/+merge/220689
<gmb> allenap: Thanks for the review.
<allenap> gmb: I got there in the end.
<gmb> allenap: It took me lots of back-and-forth to confirm that that fix actually did what I thought it did.
<gmb> So you werenât alone :)
 * gmb -> done for the day
<gmb> See you tomorrow folks.
<jtv> nn gmb
<AskUbuntu> Cannot Download Charm From juju-gui | http://askubuntu.com/q/470730
<lazyPower> Low hanging fruit for anybody that can lend a hand with MAAS networking - identified that this guy's setup stems from nodes not having network connectivity, where the master does  - it may be VMAAS instead of MAAS, unsure of topology: http://askubuntu.com/questions/469848/cant-deploy-wordpress/469852?noredirect=1#comment623061_469852
<phillw> hi good people, setting up a VM with MaaS 14.04 on a static IPv4 machine. Once I have finished the ubuntu server install sequence and edited the interface / gateway files (I can do that.. quite easy). How do I get the install to finish fully?
<phillw> Hi good people.... Using the ubuntu 14.04 server ISO and selecting MaaS install, it is incapable of handling a static ipV4 on a VM ? Any ideas?
<AskUbuntu> Ubuntu 14.04 LTS MAAS boot fails on fresh install on a Dell 2950 | http://askubuntu.com/q/470823
#maas 2014-05-23
<bigjools> mwhudson: did you manage to check my fix for https://bugs.launchpad.net/maas/+bug/1307779
<bigjools> ?
<ubot5> Ubuntu bug 1307779 in MAAS "fallback from specific to generic subarch broken" [Critical,Fix committed]
<mwhudson> bigjools: no
<mwhudson> i've more or less given up on armv7 :/
<bigjools> mwhudson: well hopefully if it doesn't work now I can blame the simplestreams data :)
<bigjools> ah
<mwhudson> bigjools: do you want me to try?  i can probably dig up the relevant details
<bigjools> well if it's important to you, sure
<bigjools> but not a big deal, I already checked the use case I was fixing
<mwhudson> ok
<mwhudson> i'll leave it for now then :)
<bigjools> no worries
<rvba> allenap: arg, your new lease parser didn't make it into 1.5.1 :/
<rvba> allenap: I think it would have made the DHCP bug less severe.
<allenap> rvba: How very annoying :-/
<rvba> allenap: If we get good feedback from the field about that fix, I think it's worth pushing for a 1.5.2 release.  The proper fix for the DHCP problem is going to take time and if the new parser alleviates the problem (and I think it does), it's worth releasing it.
<allenap> rvba: Is that something we talk to lutostag about?
<rvba> allenap: yeah, probably.
<rvba> Anyone up for a tiny review? https://code.launchpad.net/~rvb/maas/packaging.trusty-upstream-rev/+merge/220765
<jtv> I'll take it.
<jtv> Being nasty to someone might cheer me up.
<gmb> Aah, to https://bugs.launchpad.net/maas/+bug/1322336 is basically because we do the keyring writing in the wrong placeâ¦ damn. Iâll get on that now.
<ubot5> Ubuntu bug 1322336 in MAAS "import_boot_images crashes with KeyError on 'keyring'" [Critical,In progress]
<jtv> allenap, remember that occasional lock-related startup failure?  Any opinions on my guess as to the cause, i.e. ordering of decorators?
<allenap> jtv: I need to reread your analysis. Sorry I havenât replied sooner.
<jtv> allenap: I can sum it up very briefly right now if that makes it easier to digest.
<allenap> jtv: Sure :)
<jtv> "One decorator makes the function synchronous, another makes it grab a lock; but the ordering suggests that this means 1. grab lock, then 2. run synchronously."
<jtv> And so maybe the reactor goes on to run other tests during 1.
<jtv> Or wait, I mis-stated that.
<jtv> Maybe the reactor _already was_ running another test.
<jtv> Or maybe it just arbitrarily chooses to yield sometimes even though the lock is available.
<jtv> And so the test continues without actually having run that 'synchronous' function.
<allenap> jtv: I think the already-running-another-test hypothesis is the most likely of those.
<jtv> Either way, I guess we just can't expect the _call to_ that function to run synchronously even if we do have a right to expect _the function_ to run synchronously.
<rvba> jtv: thanks for the review.  Sorry that branch was so tiny; you didn't have much room to unleash your reviewing wrath ;).
<jtv> Yeah.  I'm all pent-up now.
<rvba> gmb: meanwhile, if you put your branch up for review, I'm happy to have a look at it while the test is running in the lab.
<gmb> rvba: Thanks. Iâll have the MP up presently.
<rvba> Cool.
<gmb> rvba: https://code.launchpad.net/~gmb/maas/bug-1322336/+merge/220783
<rvba> gmb: on it
<gmb> Thanks.
<gmb> jtv: Did you get a response from Alexis re: LXC?
<jtv> gmb: she forwarded, and there was one reply saying "that's easy innit," and I said I'd like to know from a real-life example of a problematic setup.  Nothing more.
<gmb> Ha.
<rvba> jtv: what's stopping us from deploying stuff on canonistack (with LXC) and testing the firewall ourselves?
<jtv> rvba: only the risk of not reproducing the real problem setup, as far as I know.
<gmb> rvba: Thanks for the review.
<rvba> np
 * gmb -> out for an early lunch.
<gmb> jtv, allenap, rvba: A review for someone, if you have a secâ¦ all code-removal: https://code.launchpad.net/~gmb/maas/bug-1322606/+merge/220800
<jtv> I'll take it.
<jtv> Ah, lovely conflicts coming.
<jtv> But I'll manage.
<jtv> Done.
<rvba> gmb: did you figure out what the problem was?  With the import task I mean.
<designated> does MAAS support aggregating NICs for using LACP, and VLAN tagging yet?
<designated> i remember reading it in the blueprint last year sometime
<AskUbuntu> How we can define more than 2 DNS server (IP) in MAAS? | http://askubuntu.com/q/471302
#maas 2014-05-24
<designated> I'm running ubuntu 14.04 and installed maas 1.5 (default).  I have configured everything according to the documentation and nodes will pxe boot and sit at the mass-enlisting login screen but the node never shows up in maas, nor does it shutdown automatically.  any ideas where to start troubleshooting?
<luttermann84> So... While trying to provision a server using MaaS, apt complained that the Packages file was gone! And it seens to be right, only Packages.bz2 and Packages.gz are avalible! What to do now?!
<luttermann84> (it's in the pxe boot/installation, so it's not possible to interact!)
#maas 2014-05-25
<AskUbuntu> juju bootstrap tries to get juju tools from amazon when in a maas enviroment | http://askubuntu.com/q/471718
<AskUbuntu> maas does not report to juju that the node is ready | http://askubuntu.com/q/471740
<AskUbuntu> juju spends bootstrap-timeout with a final message it cannot find /var/lib/juju/nonce.txt | http://askubuntu.com/q/471990
<AskUbuntu> juju handshake node error..why (juju.state open.g:93 TLS handshake failed: x509:certificate has expired or is not yet valid | http://askubuntu.com/q/472017
#maas 2015-05-18
<mup> Bug #1456188 was opened: Auto image import stacktraces <MAAS:In Progress by rvb> <https://launchpad.net/bugs/1456188>
<mup> Bug #1455560 changed: when I move servers between tags, list in nodes view is out of sync <oil> <ui> <ux> <MAAS:Triaged by ubuntudotcom1> <https://launchpad.net/bugs/1455560>
<mup> Bug #1456190 was opened: 1.8b6 Add hardware broken <ui> <ux> <MAAS:Incomplete> <https://launchpad.net/bugs/1456190>
<mup> Bug #1456231 was opened: MAAS should have a single timestamp format (or a small set of consistent ones) <MAAS:Triaged> <https://launchpad.net/bugs/1456231>
<mup> Bug #1450091 was opened: tgt does not auto-start on Vivid <systemd-boot> <MAAS:In Progress by blake-rouse> <tgt (Ubuntu):In Progress by ubuntudotcom1> <https://launchpad.net/bugs/1450091>
<mup> Bug #1456329 was opened: Add UEFI ARM64 support to MAAS <hs-arm64> <MAAS:Triaged by newell-jensen> <https://launchpad.net/bugs/1456329>
#maas 2015-05-19
<mup> Bug #1456538 was opened: Package install fails with "invoke-rc.d: unknown initscript, /etc/init.d/maas-regiond-worker not found." <MAAS:Triaged> <https://launchpad.net/bugs/1456538>
<dimitern> mpontillo, rvba, allenap, juju+maas interlock?
<allenap> dimitern: I don't have anything on my calendar...?
<dimitern> allenap, ah, sorry, I'll send you an invite, but rvba is already on it
<dimitern> allenap, you didn't miss much btw - and there's the agenda/minutes doc for the meeting (attached to the calendar event)
<mup> Bug #1456190 changed: 1.8b6 Add hardware broken <ui> <ux> <MAAS:Invalid> <https://launchpad.net/bugs/1456190>
<mup> Bug #1456190 was opened: 1.8b6 Add hardware broken <ui> <ux> <MAAS:Invalid> <https://launchpad.net/bugs/1456190>
<mup> Bug #1456190 changed: 1.8b6 Add hardware broken <ui> <ux> <MAAS:Invalid> <https://launchpad.net/bugs/1456190>
<mpontillo> dimitern: sorry, I'm on swap today
<dimitern> mpontillo-swap, no worries
<user01234> Hello, I was hoping to get to the bottom of some errors I have been getting when deploying images I made with curtinator for ubuntu desktop distros.
<user01234> I found similar questions in some of the bug reports on launch pad but im unable to figure out the solution. The error has to do with dev/sda/ not being available....I am acutally going to run an installation and get the exact message right now
<user01234> Error: /dev/sda: unrecognised disk label Unexpected error while running command. Command: ['partprobe', '/dev/sda'] Exit code: 1 Reason: - Stdout: '' Stderr: '' Installation failed with exception: Unexpected error while running command. Command: ['curtin', 'block-meta', 'simple'] Exit code: 3 Reason: -
<capncrunch4me> so since going to 1.7.4, I can no longer get nodes to complete the provisioning process. I have backdoorâd into the ephemeral image and it simply hangs at the maas-signal process
<capncrunch4me> just getting: request to http://10.0.0.2/MAAS/metadata//2012-03-01/ failed. sleeping 1.: ''
<capncrunch4me> request to http://10.0.0.2/MAAS/metadata//2012-03-01/ failed. sleeping 1.: ''
<capncrunch4me> ok, this appears to be a race condition. DNS isnt assigned to the node via DHCP until AFTER commissioning is done. Commissioning requires a FQDN to finish the commisioning. So it hangs waiting for a FQDN
<capncrunch4me> so it hangs forever
<mup> Bug #1456696 was opened: 1.8b6 Cannot mark a ready node "Broken" <ui> <MAAS:New> <https://launchpad.net/bugs/1456696>
<mup> Bug #1456698 was opened: 1.8b6 Unable to deploy a node that is marked fixed when it is on <ui> <MAAS:New> <https://launchpad.net/bugs/1456698>
<mup> Bug #1456699 was opened: 1.8b6 Cannot mark a machine broken that is "deployed" and "on" <ui> <MAAS:New> <https://launchpad.net/bugs/1456699>
<capncrunch4me> this appears to be a regression
<yabbo> hello anyone here?
<Guest52952> i have a maas setup with ipmi working on most of my systems but im having issues with it working on my sun servers
<Guest52952> i can use the ipmitool through the cli and get back responses and even power on the server but i get timeouts from within maas itself
<Guest52952> ipmitool -H 192.168.1.5 -I lanplus -U maas -P nothanks chassis power status Chassis Power is off
<blake_r> Guest52952: you should be seeing an error in clusterd.log if error is occurring with power actions
<Guest52952> were is that log found
<Guest52952> i see this in my maas.log
<Guest52952> May 19 15:26:21 maas maas.power: message repeated 2 times: [ [ERROR] Node could not be queried node-db3fef0e-fdad-11e4-98bd-00505688b5b2 (delsol.vanillasystem.com) username invalid] May 19 15:26:21 maas maas.power: [ERROR] delsol.vanillasystem.com: Failed to query power state: username invalid.
<Guest52952> i just verrified the username is correct
<Guest52952> should i file it as a bug?
<blake_r> Guest52952: check the username is correct in MAAS
<Guest52952> it is set to maas all lowercase... same as the command i use for ipmitool
<Guest52952> blake_r: i have changed it to other accounts such as root which i have logins for aswell with the same error message.
<blake_r> Guest52952: do you have it set to IMPI 2.0?
<Guest52952> yes
<Guest52952> blake_r: i have tried both 1.5 and 2.0
<blake_r> Guest52952: it needs to be set to 2.0
<blake_r> Guest52952: can you provide a screenshot of the parameters for me, just to check
<Guest52952> one sec uploading it somwere
<Guest52952> blake_r: http://www.vanillasystem.com/x2200ipmi.jpg
<blake_r> Guest52952: check that there are no spaces after the username and password
<blake_r> Guest52952: are you sure that you can query that node from the maas server?
<Guest52952> blake_r: yup no spaces
<blake_r> Guest52952: it has access to that network?
<Guest52952> blake_r: yes... logged into maas i can run the ipmitool and get back a response
<Guest52952> blake_r: yabbo@maas:/var/log/maas$ sudo -H -u maas ipmitool -H 192.168.1.5 -I lanplus -U maas -P nothanks chassis power status Chassis Power is off
<Guest52952> blake_r: i can even log into the web gui of the eLOM on the server using the maas account and password
<blake_r> Guest52952: I would go ahead and file a bug then, something very wierd is happening
<blake_r> Guest52952: please attach all the logs
<blake_r> Guest52952: you could try to modify the impi template in /etc/maas/power/impi.template
<Guest52952> blake_r: thanks... i have a dell server that when powered on it will query the power status but when powered off it does the same thing
<Guest52952> blake_r: i dont have that directory... only /etc/maas
<Guest52952> blake_r: no power directory
<Guest52952> blake_r: nevermind its in /etc/maas/templates/power
<blake_r> Guest52952: yeah sorry
#maas 2015-05-20
<mup> Bug #1456865 was opened: cisco c240 m3 system fails deployment following curtin installation and PXE local boot <oil> <MAAS:New> <https://launchpad.net/bugs/1456865>
<mup> Bug #1456892 was opened: 500 error from juju status <MAAS:New> <https://launchpad.net/bugs/1456892>
<mup> Bug #1456969 was opened: MAAS cli/API: missing option set use-fast-installer / use-debian-installer <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1456969>
<harushimo> i'm looking at the documentation. I'm understanding the second step for clustering
<harushimo> specifically on cluster master
<harushimo> can anyone assist me on maas
<roaksoax> harushimo: ask your question and if someone can help, they will reply!
<harushimo> roaksoax: I'm having problems following this documentation to setup openstack
<harushimo> its involved MAAS
<harushimo> I'm struggling with step 3
<harushimo> How does clustering setup work?
<harushimo> I'm working off this documentation: http://www.ubuntu.com/download/cloud/install-ubuntu-openstack
<mup> Bug #1457076 was opened: "make package" fails with bzr: 'ERROR: unknown command "bd"' error <MAAS:Triaged by rbanffy> <https://launchpad.net/bugs/1457076>
<mup> Bug #1457107 was opened: Unable to allocate static IP due to address exhaustion (gomaasapi 503) <oil> <MAAS:New> <https://launchpad.net/bugs/1457107>
<Yabb0> having some issues with my nodes created by maas... they have the apt proxy defined as the maas server and apt works great. but when i try and do a juju bootstrap curl has no proxy defined and errors out. (I'm guessing by default there is no direct route out)
<roaksoax> Yabb0: you need to set a proxy in juju too
<Yabb0> how do i do that before i bootstrap it?
<Yabb0> haven't found any documentation showing this as an issue when deploying ubuntu openstack
<roaksoax> Yabb0: http://pastebin.ubuntu.com/11247399/
<Yabb0> many many thanks :)
<mup> Bug #1457107 changed: Unable to allocate static IP due to address exhaustion (gomaasapi 503) <oil> <MAAS:Invalid> <https://launchpad.net/bugs/1457107>
<Yabb0> one more question. when i do juju bootstrap can i force it to use a specific node?
<Yabb0> roaksoax, can i force juju to bootstrap to a specific node?
<roaksoax> Yabb0: https://jujucharms.com/docs/devel/commands
<roaksoax> Yabb0: check --to
<Yabb0> roaksoax, thank you again. works perfectly
<roaksoax> Yabb0: np! :
<mup> Bug #1457191 was opened: Fresh install (from trunk or ppa:maas-maintainers/experimental) results in /var/log/maas/clusterd.log being owned by root <MAAS:New> <https://launchpad.net/bugs/1457191>
<mup> Bug #1457203 was opened: 1.8b6: Usability - Enter key in search field should not reset view and filter <oil> <MAAS:New> <https://launchpad.net/bugs/1457203>
<mup> Bug #1457203 changed: 1.8b6: Usability - Enter key in search field should not reset view and filter <oil> <MAAS:New> <https://launchpad.net/bugs/1457203>
<mup> Bug #1457203 was opened: 1.8b6: Usability - Enter key in search field should not reset view and filter <oil> <MAAS:New> <https://launchpad.net/bugs/1457203>
<mup> Bug #1457206 was opened: Clusters listing: <h2> title missing <MAAS:Triaged by mpontillo> <https://launchpad.net/bugs/1457206>
<yabb0> ls
<yabb0> sorry wrong screen
#maas 2015-05-21
<yabb0> I'm having issues deploying openstack. my juju config has proxy settings but i don't think they are being used when i do openstack-install
<yabb0> i see the following in the commands.log file:    ERROR: Network communication failed [7]\\n14:12:06.475815 * Hostname was NOT found in DNS cache\n
<mup> Bug #1457245 was opened: MAAS  1.7.3 doesn't save "power type" -> "wake on lan" <MAAS:New> <https://launchpad.net/bugs/1457245>
<yabb0> thats a good one mup
<yabb0> looks like i may need to change juju proxy config. how do i do that after its installed?
<yabb0> nope i think its something with the openstack-install not push proxy configs
<yabb0> can you add nodes to maas to just use for ipmi status and power cycling
<mup> Bug #1457293 was opened: 1.8b6: log entries missing in archived clusterd logs <oil> <MAAS:New> <https://launchpad.net/bugs/1457293>
<mup> Bug #1455770 changed: 100 GB disk shows as 1 in GUI <apport-collected> <third-party-packages> <trusty> <MAAS:New> <https://launchpad.net/bugs/1455770>
<mup> Bug #1455770 was opened: 100 GB disk shows as 1 in GUI <apport-collected> <third-party-packages> <trusty> <MAAS:New> <https://launchpad.net/bugs/1455770>
<mup> Bug #1457499 was opened: MAAS UI showing Wily images as 'wily' instead of as '15.10' <maas (Ubuntu):New> <https://launchpad.net/bugs/1457499>
<mup> Bug #1457504 was opened: Adding nodes via probe-and-enlist (tested with virsh) without having a cluster configure results in nodes not having a fqdn <MAAS:New> <https://launchpad.net/bugs/1457504>
<mup> Bug #1457504 changed: Adding nodes via probe-and-enlist (tested with virsh) without having a cluster configure results in nodes not having a fqdn <MAAS:New> <https://launchpad.net/bugs/1457504>
<mup> Bug #1457504 was opened: Adding nodes via probe-and-enlist (tested with virsh) without having a cluster configure results in nodes not having a fqdn <MAAS:New> <https://launchpad.net/bugs/1457504>
<mup> Bug #1457499 was opened: MAAS UI showing Wily images as 'wily' instead of as '15.10' <MAAS:New> <maas (Ubuntu):New> <https://launchpad.net/bugs/1457499>
<mup> Bug #1457529 was opened: 3 nodes cannot be deployed. To proceed, update your selection. shown when no SSH key added <MAAS:New for mpontillo> <https://launchpad.net/bugs/1457529>
<mup> Bug #1457529 changed: 3 nodes cannot be deployed. To proceed, update your selection. <MAAS:Invalid by mpontillo> <https://launchpad.net/bugs/1457529>
<mup> Bug #1457555 was opened: exceptions.ValueError: No JSON object could be decoded <MAAS:New> <https://launchpad.net/bugs/1457555>
<firl> Hey all, I am trying to figure out the best way to have MAAS serve up custom PXE images ( non disk image ones ). Anyone able to help or point me in the right direction? I know there are some builders, but it looks like they specifically just build a disk image to boot from
<mup> Bug #1457585 was opened: 1.8b7: Empty list of all nodes and incorrect number of total nodes shown in UI <oil> <MAAS:New> <https://launchpad.net/bugs/1457585>
<maasuser> i had a question about discovering new nodes, and existing hosts
<maasuser> our existing hosts have pxe configured already in the bios.  i don't want our existing hosts to get auto-imported and powered off if they were to be rebooted for some reason.  is there an option to have hosts boot to local disk after importing the node?
<mup> Bug #1457671 was opened: MAAS login window should contain the same logo as the window that appears before creating a user <MAAS:New> <https://launchpad.net/bugs/1457671>
<mup> Bug #1457671 changed: MAAS login window should contain the same logo as the window that appears before creating a user <MAAS:New> <https://launchpad.net/bugs/1457671>
<mup> Bug #1457671 was opened: MAAS login window should contain the same logo as the window that appears before creating a user <MAAS:New> <https://launchpad.net/bugs/1457671>
#maas 2015-05-22
<mup> Bug #1457708 was opened: Prostack: all pipelines hit with 400 BAD REQUEST error <oil> <MAAS:New> <https://launchpad.net/bugs/1457708>
<mup> Bug #1457783 was opened: UI: Missing padding in error message <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1457783>
<mup> Bug #1457783 changed: UI: Missing padding in error message <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1457783>
<mup> Bug #1457783 was opened: UI: Missing padding in error message <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1457783>
<mup> Bug #1457786 was opened: Test suite runs sudo commands <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1457786>
<mup> Bug #1457788 was opened: Restarting maas-regiond and maas-clusterd fills the logs with stacktraces <MAAS:Triaged> <https://launchpad.net/bugs/1457788>
<mup> Bug #1457799 was opened: UnknownRemoteError causes cluster to disconnect <MAAS:Triaged> <https://launchpad.net/bugs/1457799>
<mup> Bug #1457499 changed: MAAS UI showing Wily images as 'wily' instead of as '15.10' <MAAS:Invalid> <maas (Ubuntu):Incomplete> <https://launchpad.net/bugs/1457499>
<mup> Bug #1457879 was opened: UnknownRemoteError: Code<UNKNOWN>: Unknown Error raised when calling update_host_maps  <MAAS:Triaged> <https://launchpad.net/bugs/1457879>
<mup> Bug #1457921 was opened: virsh probe-and-enlist does not set boot order <MAAS:In Progress by mpontillo> <https://launchpad.net/bugs/1457921>
<mup> Bug #1457921 changed: virsh probe-and-enlist does not set boot order <MAAS:In Progress by mpontillo> <https://launchpad.net/bugs/1457921>
<mup> Bug #1359143 changed: Upstream DNS should be determined by MAAS regiond package install script <dns> <feature> <MAAS:Triaged> <https://launchpad.net/bugs/1359143>
<mup> Bug #1457921 was opened: virsh probe-and-enlist does not set boot order <MAAS:In Progress by mpontillo> <https://launchpad.net/bugs/1457921>
<mup> Bug #1457990 was opened: Transition from New -> Commissioning should throw an error if node power is on <MAAS:Triaged> <https://launchpad.net/bugs/1457990>
#maas 2015-05-24
<mup> Bug #1431279 changed: MAAS python scripts do not show the line numbers and the script name when errors are encountered <maas (Ubuntu):Expired> <https://launchpad.net/bugs/1431279>
#maas 2016-05-23
<mup> Bug #1584562 opened: Auto-discovery of power parameter does not work for ProLiant DL360e Gen8 system with iLO firmware version 2.40 <oil> <MAAS:New> <https://launchpad.net/bugs/1584562>
<mup> Bug #1584569 opened: maas 2 adds multiple DNS entries for nodes <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1584569>
<voidspace> dimitern: http://reviews.vapour.ws/r/4874/
<kiko> good morning
<BlackDex> Hello there, Is it possible to have maas update the public keys for ssh on already deployed machines without having the original private key used for the previous deployment?
<kiko> BlackDex, no, you'll need to redeploy.
<kiko> BlackDex, we don't have an agent on the machine
<BlackDex> Thx Kiko ;)
<kiko> BlackDex, sure thing
<BlackDex> I'm Mathijs btw. From the e-mail you received a few minutes ago :)
<kiko> BlackDex, ah, at fairbanks
<kiko> great!
<BlackDex> Indeed :)
<kiko> BlackDex, how are things going over there, beyond apparently having lost a private key? :)
<BlackDex> Network related issues, and network engineers not respoding
<BlackDex> but besides that very well
<BlackDex> :)
<mup> Bug #1532935 changed: Nodes stuck at grub menu when attempting to deploy <cdo-qa> <curtin:Invalid> <grub:New> <MAAS:Invalid> <maas-images:Confirmed> <https://launchpad.net/bugs/1532935>
<mup> Bug #1583891 changed: clean up boot-resources before syncing images as well as after <MAAS:Opinion> <https://launchpad.net/bugs/1583891>
<mup> Bug #1584569 changed: maas 2 adds multiple DNS entries for nodes <canonical-bootstack> <MAAS:Won't Fix> <https://launchpad.net/bugs/1584569>
<mup> Bug #1584850 opened: Missing PTR record for IPv6 address <landscape> <MAAS:New> <https://launchpad.net/bugs/1584850>
<mup> Bug #1569556 changed: MAAS 1.9.1 fails to commission a node <MAAS:Invalid> <https://launchpad.net/bugs/1569556>
<mup> Bug #1584926 opened: Provide API to get node statistics, including node count by status <MAAS:New> <https://launchpad.net/bugs/1584926>
<mup> Bug #1584936 opened: [2.0b5] MAAS doesn't import default images automatically <MAAS:New> <https://launchpad.net/bugs/1584936>
<mup> Bug #1584937 opened: [2.0b5] EOL releases are still shown in MAAS <MAAS:New> <maas-images:New> <https://launchpad.net/bugs/1584937>
<mup> Bug #1582243 changed: [2.0b5] Rack controller FAILED authentication from '192.168.10.3:59270'; dropping connection. <MAAS:Invalid> <https://launchpad.net/bugs/1582243>
<mup> Bug #1579758 opened: support advanced networking for non Ubuntu OS <MAAS:New> <https://launchpad.net/bugs/1579758>
<BiGG_D> I just did the conjure for openstack, it seems as though the first maas node I have pxe boots, then does a reboot at the end, when its going thru its 2nd boot sequence, it just ends with "boot:"
<BiGG_D> What did I do wrong?
<mup> Bug #1584949 opened: Provide Ubuntu desktop images for MAAS <MAAS:New> <https://launchpad.net/bugs/1584949>
<BiGG_D> Anyone?
<bdx> hows it going everyone? whats the reccomended way to build the debs from maas source?
<bdx> recommended*
<kiko> bdx, I think there's a makefile target
<kiko> bdx, curious as to what you've hacked into maas too :)
<roaksoax> bdx: there's a make target for it
<bdx> roaksoax: perfect, I see that now .... I'm looking into the interface file templating
<bdx> juju provisioned interfaces seem to be getting overridden on reboot
<bdx> juju bridges to interfaces*
<roaksoax> bdx: actually, juju overrides maas interfaces
<roaksoax> :)
<bdx> roaksoax: yea, but that isn't persisting throught reboot
<bdx> for me
<bdx> I just got rev 5038 installed ... going to run a few deploys and tests to see if its fixed
<roaksoax> k
<bdx> roaksoax: http://paste.ubuntu.com/16645539/
<bdx> roaksoax: might you know what the deal is with ^
<bdx> containers default to bridging onto the first unconfigured network space ...
<bdx> http://imghub.org/image/NH7z
<bdx> https://bugs.launchpad.net/maas/+bug/1584979
#maas 2016-05-24
<Guest72258>  /nick terje
<pacavaca> Hello here! I'm wondering if there's a doc explainig custom image generation (ubuntu/centos with custom packages) published somewhere? I was asking same question here last week and I remember kiko said that someone is going to answer this question on askubuntu because many people are asking.
<mup> Bug #1585016 opened: Commissing with LVM breaks deployments <MAAS:New> <https://launchpad.net/bugs/1585016>
<mup> Bug #1561597 changed: Clicking on multiple "Filter by" items should not make accumulative filters <ux> <MAAS:Expired> <https://launchpad.net/bugs/1561597>
<mup> Bug #1561688 changed: [2.0a3] adding DNS and Zones to settings subnav <design> <ui> <MAAS:Expired> <https://launchpad.net/bugs/1561688>
<mup> Bug #1585118 opened: MAAS 2.0beta5 fails to commission node - floppy issue <cpec> <MAAS:New> <https://launchpad.net/bugs/1585118>
<mup> Bug #1585138 opened: /api/2.0/machines/?op=list_allocated and /api/2.0/machine/?op=acquire do not work for clients authenticated via username and password <api> <MAAS:Triaged> <https://launchpad.net/bugs/1585138>
<mup> Bug #1585118 changed: MAAS 2.0beta5 fails to commission node - floppy issue <cpec> <MAAS:New> <https://launchpad.net/bugs/1585118>
<mup> Bug #1585223 opened: Node lost IPMI password, can't be deleted <landscape> <MAAS:New> <https://launchpad.net/bugs/1585223>
<mup> Bug #1585223 changed: Node lost IPMI password, can't be deleted <landscape> <MAAS:New> <https://launchpad.net/bugs/1585223>
<mup> Bug #1585223 opened: Node lost IPMI password, can't be deleted <landscape> <MAAS:New> <https://launchpad.net/bugs/1585223>
<Wouitmil> Bim
<kiko> hey Wouitmil
<huats> Hi
<huats> I am using maas 1.9 and I'd like to import a custom image
<huats> according to the docs I should be able to use maas  boot-resources
<huats> but boot-resources don't seems to be a choice I have
<huats> any chance someone has an idea ?
<huats> Ok got it
<huats> I wasn't identified I think using the API key
<huats> So now the image is uploaded but I cannot use it when I want to provision (I don't have that choice). Any idea ?
<huats> apparently my cluster is out-of-sync of the image
<huats> what is the proper way to solve that ?
<shewless> hey guys. Is this the right place to ask about "conjure up"? I just want to know if the LXD option uses containers to run the "controllers" of openstack or if it just uses LXD has the compute nodes - if that makes any sense
<rbasak> shewless: try asking stokachu in #ubuntu-server.
<shewless> rbasak: thanks I will do that. Someone on this channel recommended conjure up but I can't remember who.
<oz__> hey guys quick question, if i have nodes with multiple disks do i have to use lvm when installing autpilot in order for all the disks to be used, or do i have to set that up in maas before deploying autopilot
<noobadmin> Hi! I'm new to deploying maas and I have a network problem that I can figure out by myself... I set up a rack controller with a region controller on a single server on a mini lab to test this stuff but when I turn on the 1st node the image boots but can't connect with the region cont. to do the commissioning part because "no route to host"
<noobadmin> I can't find where's the error... both region controller and node are on the same subnet, dhcp and dns are working... I don't know where to check/how to debbug. Can somebody get me oriented, please?
<mup> Bug #1585400 opened: HP Moonshot iLO4 (IPMI) power driver has incorrect required package <MAAS:Triaged by newell-jensen> <https://launchpad.net/bugs/1585400>
#maas 2016-05-25
<jojden> Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed
<jojden> getting timeout error
<jojden> what will be the issue
<jojden> configured region controller
<jojden> and
<jojden> sudo dpkg-reconfigure maas-cluster-controller
<jojden> can anybody give a clue regarding this
<roaksoax> jojden: not without seeing the full log, but that seems related to the machine not being able to contact the region controller, or the machine does not have networking
<jojden> cluster and region configuration is correct and in maas cluster page showing it is connected.
<jojden> roaksoax: while I am doing the curl http://169.254.169.254/latest/meta-data/
<jojden> I am getting 404
<huats> any idea how to solve the out-of-sync for images that I get in a cluster ?
<roaksoax> jojden: look at the logs and see if there's an issue there
<roaksoax> jojden: what for what you've pasted, may be that your machines dont have access to the region controller
<jojden> roaksoax: Its having the access to rc.
<jojden> curl http://169.254.169.254
<jojden> gives the list of meta-data
<jojden> and http://169.254.169.254/2009-04-04/meta-data/ gives 404
<roaksoax> jojden: did you look at the logs ?
<jojden> yes
<jojden> var/ log/ maas
<jojden> right
<jojden> checked in both rc and cc log
<roaksoax> jojden: and ?
<roaksoax> jojden: any tracebacks ?
<jojden> but notmuch infor regarding this error
<roaksoax> jojden: any errors ?
<jojden> no
<roaksoax> jojden: what version of maas are you using ?
<roaksoax> jojden: do you have the full console log ?
<jojden> 1.9
<roaksoax> jojden: 1.9.X ??
<roaksoax> jojden: 1.9.2? 1.9.3?
<jojden> MAAS Version 1.9.0+bzr4533-0ubuntu1 (trusty1)
<roaksoax> jojden: can you upgrade to 1.9.3 ?
<roaksoax> your bug may be fixed there
<jojden> ok sure
<mup> Bug #1560292 changed: cli login no longer works after an update to new 2.0 packages, requires logging out and back in <MAAS:Won't Fix> <https://launchpad.net/bugs/1560292>
<jojden> hi roaksoax
<jojden> I have updated the maas to 1.9.3
<jojden> maas:
<jojden>   Installed: (none)
<jojden>   Candidate: 1.9.3+bzr4577-0ubuntu1~trusty1
<jojden> --
<jojden> maas-dns:
<jojden>   Installed: (none)
<jojden>   Candidate: 1.9.3+bzr4577-0ubuntu1~trusty1
<jojden> --
<jojden> maas-dhcp:
<jojden>   Installed: 1.9.0+bzr4533-0ubuntu1~trusty1
<jojden>   Candidate: 1.9.3+bzr4577-0ubuntu1~trusty1
<jojden> root@maasrc:/var/log/maas/apache2# apt-cache policy maas{,-dns,-dhcp} | grep Installed -B1 -A1
<jojden> maas:
<jojden>   Installed: (none)
<jojden>   Candidate: 1.9.3+bzr4577-0ubuntu1~trusty1
<jojden> --
<jojden> maas-dns:
<jojden>   Installed: 1.9.0+bzr4533-0ubuntu1~trusty1
<jojden>   Candidate: 1.9.3+bzr4577-0ubuntu1~trusty1
<jojden> --
<jojden> maas-dhcp:
<jojden>   Installed: (none)
<jojden>   Candidate: 1.9.3+bzr4577-0ubuntu1~trusty1
<roaksoax> jojden: cool, let's try to reproduce and please paste me the full console log while the machine is trying to access the metadata
<jojden> atually I am trying to create the node using pxe boot. And using the following script
<jojden>     --name=maas-node-test \
<jojden>     --connect=qemu:///system --ram=512 --vcpus=1 --hvm --virt-type=kvm \
<jojden>     --pxe --boot network,hd \
<jojden>     --os-variant=ubuntutrusty --graphics vnc --noautoconsole --os-type=linux --accelerate \
<jojden> --disk=/var/lib/libvirt/images/maas-node-test.qcow2,bus=virtio,format=qcow2,cache=none,sparse=true,size=10 \
<jojden>     --network=network=vlan-20,model=virtio
<jojden> maas rc in one node and maascc in another node
<jojden> and they are connected it
<roaksoax> jojden: right, that should be ok, but i'm interested in looking at the console log
<roaksoax> jojden: to see what's actually going on
<jojden> console log of newly created node right ?
<jojden> i will take the console screenshots of the newly created node
<jojden> is that fine ?
<roaksoax> jojden: you can just put it in those websites were you can share pic
<jojden> ok
<jojden> http://postimg.org/gallery/2fqa982k/99188f9c/
<jojden> roaksoax
<jojden> roaksoax are you busy
<roaksoax> jojden: seems like you dont have connection
<jojden> connection to where ?
<jojden> @roaksoax
<roaksoax> jojden: to the region, but the 3rd/4th image show a different interesting error
<roaksoax> jojden: can you paste /var/log/maas/*.log ? like clusterd.log and regiond.log
<jojden> sure
<jojden> roaksoax http://pastebin.com/kAjbKAsr
<jojden> http://pastebin.com/B1dJtVaL
<roaksoax> jojden: isn't there a better regiond.log ?
<roaksoax> jojden: the one you sent me doesn'y really show any API query
<roaksoax> jojden: also, is apache2 running ?
<jojden> apache2 is running , otherwise maas gui wont load right ?
<jojden> actually I have cleared the log before creating the vm
<jojden> then I started creating it
<jojden> and this is the log details we have in
<roaksoax> jojden: so regiond.log should be showing that you can/cannot access a machine
<roaksoax> jojden: err
<roaksoax> jojden: regiond.log would be showing when the machine is accessing the metadata server
<roaksoax> jojden: but it is not
<roaksoax> jojden: which is why I wonder if apache2 is failing in the forwarding
<roaksoax> or something along those lines
<jojden> let me check for access and error log
<jojden> root@maasrc:/var/log/maas/apache2# /etc/init.d/apache2 status
<jojden>  * apache2 is running
<roaksoax> jojden: can you share your apache2 access.log ?
<jojden> ok
<jojden> roaksoax: http://pastebin.com/6A4Uux5A
<roaksoax> jojden:  /MAAS/api/1.0/pxeconfig/?bios_boot_method=pxe&local=10.20.0.12&remote=10.20.0.174&cluster_uuid=68ac4a87-16d9-4ce2-a96c-19c6360eb9e1 HTTP/1.0" 200 534 "-" "provisioningserver.pserv_services.tftp.TFTPBackend"
<roaksoax> jojden: tha's the only thing I see
<roaksoax> jojden: no other access to metadata
<roaksoax> jojden: which should be there
<roaksoax> jojden: that's leading me to believe that your machine, after accessing the pehemeral environment
<roaksoax> is not really contacting the maas server
<roaksoax> jojden: what's your /etc/maas/clusterd.conf ?
<jojden> root@maascc:/etc/maas# cat clusterd.conf
<jojden> cluster_uuid: 68ac4a87-16d9-4ce2-a96c-19c6360eb9e1
<jojden> maas_url: http://192.168.122.159/MAAS
<jojden> roaksoax this is the content
<roaksoax> jojden: so that tells me that 192.168.122.159 is the IP address of your region controller where the metadata server is running
<roaksoax> jojden: do the machines have access to that IP ?
<jojden> yes
<jojden> correct
<jojden> ping 192.168.122.159
<jojden> PING 192.168.122.159 (192.168.122.159) 56(84) bytes of data.
<jojden> 64 bytes from 192.168.122.159: icmp_seq=1 ttl=64 time=0.241 ms
<jojden> 64 bytes from 192.168.122.159: icmp_seq=2 ttl=64 time=0.205 ms
<jojden> 64 bytes from 192.168.122.159: icmp_seq=3 ttl=64 time=0.181 ms
<roaksoax> jojden: right, so the previous logs don't show that at all
<roaksoax> jojden: what's in /etc/maas/regiond.conf ?
<jojden> root@maasrc:/etc/maas# cat /etc/maas/regiond.conf
<jojden> database_host: localhost
<jojden> database_name: maasdb
<jojden> database_pass: EnUx90XzXHy3
<jojden> database_user: maas
<jojden> maas_url: http://192.168.122.159/MAAS
<roaksoax> jojden: and why are your machines PXE with local=10.20.0.12&remote=10.20.0.174 ?
<roaksoax> jojden: that seems that maybe KVM/libvirt running its own DHCP  ?
<roaksoax> jojden: which may be interfiering with MAAS's /
<roaksoax> ?
<jojden> actually
<jojden> eth1 if maascc is 10.20.0.12
<jojden> *of maascc
<roaksoax> jojden: right, so that's were MAAS is DHCP'ing from
<jojden> but don't know abt remote=10.20.0.174
<jojden> :(
<roaksoax> jojden: i think that's the IP that the machine is obtaining
<jojden> let me verify
<roaksoax> jojden: what happens if you change /etc/maas/clusterd.conf to point to 10.20.0.12 instead ?
<roaksoax> jojden: if you change that and restart maas-clusterd
<roaksoax> i think things iwll just go fine
<jojden> ok
<jojden> 174 is obtaining ip
<jojden> :)
<jojden> let me do as you said
<jojden> maas_url: http://192.168.122.159/MAAS
<jojden>  to  maas_url: http://10.20.0.12/MAAS
<jojden>   in  /etc/maas/clusterd.con
<jojden> right
<jojden> resatarted
<jojden> let me try to create node with pxe boot again.
<jojden> deleting the old node
<jojden> Bootfailed
<jojden> not a bootable disk
<jojden> i think I need to reconfigure with 10.20.0.12
<jojden> roaksoax
<jojden> i think I need to reconfigure with 10.20.0.11 (eth1 of rc)
<jojden> now booting
<jojden> roaksoax
<BlackDex_> what is the best way to prevent a system to poweroff during enlisting?
<mup> Bug #1585628 opened: [2.0] Bulk actions-Nodes action doesnât apply should be red <MAAS:New> <https://launchpad.net/bugs/1585628>
<BlackDex> Also, is there a way to force a specific metadata url?
<BlackDex> or IP address?
<BlackDex> using maas 2.0 btw
<kiko> BlackDex, there's a backdoor image process, just a second
<BlackDex> kiko: https://maas.ubuntu.com/docs/troubleshooting.html that one right?
<BlackDex> for the backdoor
<roaksoax> BlackDex: or you can modify /etc/maas/preseeds/enlist_userdata to do what you want
<kiko> http://askubuntu.com/questions/499316/how-to-create-a-backdoor-add-a-login-to-ephemeral-images
<BlackDex> roaksoax: Thx ;) Thats a quicker way
<BlackDex> thx kiko, that comment above the commands explains the steps very wel
<mup> Bug #1585649 opened: [2.0b5] After changing proxy, MAAS cannot install images <MAAS:New> <https://launchpad.net/bugs/1585649>
<mup> Bug #1585666 opened: Subnets-> Reserved->Purpose - Rephrase migration message <MAAS:New> <https://launchpad.net/bugs/1585666>
<mup> Bug #1585684 opened: Nodes-When going back to nodes listing after performing a bulk action show filtered by selected <MAAS:New> <https://launchpad.net/bugs/1585684>
<mup> Bug #1585759 opened: [2.0RC1] Display RAM amount to the first decimal place in the UI <MAAS:In Progress by ltrager> <https://launchpad.net/bugs/1585759>
<mup> Bug #1585760 opened: [2.0RC1] Expose the refresh rack controller action over the UI <MAAS:In Progress by ltrager> <https://launchpad.net/bugs/1585760>
<mup> Bug #1585768 opened: [2.0RC1] Rename maas-nodegrou-worker to MAAS <MAAS:In Progress by ltrager> <https://launchpad.net/bugs/1585768>
<mahmoh> I have a dirty VM, may be caused by that but seeing this problem: May 25 19:58:25 maas-xenial maas.dhcp: [ERROR] Could not rewrite DHCPv4 server configuration (for network interfaces ens3): Command `maas-rack atomic-write --filename /var/lib/maas/dhcpd.conf --mode 0644` returned non-zero exit status 1:#012None
<mahmoh> this just hangs: root@maas-xenial:/var/log/maas# sudo /usr/sbin/maas-rack atomic-write --filename /var/lib/maas/dhcpd.conf --mode 0644
<mahmoh> 2.0b5 ^
<mup> Bug #1565467 opened: twistd3 crashed with PermissionError in touch(): [Errno 13] Permission denied: '/etc/maas/rackd.conf' <amd64> <apport-crash> <xenial> <MAAS:New> <twisted (Ubuntu):New> <https://launchpad.net/bugs/1565467>
<mup> Bug #1585814 opened: MAAS fails to add a DHCP snippet with "subnet6 statement is only supported in DHCPv6 mode." <MAAS:New> <https://launchpad.net/bugs/1585814>
<terje> Hi, I've just installed: beta5+bzr5026 and I notice that this command is no longer supported:
<terje> maas admin node-groups list
<terje> what is it's replacement I wonder?
<mup> Bug #1585822 opened: Is it impossible to create multiple fabrics which have duplicated subnets from other fabrics <MAAS:New> <https://launchpad.net/bugs/1585822>
#maas 2016-05-26
<mup> Bug #1585841 opened: It would be great if MAAS can support ZFS on the 'Storage' configuration part <MAAS:New> <https://launchpad.net/bugs/1585841>
<mup> Bug #1585878 opened: It does not remove the DHCP and DNS configurations on MAAS after juju removes LXD container(machine). <MAAS:New> <https://launchpad.net/bugs/1585878>
<jojden> why newly created vm using pxe boot is not listing in the maas
<mup> Bug #1585878 opened: It does not remove the DHCP and DNS configurations on MAAS after juju removes LXD container(machine). <MAAS:New> <https://launchpad.net/bugs/1585878>
<jojden> hi roaksoax
<mup> Bug #1585878 changed: Removing a container does not remove the underlying MAAS device representing the container unless the host is also removed. <juju-core:Triaged> <https://launchpad.net/bugs/1585878>
<jojden> roaksoax http://askubuntu.com/questions/777665/why-newly-created-vm-using-pxe-boot-is-not-listing-in-the-maas
<huats> Nobody  to help me a bit with that "out-of-sync" image thing that I am facing ?
<mup> Bug #1586000 opened: Make terminology clearer through tooltips <MAAS:New> <https://launchpad.net/bugs/1586000>
<mup> Bug #1586006 opened: Rearrange DHCP information on VLAN details page <MAAS:New> <https://launchpad.net/bugs/1586006>
<kiko> huats, sure, what's up?
<kiko> terje, the thing is that the whole cluster interfaces API changed
<kiko> terje, check out the new API under /docs2.0
<kiko> mahmoh, never seen that before, did you figure it out?
<roaksoax> jojden: 2016-05-26 06:24:26,012 - url_helper.py[WARNING]: Calling 'http://10.20.0.12/latest/meta-data/instance-id' failed [0/120s]: bad status code [404] -> is 10.20.0.12 the IP of your region controller ?
<huats> Hi kiko .
<huats> I have added a custom image
<huats> and sice I am facing an image "out-of-sync"
<huats> and I don't seen how to fix that
<huats> (and how course the custom image is not usable...)
<kiko> huats, any crashes showing up in /var/log/maas* or syslog?
<kiko> huats, if you remove the image does it work again?
<huats> actually I can use the "old" image
<huats> it is just the new one that is not "showing up"
<kiko> huats, images are uploaded first to the region, and then copied to the cluster filesystem
<kiko> huats, so it's likely your image is not syncing down
<huats> probably
<kiko> but why, the logs may be able to tell us
<huats> ok
<huats> I am ooking
<mahmoh> kiko: no, it was technically terj-e's problem, just bubbling it up for him
<huats> kiko: sorry I had to switch to something else
<huats> I don't see any error in the logs :(
<mup> Bug #1426010 changed: Tests using Selenium are all failing <tech-debt> <tests> <MAAS:Fix Released by allenap> <https://launchpad.net/bugs/1426010>
<mup> Bug #1459168 changed: Start-up stacktrace: IntegrityError: duplicate key value violates unique constraint "maasserver_config_name_uniq" DETAIL:  Key (name)=(rpc_shared_secret) already exists. <stacktrace> <start-up> <MAAS:Invalid> <https://launchpad.net/bugs/1459168>
<shewless> Hello. I have a network that I would like to change the "DNS" IP on (it's currently blank) but I don't see an easy way to edit the subnet from the UI (I can only delete it). Is there a way to do this from the server level?
<shewless> sorry. I mean a subnet.. MAAS 2.0
<kiko> shewless, the API lets you do this; I believe 2.0 final will give you UI, right roaksoax?
<pacavaca> Hi, kiko. Last week me and some other guy were asking here how to create custom ubuntu/centos images, with custom configs and packages installed (custom fs snapshot). You said that someone may write a public answer to that. So, I'm just wondering, maybe it's published somewhere already. Thanks.
<kiko> pacavaca, still on my todo, but a short answer for custom ubuntu is lp:curtinator
<kiko> that's roadmr's project which helps roll custom ubuntu images
<pacavaca> cool, will check it out. thank you
<roadmr> pacavaca: with curtinator you can build maas-installable images from stock Ubuntu ISOs, as long as you can express your config in a standard preseed, you should be able to hack curtinator into doing what you need
<pacavaca> roadmr: am I right that it downloads ubuntu iso then installs it on some kvm vm then takes an fs snapshot, mixes it with preseed scripts and then packs everythin in a tarball, which is something maas can consume?
<kiko> yep
<roadmr> pacavaca: somewhat. You need to provide the iso locally (just wget it ;). Also, the preseeds are applied at *install* time
<roadmr> pacavaca: so it'll boot the provided ISO in a kvm, pointed to the given preseed, and when the install finishes it'll package the resulting filesystem contents in a tarball for maas
<roadmr> pacavaca: the main maas-related thing it does is install cloud-init, but you can hack the preseed to install more packages and maybe write custom files
<pacavaca> I see. That sounds like what I need. Thank you
<roadmr> cheers!
<kiko> you rock roadmr
<roadmr> thanks :) I'm glad curtinator is proving helpful
<shewless> kiko: thanks. another question:
<shewless> I'm trying to make my "fqdn" of my hosts be something specific (say: node-name.foo.com) instead of node-name.maas
<shewless> I don't care if .maas is still there.. basically I have a "maas" fiber and a "foo.com" fiber.. and different subnets for both
<shewless> right now I have the dns servers and IPs and everything working (the foo.com subnet is statically assinged)
<shewless> I'm also using the DNS forwarder option
<shewless> all is good except the nodes "hostname -f" still reports node-name.maas instead of node-name.foo.com
<roaksoax> shewless: if you are using 1.9, you change the DNS zone / domain in the cluster controller
<shewless> roaksoax: 2.0
<roaksoax> shewless: if you are using 2.0, you add a new DNS domain, change the domain in the machine itself, and deploy
<shewless> roaksoax: I tried that but it seems to map the domain name of the machine to the wrong subnet
<shewless> I'm not sure how to change that part
<roaksoax> shewless: <hostname>.<domain> will always map against the IP of the PXE interface
<roaksoax> shewless: <interface>.<hostname>.<domain> PTR records are available against all of the interfaces
<shewless> roaksoax: right I don't want the domain to map to the pxe interface
<roaksoax> shewless: you wont be able to change that unfortunately
<shewless> I'm not sure what you mean by "interface.hostname.domain" - do you think that would work and how do I do it?
<roaksoax> shewless: for example, your node interfaces is this:
<roaksoax> eth0 fabric-0 untagged subnet-1 X.X.X.X
<roaksoax> eth1 fabric-1 vlan10  subnet-10 Y.y.y.y
<roaksoax> shewless: X.X.X.X -> node01.foo.com
<roaksoax> shewless: X.X.X.X -> eth0.node01.foo.com
<roaksoax> shewless: Y.Y.Y.Y -> eth1.node01.food.com
<roaksoax> shewless: Y.Y.Y.Y -> eth1.node01.foo.com
<shewless> okay how do I do that? that seems to be what I want
<roaksoax> shewless: that's done automatically
<shewless> oh wait.. you actually have to have the interface name in the dns?
<roaksoax> shewless: yes
<shewless> roaksoax: I tried adding a DHCP snippet to the "PXE" subnet... option domain-name 'foo.com" which actually worked from a lease perspective.. but the "lo" interface still has a domain name of "maas"
<roaksoax> shewless: go to 'DNS' section
<shewless> roaksoax: k
<roaksoax> shewless: add a domain 'foo.com'
<shewless> did
<roaksoax> shewless: go to the machine details page
<shewless> (none authoritative)
<roaksoax> shewless: click on the hostname, and change node.maas to node.foo.com
<shewless> roaksoax: did
<shewless> roaksoax: but the dns maps to the PXE interface
<roaksoax> shewless: yes, that will never change
<roaksoax> shewless: we always map the <hostname>.<domain> to the PXE interface
<roaksoax> shewless: so eth0 (PXE) - X.X.X.X - node01.foo.com | eth0.node01.foo.com
<shewless> roaksoak: okay. So I need to solve my problem in a different way
<shewless> roaksoax: I'm trying to deploy a "production" server on my network with a provisioned IP and a DNS name that is managed by an external DNS server. I think this would be common right?
<shewless> roaksoak: so my network guy says "assign static IP y.y.y.y" and I've added a dns record of node.foo.com for you
<shewless> roaksoak: right now it's all good (I have maas statically assign IP and update the DNS server) except the fqdn is wrong
<roaksoax> shewless: I see your point now. Right, we don't have a way to change that actually
<shewless> roaksoak: IE: hostname -f returns "node01.maas".  So I'm so close :)
<shewless> if we could make it so "lo" on the nodes doesn't have the domain option set to maas I think it would work with my DHCP snippet
<shewless> any chance we could change that?
<roaksoax> shewless: i think you could do it via preseeds, as in change the hostname automatically
<roaksoax> shewless: like writing a script to change the hostname to what you want
<shewless> roaksoax: that could work. I've never done a preseed before. any hints ? :)
<roaksoax> shewless: let me get my environment back up and reproduce what you are trying to do
<shewless> roaksoax: I think I literally just need to execute this command: echo $(cat /etc/hostname).foo.com > /etc/hostname
<shewless> roaksoax: before boot.  If it's after boot I'd also need to run "hostname" to change the rest
<roaksoax> shewless: in /etc/maas/preseeds/curtin_userdata try something like thois:http://paste.ubuntu.com/16715744/
<shewless> raoksoax: thanks I'll give that a try. I can just edit that file manually?
<roaksoax> shewless: yeah
<roaksoax> shewless: that's the preseed
<roaksoax> shewless: let me konw if that works
<roaksoax> shewless: and how are you finding the DHCP snippet feature btw ?
<shewless> roaksoax: will let you know. the DHCP snippet worked exactly as expected for the subnet
<shewless> roaksoax: for the "node" it just didn't add the snippet at all.. no error.. just didn't add it
<shewless> roaksoax: do I have to restart any services to get the preseed to work or just re deploy
<roaksoax> shewless: just redeploy IIRC
<shewless> roaksoax: trying now.. will keep you posted
<shewless> roaksoax: didn't seem to work.. /etc/hostname is not changed
<shewless> roaksoax: here is the rsyslog: http://paste.ubuntu.com/16716515
<roaksoax> shewless: it doesn't seem like it failed ?
<shewless> roaksoax.. you are right... I didn't see anything that appeared to fail
<shewless> roaksoax: but at the same time it didn't appear to work
<shewless> roaksoax: can I run the userdata thing manually after the fact to see if it worked?
<roaksoax> shewless:
<roaksoax> root@acerbic-rufus:/home/ubuntu# echo $(cat /etc/hostname).foo.com > /etc/hostname
<roaksoax> root@acerbic-rufus:/home/ubuntu# hostname -f
<roaksoax> acerbic-rufus.maas
<roaksoax> shewless: even doing it manually doesn't work
<roaksoax> shewless: do you need the hostname of the machine to reflect the hostname ?
<shewless> roaksoax: if you check /etc/hostname you'll see it's changed.. on next boot it would work.. or you can do "sudo hostname `cat /etc/hostname`" if you don't want to wait
<shewless> roaksoax: but the point is I can see that the preseed didn't change the /etc/hostname file at all for me
<roaksoax> shewless: i think that may be because cloud-init change the hostname after first boot
<roaksoax> or at least I think that's what is happening
<roaksoax> shewless: so you absolutely need the machine to be deploed with such hostname ?
<shewless> roaksoax: I agree I saw a bunch of hostname stuff in cloud.cfg on the box
<shewless> roaksoax: I do need it. Right now I'm just manually doing it
<roaksoax> shewless: the other thing you could do
<roaksoax> shewless: is to write a script that change sit or similar
<roaksoax> shewless: after cloud-init writes it
<roaksoax> shewless: ohhh I have an idea
<roaksoax> shewless: let me test it though
<shewless> roaksoax: sounds good
<roaksoax> shewless: wont work. I was thinking of giving an IP to second NIC, and assigning a DNS name like nodeXX.foo.com
<roaksoax> shewless: so you wouldn;t need external DHCP/DNS
<roaksoax> shewless: but that won't set the machine's hostname to <hostname>.foo.com
<roaksoax> shewless: i'l talk to the team and see if we can prpovide the ability to selcet which interface would get the actualy hostname you are looking for
<roaksoax> shewless: but that wont happen till next week
<shewless> roaksoax: thanks for the help.  In the mean time I'll just manually set the hostname. I appreciate your help
<roaksoax> sorry i couldn't be of more help though
<aslaen> Hello I am not sure I did wrong but I can't get a node to provision.  I have MaaS installed correctly and when I PXE boot a node it pulls IP from MaaS, and starts to bootstrap, but then it stops at "yay system is up!" and doesn't complete the process.
<aslaen> any ideas?
#maas 2016-05-27
<mup> Bug #1586365 opened: Node IP changes are not reflected in Dashboard <change> <dashboard> <dhcp> <ip> <update> <MAAS:New> <https://launchpad.net/bugs/1586365>
<mup> Bug #1586365 changed: Node IP changes are not reflected in Dashboard <change> <dashboard> <dhcp> <ip> <update> <MAAS:New> <https://launchpad.net/bugs/1586365>
<mup> Bug #1586464 opened: Installation failed - /dev/nvme0n11 no such file or directory <maas (Ubuntu):New> <https://launchpad.net/bugs/1586464>
<mup> Bug #1586464 opened: Installation failed - /dev/nvme0n11 no such file or directory <curtin:New> <MAAS:New> <https://launchpad.net/bugs/1586464>
<mup> Bug #1586464 changed: Installation failed - /dev/nvme0n11 no such file or directory <maas (Ubuntu):New> <https://launchpad.net/bugs/1586464>
<mup> Bug #1586464 opened: Installation failed - /dev/nvme0n11 no such file or directory <maas (Ubuntu):New> <https://launchpad.net/bugs/1586464>
<mup> Bug #1586464 changed: Installation failed - /dev/nvme0n11 no such file or directory <curtin:New> <MAAS:New> <https://launchpad.net/bugs/1586464>
<mup> Bug #1586464 changed: Installation failed - /dev/nvme0n11 no such file or directory <curtin:New> <https://launchpad.net/bugs/1586464>
<mup> Bug #1586487 opened: Improve boot-resources create --help text <MAAS:New> <https://launchpad.net/bugs/1586487>
<mpjetta> how do I set âagent-stream: develâ in MAAS 2.0 ?
<mup> Bug #1586499 opened: HP Moonshot iLO4 (IPMI) power driver not working <MAAS:In Progress by newell-jensen> <MAAS 1.9:In Progress by newell-jensen> <https://launchpad.net/bugs/1586499>
<can8dnSix> afternoon; I'm trying to get MaaS 1.9.3 to work with KVM (Ubuntu 14.04), I can get everything all the way to storage, is there additional steps for virsh/kvm to be taken to get this working?
<mup> Bug #1586540 opened: MaaS 2.0 beta 5 fails to assign IP address to nodes when multiple nodes go into deploying at once <cpec> <juju> <maas2.0> <MAAS:New> <https://launchpad.net/bugs/1586540>
<x58> Got an issue with MaaS: https://bugs.launchpad.net/maas/+bug/1586540 could use some help please :-)
<x58> kiko: Hey, Bert here. We had a discussion a long time ago, now using MaaS with the help of mattrae!
<x58> MaaS has grown up from 1.7 to 2.0 :P
<mup> Bug #1586540 opened: MaaS 2.0 beta 5 fails to assign IP address to nodes when multiple nodes go into deploying at once <cpec> <juju> <maas2.0> <MAAS:New> <https://launchpad.net/bugs/1586540>
<mup> Bug #1586540 changed: MaaS 2.0 beta 5 fails to assign IP address to nodes when multiple nodes go into deploying at once <cpec> <juju> <maas2.0> <MAAS:Invalid by bertjwregeer> <https://launchpad.net/bugs/1586540>
<x58> Sorry, didn't do my due diligence, here's the new bug: https://bugs.launchpad.net/maas/+bug/1586555
<mup> Bug #1586540 opened: MaaS 2.0 beta 5 fails to assign IP address to nodes when multiple nodes go into deploying at once <cpec> <juju> <maas2.0> <MAAS:Invalid by bertjwregeer> <https://launchpad.net/bugs/1586540>
<mup> Bug #1586540 changed: MaaS 2.0 beta 5 fails to assign IP address to nodes when multiple nodes go into deploying at once <cpec> <juju> <maas2.0> <MAAS:Invalid by bertjwregeer> <https://launchpad.net/bugs/1586540>
<mup> Bug #1586555 opened: MaaS 2.0 BMC information not removed when nodes are removed <cpec> <MAAS:New> <https://launchpad.net/bugs/1586555>
#maas 2016-05-28
<enp0s8> I have a node with two network interfaces how can i bring up the second nic when i deploy?
<huats> Hi kiko
<huats> sorry it took me ages to have a look at the various logs (regarding the issue I have of the out-of-sync image in my cluster)
<huats> I have been able to redo the addtion of an image
<huats> and I am still stuck with the out-of-sync thing
<huats> the image seems to be uploaded well on the region
<huats> but it "stops" there and it is never sent to the cluster
<huats> there is nothing that seems wrong/special on the logs
<huats> just that on syslog after it is sent to the region I can see
<huats> [INFO] Updating boot image iSCSI targets.
<huats> and I never got any reference to the custom image I have added (it only shows the generated ubuntu image I have already)
<huats> if you have any clue :)
<huats> It would be really interesting...
<huats> I am really stick :(
<huats> stuck
<roaksoax> huats: what version of maas are you using?
<huats> roaksoax: Hi
<huats> 1.9.2+bzr4568-0ubuntu1
<huats> actually I am guessing if I am providing the right kind of image to maas... since it is the first "custom" image I want to give him
<huats> can I give to maas a qcow2 ?
<roaksoax> huats: imthinking that the issue will still be there in 1.9.3
<roaksoax> but i'd recommend you upgrade
<huats> ok
<huats> I will try that
<huats> and regarding the qcow2 thing ?
<roaksoax> huats: also, you can't do qcow, only root tarball
<huats> ok
<huats> :)
<roaksoax> huats: how large is the image?
<huats> that might be main issue
<huats> not so large
<huats> about 300M
<roaksoax> huats: yeah so if it is qcow2 that wont work
<huats> hum I am wondering how to convert qcow2 to tarball
<roaksoax> huats: https://launchpad.net/maas-image-builder
<roaksoax> huri'd sugggst you look into that
<huats> roaksoax: does it makes that kind of convertion ?
<roaksoax> huats: that creates a maas image from a vm. so you can see how the root image is created
<huats> oh great
<roaksoax> huats: also, if you are creating a third party OS(non-ubuntu) you'll need to look at curtin_hooks being created for that image
<huats> ok
<huats> (trying to do an opensuse one...)
<huats> roaksoax: can you explain me a bit more about the curtin_hook ?
<huats> I think I have done a tgz from the qcow2 (using a simple tar the same way it is done in maas-image-builder)
#maas 2017-05-22
<mup> Bug #1665104 changed: ARM64 Gigabyte server sometimes fails to enlist in CI <MAAS:Expired> <https://launchpad.net/bugs/1665104>
<mup> Bug #1673525 changed: Boot from SSD in AHCI mode fails <MAAS:Expired> <https://launchpad.net/bugs/1673525>
<mup> Bug #1665104 opened: ARM64 Gigabyte server sometimes fails to enlist in CI <MAAS:Expired> <https://launchpad.net/bugs/1665104>
<mup> Bug #1673525 opened: Boot from SSD in AHCI mode fails <MAAS:Expired> <https://launchpad.net/bugs/1673525>
<mup> Bug #1665104 changed: ARM64 Gigabyte server sometimes fails to enlist in CI <MAAS:Expired> <https://launchpad.net/bugs/1665104>
<mup> Bug #1673525 changed: Boot from SSD in AHCI mode fails <MAAS:Expired> <https://launchpad.net/bugs/1673525>
<mup> Bug #1690466 changed: Pod manager counts all virsh pools as available disk <MAAS:Won't Fix> <https://launchpad.net/bugs/1690466>
<mup> Bug #1692554 opened: doc: https://docs.ubuntu.com/maas/2.1/en/api states "bond-mode" instead of bond_mode <canonical-bootstack> <MAAS:Confirmed for petermatulis> <https://launchpad.net/bugs/1692554>
<mup> Bug #1692557 opened: [2.2] Menu on mobile view does not work.  <MAAS:Triaged> <https://launchpad.net/bugs/1692557>
<xygnal> roaksoax I have a bit of a problem.  In order to force our Dell boxes to set their raid config, it reboots the system
<xygnal> roaksoax can Comission handle a reboot or will that spoil it?
<roaksoax> xygnal: the commission process would start all over again. So what will happen? the dell firmware will upgrade the firmware, require a reboot and that's it ? or will it do more stuff after a reboot ?
<roaksoax> xygnal: actually, it may even mark the machine failed commissioning because it didn't receive a ping from the machine
<xygnal> roaksoax its just reseting the raid config back to 0, so we can change it to HBA mode after that.  That forces it to reboot the OS to change the RAID settings.
<roaksoax> ltrager: ^^ in commissioning, whilerunning a custom script, will rebooting the machine mark it as failed commissioning ?
<ltrager> roaksoax: with 2.2 it should resume on reboot
<xygnal> ltrager and it would just re-run the steps?
<roaksoax> xygnal: it would, yes
<ltrager> xygnal: it would run scripts which havnt run
<xygnal> ltrager would my script which initiates the rboot count as completed?
<xygnal> or be re-run?
<ltrager> no the reboot will cause no result to be sent
<ltrager> so it should rerun
<xygnal> alright then
<xygnal> i've already started coding it to check if the raid has been reset or not
<xygnal> so it will say "nope not reset", reboots
<xygnal> comes back around
<xygnal> checks "ok its gone now, safe to move forward" on seccond boot
<mup> Bug #1692607 opened: maas CLI/api interaction silently ignores bad parameters <canonical-bootstack> <MAAS:Triaged> <https://launchpad.net/bugs/1692607>
<mup> Bug #1692607 changed: maas CLI/api interaction silently ignores bad parameters <canonical-bootstack> <MAAS:Triaged> <https://launchpad.net/bugs/1692607>
<mup> Bug #1692607 opened: maas CLI/api interaction silently ignores bad parameters <canonical-bootstack> <MAAS:Triaged> <https://launchpad.net/bugs/1692607>
<xygnal> ltrager one quesiton - how long before comission times out?  This raid operation takes 10 minutes.
<ltrager> xygnal: there is a heart beat with 2.2, so that shouldnt be a problem
<xygnal> ltrager heartbeat to prod interface IP, or to OOB?  During this 10 minutes, OS wont be available.
<ltrager> xygnal: to the rack on the metadata sevice
<mup> Bug #1692660 opened: sudo maas createadmin creates username with 'login' prepended <MAAS:New> <https://launchpad.net/bugs/1692660>
<mup> Bug #1692660 changed: sudo maas createadmin creates username with 'login' prepended <MAAS:Invalid> <https://launchpad.net/bugs/1692660>
<xygnal> roaksoax: ltrager:  not working like you think it would
<xygnal> soon as the box reboots, goes into failed comission state, and powers off the box
<xygnal> which then prevents it from even completing the raid change
<xygnal> :/
<roaksoax> ltrager: ^^
<roaksoax> xygnal: yeah I think I kind of expected that, ltrager why would that not be the case? unless you define a script timeout ?
<xygnal> if i set a sleep in the script i see it wait patiently for 5 minutes of sleep
<xygnal> but as soon as the OS reboots from this command
<xygnal> instantly, commission failed
<roaksoax> yeah because the heartbeating mechanism is asking for status
<xygnal> and there is no OS to respond :(
<roaksoax> exactly
<xygnal> if it did not power it off
<xygnal> at least it would finish its activity
<xygnal> and on second try, it would skip that part
<xygnal> but since it powers off right away... nope
<roaksoax> but, ltrager can confirm, there may be possible to specify a timeout for the script in question, so it doesn't immediately think it is dean
<roaksoax> dead*
<xygnal> ltrager let me know if I can do that, a 600 second timeout should get me past it.
<xygnal> dont ask my why a PERC needs 10m to reset its RAID config, it just does :/
<mup> Bug #1692723 opened: Adding RSD Pod fails if pre-composed node has remote iSCSI storage target assigned <rsd> <MAAS:Triaged> <https://launchpad.net/bugs/1692723>
<mup> Bug #1692723 changed: Adding RSD Pod fails if pre-composed node has remote iSCSI storage target assigned <rsd> <MAAS:Triaged> <https://launchpad.net/bugs/1692723>
<mup> Bug #1692723 opened: Adding RSD Pod fails if pre-composed node has remote iSCSI storage target assigned <rsd> <MAAS:Triaged> <https://launchpad.net/bugs/1692723>
<ltrager> xygnal: What should be happening is after you reboot the machine goes back into the ephemeral environment and any script which MAAS has not received a result for is run. What I suspect is happening is the reboot is taking to long.
<ltrager> xygnal: Once commissioning/testing starts MAAS expects the heartbeat to run and allows for 10 minutes of silence. If reboot takes longer then 10 minutes it will fail
<xygnal> it fails in 30 seconds
<xygnal> every time
<ltrager> hmm I wonder if the script runner is detecting the reboot as a failure for some reason
<ltrager> xygnal: are you just running the command 'reboot'?
<xygnal> ltrager: no but this is racadm issuing a command to the DRAC to wipe the RAID config.  It immediately power-cycles the box and boots itself into its UEFI ui and shows a progress meter for the action.  When it reaches 100% it boots back to normal.
<xygnal> sadly srvadmin-idracadm8 and 7 both fail their post-scripts on install, so if I cannot cleanly uninstall them, any boot after that fails because of those 2 packages that failed to finish their post scripts.
<xygnal> thinking that this step is simply going to have to happen pre-maas
<ltrager> xygnal: In the event log does MAAS tell you why it failed?
<xygnal> checking the maas.log
<mup> Bug #1692723 changed: Adding RSD Pod fails if pre-composed node has remote iSCSI storage target assigned <rsd> <MAAS:Triaged> <https://launchpad.net/bugs/1692723>
<xygnal> lol
<xygnal> region or rack would have this?
<xygnal> reigon has 3 lines.  Status transition from READY to COMMISSIONING, Comissioning Started, Status transition from COMMISSIONING to FAILED_COMMISSIONING
<ltrager> xygnal: On the machine page click on the events tab
<xygnal> Node commissioning failure - 'cloudinit' running modules for final
<xygnal> only that, begin the begining and ending messages for commission
<xygnal> er, other than the begining and ending messages
<xygnal> the last script to execute is my raid reset action, and the logs for that confirm it excuted and would have rebooted at that time.
<xygnal> does cloud-init get run *after* these?
<ltrager> xygnal: could you post the result of maas <profile> node-script-result read <system_id> current-commissioning
<ltrager> xygnal: When the ephemeral environment boots cloud-init is given the MAAS script runner as user data which downloads, executes, and returns all commissioning and testing scripts slated to be run
<xygnal> btw, it does not show my scripts having failed execution.
<xygnal> 'Passed' status
<xygnal> They have an immediately 'exit 0' after that racadm command to ensure it comes back as Passed.  Since there would be no reason for that script to execute a second time.  Its work was complete.
<ltrager> xygnal: but the system never comes back after the reboot?
<xygnal> ltrager system is immediately powered-off by MAAS
<xygnal> after commission failed status
<xygnal> there is no 'time out' waiting for it to come back
<xygnal> it gives up right away
<xygnal> the timestamp for starting comission and ending comission is 17:02 to 17:07
<xygnal> when it fails, that is
<xygnal> ltrager I am doing this as a 99- script,  should I be putting it earlier instead?
<ltrager> xygnal: that shouldn't matter
<xygnal> ltrager do you want it strait out of maas like that, or would you rather see my script directly on pastebin?
<ltrager> xygnal: straight from MAAS is fine :)
<xygnal> ltrager ah I see this is the status result.
<xygnal> all of the tasks after my raid reset task
<xygnal> are marked as failed
<xygnal> but they were never run...
<xygnal> and the timestamp for the fail on each of those items
<xygnal> is identical
<xygnal> like it auto-failed them all
<xygnal> ltrager: check private message window
<roaksoax> i think that what's happening is since the machine is rebooting mid-commissioning, a message is sent to cloud-init which then tells maas that it failed finishing doing what it needed to do
<roaksoax> causing the machine to be marked as failed commissioning, as expected
<ltrager> roaksoax: I think its failing when the PXE file is requested
<ltrager> xygnal: The reboot is causing the failure as roaksoax mentioned I'm just trying to figure out why and how it can be fixed
<xygnal> any other location I can gather data from to assist with debuggin that?
<roaksoax> ltrager: because cloud-init is running the show in the ephemeral environment
<roaksoax> ltrager: cloud-init captures the fact that something is breaking its own process and is trying to reboot the machine
<roaksoax> ltrager: and cloud-init goes back and says "oh wait, I didn't finish running what I was told to run, and something is trying to reboot the machine, so since I didn't finish, I'm failing running everything I was told to"
<roaksoax> xygnal: i have a question, your change process requires to reboot the machine. I wonder if you can simply not reboot the machine. The machine wil turn off after commissioning, and when you deploy, it will have effectively applied the changes you requested
<xygnal> roaksoax unfortunately there does not appear to be a 'please dont reboot' for this option.
<xygnal> and telling it to clear the config does not cause it to simply change a 1 to a 0, it boots up into its UEFI boot manager and proceeds to execute.
#maas 2017-05-23
<benlake> Folks, I hate to bother, but Iâve been at this for a while. Attempting to commission a my first node on a fresh 16.04.2 MAAS install using the 16.04 image and cloud-init is failing with âno datasource foundâ. Here is a screen cap with the interesting points being at times 1:27, 1:32, and 1:44, https://www.screencast.com/t/iSyL4IAPiI
<benlake> I canât quite tell if this issue is related: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1648380
<benlake> Possibly relevant, at 0:59 mid screen you can see eth0 being renamed to enp1s0. I manually added the node (because this same issue prevented PXE based enlisting), and manually changed the interface name to enp1s0 in MAAS. Thinking that perhaps that was playing a part in preventing communication between controller and node.
<benlake> 1:06 the line âInvalid path for Logical Volumeâ when referring to the iSCSI LUN seems troubling too, but it then goes on to seemingly mount and read /scripts/, so I guess OK?
<benlake> The next step I suppose will need to be backdooring the image to dig around locally.
<benlake> Attempting to poke around the âMAAS datasourceâ section on https://docs.ubuntu.com/maas/2.1/en/troubleshoot-faq led me to files that donât exist on my controller. So I donât know if that information is just old or if something didnât get installed.
<benlake> any pointers are appreciated.
<cnf> ugh, silly maas networking :/
<mup> Bug #1681278 opened: bootstrap failure on MAAS <bootstrap> <maas> <juju:Incomplete> <juju 2.0:Won't Fix> <MAAS:New> <https://launchpad.net/bugs/1681278>
<jeevan> hi
<benlake> Hmm, so I donât have any files denoted by the âbackdoor stepsâ, ie. no /var/lib/maas/boot-resources/*/*/*/*/*/*/root-image
<benlake> but I think it just dawned on me that process is referring to images that actually manage to get deployed.
<benlake> I instead, am stuck at cloud init issues during PXE boot.
<benlake> should the cloud-init package been installed via the maas metapackage?
<benlake> is there a way to get into the PXE booted image to check network config?
<benlake> Iâm working under the assumption âno datasource foundâ might be a failed MAAS API call
<pmatulis> benlake, i cannot see your original screenshot. got some kind of java problem trying to view
<benlake> this? https://www.screencast.com/t/iSyL4IAPiI - it is a flash video
<benlake> Iâll snap pics at the times I noted.
<benlake> iSCSI path issue (maybe?) https://www.screencast.com/t/d74xmHp8tt6L
<benlake> cloud-init init https://www.screencast.com/t/tJXY2WzefYl
<benlake> cloud-config apply no datasource https://www.screencast.com/t/rvKCTWh1xv7
<benlake> cloud-init stage final no datasource https://www.screencast.com/t/zZ3KnTDZAPV
<benlake> Iâve been poking around the maas node to try and find/understand what config is being sent to cloud init
<pmatulis> benlake, can you explain your network topology and what the underlying machines are?
<benlake> maas controller has 2 interfaces, same wire. Untagged and VLAN 100 interfaces. Untagged is 10.128.1.128/25 the âprovisioning subnetâ. I set a dynamic range of 10.128.1.192-.254. I enabled maas DHCP on the untagged interface.
<benlake> the controller is a supermicro + ubu 16.04, and the node attempting to be deployed is the same spec supermicro
<benlake> both with IPMI 2.0+
<benlake> the node Iâm attempting to deploy properly PXEâs via maas
<benlake> and DHCP is assigning 10.128.1.192
<benlake> since enlistment didnât work, I manually added. maas is properly managing IPMI to control power to the machine.
<benlake> because I donât want you to have to believe me, here is the PXE boot https://www.screencast.com/t/9vlNb5rfRM
<benlake> oh balls.
<benlake> oh pmatulis, you rubber ducky you
<pmatulis> benlake, hm?
<benlake> I just noticed there is a config-url displayed in that last screenshot
<benlake> and it has the tagged interfaces IP!
<benlake> but the iscsi target IP is correct. why the hell is maas deciding to use both?
<benlake> anyone know where maas is pulling the config-url IP from?
<kiko> blake_r, mpontillo, or maybe newell might know that one
<kiko> benlake, those addresses do look suspicious
<kiko> benlake, I assume the 74.x network is not accessible from the node itself
<benlake> the IPs are valid, just not what maas should be using here.
<blake_r> benlake: what is the maas_url= in the /etc/maas/regiond.conf
<benlake> correct, 74. is not.
<blake_r> benlake: that needs to be the same IP address that the PXE booting nodes can reach the region controller
<benlake> I just found this command, sudo maas-region local_config_set
<blake_r> benlake: you can use that command to change the value in /etc/maas/regiond.log, or manually change it
<benlake> and set it to the correct IP, so /etc/maas/regiond.conf has the correct IP. Not sure if it did before. Let me check history
<benlake> ding, ok so that command prolly changed it
<blake_r> benlake: if you change it you need to restart
<blake_r> systemctl restart maas-regiond
<kiko> benlake, this is a very common problem, it stems from us trying to guess the address during MAAS insteall
<blake_r> to get the updated IP and then try to enlist
<kiko> install
<kiko> blake_r, where did we end up with putting a debconf option to request upon installation?
<kiko> blake_r, or alternatively, leaving it unconfigured until the user sets it explicitly
<kiko> instead of trying to guess
<kiko> as when we guess wrong, which is almost always on a multi-homed regiond, the failure more is horrible?
<blake_r> kiko: dpkg doesnt request
<kiko> I had a bug filed on this since prehistoric times I think
<blake_r> kiko: this is a change the snap has done, to make this process better
<blake_r> kiko: the snap asks you when you configure
<kiko> that's nice -- but dpkg could too if we wanted it to?
<blake_r> kiko: another fix would be to proxy all requests through the rack, then that IP doesn't matter
<blake_r> kiko: I think it doesn't because it breaks installation from the ISO
<blake_r> kiko: but I don't fully remember why
<kiko> I think it depends on the priority set in the ISO installer
<kiko> indeed, that would work and is probably the right solution
<benlake> blake_r: restarted, testing. I concur with not guessing. Especially since MAAS most definitely is OK working with VLANs, so the controllers will likely always have multiple interfaces...
<kiko> right
<kiko> https://bugs.launchpad.net/maas/+bug/1418044
<benlake> why are the iscsi paths using the other IP?
<kiko> because they talk to the rack controller
<kiko> which is a separate component
<benlake> seems odd that discovery isnât at least consistent
<benlake> oh, gotcha
<kiko> well that is due to a design artifact:
<kiko> a) region and rack are separate, for scalability reasons (you'll want many rack controllers)
<kiko> b) the nodes mostly talk to the rack, but for metadata requests currently talk to the region
<blake_r> benlake: you can also change the /etc/maas/rackd.conf maas_url
<kiko> c) at install time it's unclear what the internal interface for the region controller actually is, and we guess
<blake_r> benlake: that is unique per rack controller
<benlake> blake_r: thatâs currently localhost, so itâs OK
<blake_r> benlake: if its localhost, MAAS will use the IP set in regiond.conf
<benlake> oh wow, thatâs opaque
 * benlake changes it
<blake_r> benlake: it tells the rack controller how to talk to the region controller
<kiko> blake_r, wtf??
<blake_r> benlake: but the machines that PXE boot from that rack controller, must also be able to contact the region controller at that address
<benlake> yeah, I follow that, but detecting localhost and then using another config is a bit rough
<kiko> what benlake said
<benlake> if it says localhost, I expect localhost to be resolved.
<kiko> anyway, it's really unclear that that config means "the IP which nodes trying to talk to me should use"
<kiko> which leads to putting localhost in be fine
<benlake> blake_r: yup, gotcha.
<blake_r> really what should happen is that all comunication should proxy through the rack controller
<blake_r> removing the need for the nodes to use the maas_url in rackd.conf
<kiko> sorry, leads to people thinking that putting localhost in is fine
<kiko> yeah
<blake_r> butting localhost is fine
<blake_r> in a simple MAAS
<blake_r> in complex networking things get more difficult
<blake_r> but proxy through rack would solve this problem
<benlake> one thing I did after manually adding this node, then marked it broken, was to change the interface name from eth0 to enp1s0 - is that necessary? is that interface name meaningful to cloud-init/deployment?
<benlake> I did this in my troubleshooting quest
<kiko> it should not be necessary
<blake_r> benlake: that is not necessary
<blake_r> benlake: but when you deploy that interface will always get that name
<benlake> great! trying commission again, if it moves along, Iâll blow everything away and try a raw enlist via pxe.
<benlake> âget that nameâ - as in end up in /etc/network/interfaces?
<blake_r> benlake: yep, and udev rules to make sure it has that name
<benlake> sweet, cloud init worked!
<benlake> blake_r: ah, ok then.
<cnf> so MaaS won't allow a default gateway outside of the CIDR i define
<cnf> but the CIDR is a lot larger, i just have a small part of it assigned to me
<mpontillo> cnf: MAAS expects the CIDR to match how it is defined on the network; if you only control a small part you can make it an "unmanaged" subnet in MAAS 2.2 (reserve a range for IP allocation). if you want MAAS to use DHCP on that subnet, define the entire subnet, and make sure to define it as a managed subnet with reserved ranges for the portions MAAS is not
<mpontillo> allowed to allocate from
<cnf> mpontillo: yeah, that's a pain, because i have a /29 in it and a /28 in it, used for different things
<mpontillo> cnf: worth noting is that MAAS is happier with non-overlapping subnets as well; users are allowed to model overlapping subnets but there might be edge cases, so I would recommend against it
<mpontillo> cnf: if it's just one bit, should be easy to mask off the unusable-to-MAAS portion with a reserved range?
<cnf> you can recommend against it, but i don't decide on the network ranges used
<cnf> 2 bits, i have 2 non- following parts of a /24
<cnf> both with the same gateway
<mpontillo> cnf: oh okay, so there are at least three overlapping subnets, a /24, /28, and /29?
<cnf> yeah
<mpontillo> cnf: are you managing DHCP on the subnet?
<mpontillo> cnf: rather, do you expect MAAS to manage DHCP on your portion of the subnet?
<mpontillo> cnf: if yes, how is the traffic isolated from the larger subnet?
<cnf> it's not DHCP, but juju needs to ask for IP's in it
<cnf> mpontillo: which is used for IPs for containers
<cnf> legacy, so much fun
<mpontillo> cnf: ok. so if I understand you correctly, you have /24, you don't manage DHCP on the subnet, and you want to carve out /28 and /29 networks for specific container-IP-assignment purposes?
<benlake> blake_r: pmatulis: kiki: thanks for your help. The machine is now progressing. Some other things to tinker with, but those are likely with my setup.
<kiko> benlake, thanks, please chime in on the bug so it's not just me :-)
<cnf> mpontillo:  yes
<benlake> kiko: will do!
<cnf> it's the only way i know to get juju the IP's for containers, when running on MaaS
<mpontillo> cnf: how do you plan to tell juju which subnet to use? (are you using spaces? if yes, MAAS 2.2 may actually break you, since spaces moved to be associated with VLANs instead of subnets)
<cnf> i am using spaces
<cnf> and ugh
<cnf> why would you associate spaces with VLANs?
<cnf> how can you then tell juju what subnet to use?
<mpontillo> cnf: well, there was a significant debate about that. basically there is no perfect solution, but in order to deploy OpenStack in certain scenarios we needed to have a way to have an "empty" VLAN with a space, but no subnets assigned yet
<mpontillo> cnf: it was understood at the time that people weren't using spaces how you're using them =(
<blake_r> cnf: there is no true isolation unless a space is a VLAN
<cnf> i have been struggleing with openstack on MaaS / juju for a LONG time now
<cnf> list of open bugs is growing...
<cnf> i mean, if you want a vlan, define a vlan!
<cnf> the usefulnes of spaces was that you could put several subnets in a single space
<mpontillo> cnf: right, so as blake_r implied, spaces were envisioned as a "color" for a vlan/subnet the defined its security properties. you might have a "red" space for your DMZ, "green" for your intranet, "purple" for your protected health care data, etc
<mpontillo> cnf: if you combine all those things onto the same VLAN is sort of defeated the purpose of spaces modeling the security properties of the network
<blake_r> cnf: you can have 2 vlans in the same space
<blake_r> cnf: just a router between them
<mpontillo> *can't I think you mean blake_r?
<blake_r> mpontillo: can(
<blake_r> can*
<cnf> this is going to be a fun RFI
<blake_r> as for the subnet you don't control
<blake_r> add the whole subnet
<blake_r> set it to unmanaged
<cnf> so i can almost start from scratch
<cnf> and it STILL doesn't fix my problems
<blake_r> and define a range
<blake_r> then Juju will only use those IP's
<cnf> blake_r: and then add the same subnet again?
<blake_r> cnf: how does it not fix your problem?
<cnf> and maas won't mind that?
<blake_r> you add the whole subnet, and set that subnet to unmanaged
<blake_r> in that subnet you create an IP range
<blake_r> MAAS will only use those IP's in that range
<cnf> there is a /24, out of which i have non - sequential a /29 and a /28
<cnf> with different purposes
<blake_r> cnf: that is fine
<blake_r> cnf: add the whole /24
<cnf> so i need to add the same /24 twice in maas
<blake_r> cnf: define the range you want your IP's to be assinged in that fall with in the /29 and /28
<cnf> define them where? how do i distinguish between the 2?
<cnf> blake_r: i have no idea what you mean
<blake_r> cnf: what subnets do you have now?
<blake_r> cnf: in MAAS
<cnf> uhm, tons
<cnf> i have the /24
<cnf> the other 2 are a problem
<blake_r> did you add those manually? or where they discovered?
<cnf> i have discovery turned off
<cnf> that was just a mess
<blake_r> "the other 2"? did you add them manually or did they just show up?
<cnf> they are not defined
<cnf> as i don't know how to
<mpontillo> cnf: well, MAAS will "discover" subnets outside of "device discovery"; it will automatically add subnets it finds configured on rack controllers
<blake_r> cnf: okay
<blake_r> cnf: what MAAS version?
<cnf> mpontillo: i have _all_ discovery turned off
<cnf> 2.1.3+bzr5573-0ubuntu1 (16.04.1)
<mpontillo> cnf: there is no option to disable discovery of subnets found on rack controllers
<blake_r> mpontillo: he means device discovery
<blake_r> cnf: with your setup you will want the unmanaged subnet feature
<blake_r> cnf: since that is a subnet that MAAS doesn't manage
<cnf> which i guess is in 2.2
<cnf> right?
<blake_r> sudo add-apt-repository ppa:maas/next-proposed
<blake_r> sudo apt update && sudo apt upgrade
<cnf> yeah, but that would completely break my juju openstack
<blake_r> why is that? thought it didn't work at all?>
<cnf> it's running, just without the ip's from the /29
<cnf> which are the routable ones
<cnf> which means i need weird tunnels to access the openstack
<cnf> because, hell, putting them behind a single ip isn't something that works atm with charms
<cnf> anyway, it's 19:07, time to go home...
<blake_r> cnf: you can set static IP addresses on nodes
<cnf> blake_r: not on containers
<blake_r> cnf: ah true
<cnf> so you need a LOT of routable IP's just to have a workable chams openstack
<cnf> which is what the /29 is for
<cnf> i won't even start on the long, long list of other bugs i have on juju etc :(
<cnf> a lot of which come from assumptions of network layouts
<cnf> anyway, 7 pm, i'm hungry
<cnf> tomorrow is another day
<cnf> i'll have to look at how the new spaces work, i guess
<cnf> thanks for the help
<cnf> aaand home
<mpontillo> cnf: please let us know how things work out (or don't work out) for you; you can bring things up on the maas-devel list and/or the bug tracker (Launchpad) if you want more visibility for your use cases
<mup> Bug #1651316 changed: Disks are found but not shown <MAAS:Fix Released> <https://launchpad.net/bugs/1651316>
<benlake> what does it mean to use the âretain network configurationâ option when commissioning?
<kiko> benlake, the network interfaces, do you want them reset back to unbonded, unvlanned etc?
<kiko> benlake, also, c'mon https://bugs.launchpad.net/maas/+bug/1418044
<benlake> I promise I am going to do that thing!
<kiko> cnf, I'd love you to share the current issues you're running into with juju, ivoks nobuto and I are tracking this closely
<benlake> so network temporarily reset to a defailt state, ignoring any setup done in maas?
<benlake> *setup - any network configuration adjustments setup in maas
<kiko> correct
<benlake> kk
<cnf> kiko: https://bugs.launchpad.net/~cnf is a start :P
<cnf> kiko: a very large part of them are proxy related
<kiko> cnf, you and ivoks would be best friends
<kiko> cnf, we actually started on a plan with jamespage to address that more widely, let me find it
<cnf> kiko: i have been in contact with jamespage for most of it
<cnf> also, place i work at is launching an RFI for an openstack install
<cnf> so i'll be using that  channel to add some weight to some issues
<kiko> cnf, https://www.dropbox.com/s/qvhi0wyfj87tyxq/PROXY.txt
<kiko> cnf, see if that matches what you think could work. there is backwards-compatibility problem thrown in the mix but it should be solvable
<benlake> finally have a fully deployed node. really surprised the base install is 9.5GB O.o
 * benlake checks if he installed Windows
<cnf> kiko: you can add "openstack picks up htt-proxy and ignores no-prozy"
<kiko> benlake, 9.5GB can't be right. fully deployed with what?
<benlake> ubuntu xenial
<kiko> benlake, uhhh that can't be right
<benlake>  /dev/mapper/vgroot-lvroot  219G  9.5G  199G   5% /
<kiko> cnf, "openstack" as in the system or the charms or what?
<cnf> kiko: openstack as installed with charms
<cnf> totally ignores no-proxy settings
<cnf> so _nothing_ can talk to keystone
<cnf> because my proxy can't talk to keystone
<kiko> cnf, but my question is whether the charms themselves ignore no_proxy or whether the systems are configured without them or..?
<cnf> oh, no, no-proxy envs are set
<cnf> it's populated wherever i know to look?
<cnf> but openstack just seems to ignore it
<cnf> which isn't a juju problem, of course
<kiko> hmm... that's weird.
<cnf> but it causes problems with other software, which i can't fix with juju
<kiko> so how does http_proxy get used by openstack itself?
<cnf> kiko: whish is where https://bugs.launchpad.net/juju/+bug/1681495 came from
<benlake> well, I found the reason./swap.img is 8GB
<cnf> kiko: yes
<kiko> does it pick up from env vars set when launching the control plane services?
<kiko> benlake, that looks more like it
<benlake> I guess weâve switched to file based swap!
<cnf> kiko: it sure looks that way, yes
<cnf> kiko: jamespage was involved with debugging this, byw
<kiko> benlake, maybe we do that if you don't define a swap partition? I'm surprised tbh, also because I'm not a big fan of file based swap for i/o path reasons
<benlake> slightly unfortunate side effect of that transition is that the swap space is hidden. guess Iâll get used to that
<kiko> benlake, can't you just define a swap partition?
<benlake> I did nothing special, just pushed buttons to get a thing deployed. wanted to see a success before mucking around
<benlake> I have an existing PXE+preseed environment. Is there somewhere I can use my existin pressed with MAAS?
<benlake> or do some merging?
<benlake> honestly, I need to continue reading the docs. This is the farthest Iâve made it, and most of my time had been on reading setup and troubleshooting
<cnf> kiko: i also have a need for the openstack loadbalancer charm
<cnf> but i understand resources are not available for that atm
<kiko> cnf, for lbaasv2?
<cnf> kiko: http://specs.openstack.org/openstack/charm-specs/specs/pike/approved/openstack-load-balancer.html
<kiko> cnf, oh, on the infra layer -- L3 HA basically
<cnf> uhu
<cnf> solves HA, AND openstack services not being on routable networks
<kiko> we are probably likely to have to work on this -- our telco customers all have these requirements
<cnf> count me as "a telco customer" :P
<kiko> and for many of them we've done the setup manually
<cnf> kiko: our contact at canonical is Richard Card, i believe
<kiko> cnf, oh are you an existing customer?
<cnf> well, we just launched an RFI
<cnf> we'll be doing an RFP end Q3, early Q4?
<kiko> ah, yes, I read it earlier this week
<cnf> it under Telenet, or Liberty Global
<cnf> i think it's under Telenet
<sanjay> hi
<sanjay> I have an issue for node deployment in maas
<sanjay> the deployment of ubuntu os gets completed but at last moment the system goes to grub rescue mode
<sanjay> and then doesn't move on for deployment suceessfull
<benlake> interesting. Iâm configuring the firewall of the maas controller, and Iâve noticed that enlisting discovers the power type when the firewall is off, but is unable to discover it with the firewall on. What service is providing that discovery?
<benlake> I figured itâd all be happening on the server using local IPMI tools and then hitting the maas api with the deets
<benlake> maybe a round trip to the api, to trigger a reach out to the IPMI to confirm, but Iâm not blocking outbound connections, so not sure why that would break.
#maas 2017-05-24
<benlake> guess Iâll answer my own question. Apparently the HTTP proxy plays a part in the IPMI discovery. Opened TCP 8000 and enlistment was able to determine the power type to be IPMI 2.0
<pmatulis> that's very odd
<benlake> trial and error got me there.
<pmatulis> roaksoax, possible? ^^
<benlake> but I suppose my trials could have had an error :D
<benlake> watched dropped packets on MAAS, opened things up until enlistement revealed the power type as it had with no firewall
<BjornT> benlake: maas installs the ipmitool package on the machine. if it can't use the http proxy, it can't install that package, and thus not determine the power type.
<cnf> morning
<BjornT> good morning cnf
<cnf> \o
<sachi> Hi All
<sachi> i am using maas 1.9 version
<sachi> is there support to deploy 16.04 for any provision
<roaksoax>  /win 6
<benlake> BjornT: ah, that makes sense.
<roaksoax> sanjay: you can deploy 16.04 with 1.9
<roaksoax> sanjay: you cannot commission with 16.04 in 1.9
<sanjay> i have mass 2.1.5
<sanjay>  I can commission nodes
<sanjay> but while deploying at last moment its shows error of grub rescue>
<sanjay> node is at final stage to get delpoyed but if grub rescue doesnt come
<roaksoax> sanjay: that seems like a deployment failure
<roaksoax> sanjay: grab the installation log from the UI
<roaksoax> on the node that failed
<roaksoax> go to the bootom part
<roaksoax> where the machine output is
<roaksoax> and on the dropdown select installation log
<roaksoax> and pastebin that
<sanjay> error: attempt to read or write outside of disk 'hd0'
<roaksoax> sanjay: can you pastebin it all please ?
<sanjay> i can see the outputsummary logs from webui
<sanjay> how to use pastebin
<sanjay> https://pastebin.com/xWCE4PYT
<roaksoax> sanjay: on the dropdown menu, what options do you have on that sectio n?
<mup> Bug #1693255 opened: [2.2, UI] Cannot add an interface when the machine is "NEW' <MAAS:New> <https://launchpad.net/bugs/1693255>
<mup> Bug #1693256 opened: [2.2, UI] Cannot add an interface when the machine is "NEW' <MAAS:Triaged> <https://launchpad.net/bugs/1693256>
<xygnal> after setting boot disk for a machine in maas
<xygnal> how do I apply that?  the machine still shows sda as the boot disk, even though I got a 200 back from the API :/
<xygnal> well let me put it this way, it still shows up as the install disk in the storage tab.  do I need to combine boot disk with something else to change the install disk?
<benlake> Iâm very new to MAAS, but I get the impression any changes such as the one you speak are Deploy time implemented only.
<benlake> I donât think it is designed to make changes post deploy
<sanjay> one more thing
<sanjay> does we need to have atleast 2 disks on server
<sanjay> or with 1 disk also OS can be deployed
<benlake> one disk is fine. what is your thinking around needing 2 disks?
<sanjay> no just asking
<sanjay> do we need to do any partition
<sanjay> it creates on GPT partition and other part-2 partion with full disk
<kiko> if you are using EFI, yes
<benlake> sanjay: before you deploy, you can mess with the partitioning scheme on the node
<benlake> unfortunately there doesnât appear to be a way to save that scheme and apply it to other machines. I assume this isnât a new thought and someone is thinking about custom layouts, eventually.
<kiko> benlake, we're working on that right now in fact
<kiko> the first iteration will be a dump-to-yaml and upload-yaml
<benlake> look at that, heroes of the people
<benlake> thatâs a good start
<benlake> removes all the UI work
<kiko> we are also doing something interesting for our use case, which is grouping machines into buckets of "identical" config
<kiko> so you'll be able to easily configure a set of machines with the same layout
<kiko> and by identical config, layout I mean # and type of NICs, drives, and cpu/core and RAM count
<cnf> kiko: accepted :P
<kiko> thanks!
<cnf> :P
<mup> Bug #1693299 opened: MAAS allows any image name to be uploaded by only known images can be deployed <MAAS:Triaged by ltrager> <https://launchpad.net/bugs/1693299>
<mup> Bug #1693299 changed: MAAS allows any image name to be uploaded by only known images can be deployed <MAAS:Triaged by ltrager> <https://launchpad.net/bugs/1693299>
<mup> Bug #1693299 opened: MAAS allows any image name to be uploaded by only known images can be deployed <MAAS:Triaged by ltrager> <https://launchpad.net/bugs/1693299>
<sanjay> Guys i have deployed 4 nodes..i created one /boot partition and other / root partition and started deployed and it worked for me
<sanjay> thanks all for your support
<sanjay> hope this can be helpful to other people who are facing same error
<benlake> kiko: +1 to identical layouts
<kiko> benlake, thanks -- I think it's going to be really useful
<ThiagoCMC> hey guys, is it possible, via MaaS -> Interfaces, to create OpenvSwitch Bridges? And not only Linux Bridges...?
<pmatulis> kiko, i think this is also on the map but, to be sure, please allow (storage) percentages when changing a layout
<pmatulis> currently sizes need to be in, gulp, bytes
<kiko> pmatulis, yes indeed
<kiko> ThiagoCMC, not currently
<ThiagoCMC> Hmm... Ok!
<sanjay> does anyone can give exact layout in % wise when doing partition manually
<maticue> Hi everyone! I see that maas region controller and maas rack controller DNS registers are under ".maas" domain. Is is possible to change these domains? Can be different for rack controller and region controller? Finally, could some one guide me and tell me how to change this?
<maticue> nobody?
<ThiagoCMC> you can add more domains
<ThiagoCMC> and move the nodes to it, before deploying
<sanjay> Mass dhcp not running
<sanjay> can anyone please let me know how to start it
<ThiagoCMC> reboot
<ThiagoCMC> =P
<maticue> ThiagoCMC: I created more domains , I also deployed new servers and I know how to assign them to the new domains. However, I can't do this with maas rack controller and maas region controller
<xygnal> roaksoax: seems root_disk is ignored on custom image?
<roaksoax> benlake: https://bugs.launchpad.net/maas/+bug/1418044/comments/3 -> in your comment there, what version of MAAS are you using? What was set in /etc/maas/regiond.conf and what was set in /etc/maas/rackd.conf ?
<roaksoax> xygnal what is the custom image you are trying to deploy ?
<xygnal> a centos7 cloud image we have made some tweaks on
<ThiagoCMC> Guys, at the end of a deployment, I'm seeing the following message: "cloud-init[XXXX]: Can not apply stage final, no datasource found!"
<ThiagoCMC> What to do?
<ThiagoCMC> I'm running MaaS Next
<ThiagoCMC> It was working this morning but, I updated the box because a new package appeared on MaaS Next PPA...
<roaksoax> xygnal: at the moment we dont support any storage config for centos, I think that's the culprit.
<roaksoax> xygnal: you could customize the image curtin hooks to install where you need them to
<roaksoax> ThiagoCMC: has it caused a failed deployment ?
<ThiagoCMC> I was stucked...
<ThiagoCMC> I rebooted the node, boom! It worked!
<roaksoax> ThiagoCMC: strange, it would be interesting to see the full cloud-init log if you can grab that
<ThiagoCMC> Sure, I'll collect it and post on pastebin
<roaksoax> ThiagoCMC: but final has had tiny bug fixes not at all related to metadata server or anything of the sorts
<ThiagoCMC> Hmm... I see
<ThiagoCMC> which file should I collect?
<roaksoax> ThiagoCMC: /var/log/cloud-init*.log from the ephemeral env if you can, and also /var/log/maas/regiond.log and maas.log
<ThiagoCMC> ok
<ThiagoCMC> roaksoax, figured out! For some reason, MaaS picked up the wrong subnet for a fabric... So, it gave two IPs from the same subnet, to two different segments, which was causing problems with the communication between cloud-init and the metadata server.
<xygnal> roaxsoak: is that neccesary? can customs or centos not use root_device?
<xygnal> roaxsoak ok i see.  any example code?
<xygnal> roaxsoax: going to need a little more info on using curtain
<xygnal> roaxsoax: for that purpose
<xygnal> using block-meta?
<roaksoax> xygnal: so IIRC< curtin will pick up the first device it finds in the list
<mup> Bug #1693358 opened: VLAN name mismatch between web UI and API <MAAS:New> <https://launchpad.net/bugs/1693358>
<roaksoax> xygnal: and on the OS' where we dont configure the underlying store, like centos, we dont pass along any storage config because that could actually break the deployment of things
<xygnal> do i neee to pre-label it so it knows to pick it up?
<xygnal> label=root or such?
<roaksoax> xygnal: i need to step out right now. I'll try to come back later, but otherwise we can pick that up tomorrow
<xygnal> ok.
<xygnal> where does my curtin_userdata_custom need to be, region or rack server?
<mup> Bug # changed: 1687420, 1688060, 1689288, 1689838, 1690144
#maas 2017-05-25
<benlake> roaksoax: noted, will add.
<benlake> kiko: ThiagoCMCâs situation sounds familiarâ¦ but why would an update cause a redisovery of IPs, or is that more likely related to him probably adding subnets or a fabric or something?
<xygnal> roaksoax i'll be around if you do come back, i'd like to verify what is needed in my curtin config to ensure it uses them.  Right now my storage blocks are not being used, though its not throwing errors either in the logs.
<chrome0> Hi maas maintainers, do you have a timeline when you plan to pronounce 2.2 stable? I believe it's  currently labeled devel as it's in ppa:maas/next right?
<chrome0> But maybe I'm confused about that devel label, as maas 2.2 is actually released with Zesty?
<jamespage> congrats on the 2.2 release MAAS folks - looks awesome!
<benlake> jamespage: where are you seeing 2.2 as released? I ask because Iâm actually quite confused as to what package version is current and with what release
<jamespage> benlake: https://docs.ubuntu.com/maas/2.2/en/release-notes
<benlake> my 16.04.02 box installed 2.1.3 a few days ago, but according to packages.ubuntu.com it should only be 2.0.0-beta3   O.o
<jamespage> I think its still +1 week off being in the stable PPA - roaksoax would be able to confirm that
<jamespage> benlake:
<jamespage>  maas | 2.1.3+bzr5573-0ubuntu1~16.04.1    | xenial-updates   | source, all
<jamespage> 2.1.3 is in xenial-updates
<benlake> even still I look at https://launchpad.net/maas/+packages and it says xenial should be at 2.1.5, but I donât show an upgrade path to it via apt
<jamespage> I think 2.2.x will end up there once its been through SRU
<jamespage> benlake: try "rmadison maas"
<jamespage> its a easier view of what is where
<jamespage> 2.1.5 is in xenial-proposed ATM
 * chrome0 would be eager to know when 2.2 lands in stable too 
<benlake> oic https://launchpad.net/ubuntu/xenial/+source/maas
<benlake> what is rmadison?
<roaksoax> benlake: http://www.roaksoax.com/
<roaksoax> benlake: http://www.roaksoax.com/2017/05/maas-2-2-0-released
<benlake> ah, thanks
<chrome0> aluria : ^^ maas 2.2 to be avail in maas/stable next week and in xenial in the following weeks
<chrome0> roaksoax : typo alert, you probably meant "has _now_ been released..."
<aluria> chrome0: thx for the heads-up
<roaksoax> chrome0: thanks!
<chrome0> nw at all
<xygnal> roaksoax hello :)
<roaksoax> xygnal: howdy! i'm otp for the next ~2-3 hours, but share with me whta you have and i can look as meetings go
<xygnal> roaksoax: do I need more than a storage block to convince curtin to install on a different disk?  Just setting the disks, partitions, and mounts does not seem to be enough.
* roaksoax changed the topic of #maas to: World's best bare-metal provisioning tool | Docs: http://maas.io/docs | Mailing list: https://lists.ubuntu.com/mailman/listinfo/maas-devel
* roaksoax changed the topic of #maas to: World's best bare-metal provisioning tool | Docs: http://maas.io/docs | Mailing list: https://lists.ubuntu.com/mailman/listinfo/maas-devel | MAAS 2.2.0 now released!
<roaksoax> xygnal: checking that now.
<xygnal>  roaksoax my co-worker says those blocks appeared to work, but only if the boot disk in the servers BIOS was set to boot that disk.
<xygnal> roaksoax we also can't use the same hard-coded disk every time for every model.   Can we do some kind of pre-script for storage that grabs that and makes it a variable?
<roaksoax> xygnal: what do you mean with the latter ?
<xygnal> roaksoax storage section in curtin needs a hard-coded device name
<xygnal> roaksoax but we have different models, where the device name woud not be identical
<xygnal> roaksoax can we gather that information and pass it into curtin?
<xygnal> so that it is no longer a hard coded disk path
<roaksoax> xygnal: ok, so in the preseed you have access to the 'node' objects
<xygnal> i've never played with tthose.  link me a example?
<roaksoax> xygnal: i'll give you in a sec. So If I understand correctly
<xygnal> I can set boot and root in the API, they just dont apply.  If I can tell Curtin to use that information, we essentially get around the 'not supported' problem.
<ThiagoCMC> Guys, MaaS Next is weird!
<ThiagoCMC> It is failing to test a server...
<ThiagoCMC> Error, `smartctl --xall /dev/sda -d sat` returned 24! See the smartctl man page for return code meaning
<ThiagoCMC> Say what?
<ThiagoCMC> =/
<ThiagoCMC> blade was just working fine until I tried to re-commision it
<kiko> have you tried doing what the message suggests?
<ThiagoCMC> yep... researching but, no clue
<xygnal> start rescue mode on the node and try to execute that command via ssh
<ThiagoCMC> Is there any way to ignore that?
<ThiagoCMC> cool!
<roaksoax> ThiagoCMC: that could indicate that there's an error with your disk :) but also if you havea a full pastebin we could look would be great
<roaksoax> ThiagoCMC: that said, you can decide not to perform hardware testing on commissioning
<ThiagoCMC> Hmm...
<roaksoax> ThiagoCMC: iy could also mean smart is not supported on your disks
<mcuenca> hi everyone! maas region controller and maas rack controller are created under ".maas" dns domain. Is it possible to change that?
<roaksoax> mcuenca: https://bugs.launchpad.net/maas/+bug/1686678
<mcuenca> roaksoax: thanks! so, it is a bug, no problem. For sure the guys will resolve it. I'll try a workaround using CNAMEs... should work, right?
<roaksoax> mcuenca: yes it should work
<mcuenca> roaksoax: thanks! :D
<mcuenca> roaksoax: I'll try in 30 minutes and I'll let you know
<mcuenca> roaksoax: solved :) thanks!
<ThiagoCMC> Is there an easy way to move a VLAN / subnet from fabric-1, to another fabric?
<pmatulis> ThiagoCMC, did you try via the CLI?
<ThiagoCMC> pmatulis, not really, I'm not familiar with CLI... I'll research about it! Tks!
<benlake> so, if you toast your network connection to a server after deployment, there isnât a password for the ubunut user to use via IPMI KVM, is there?
<benlake> I get SSH is public key only, but is the expectation if there is a desire to directly access the machine, you should set the password after deployment?
<mpontillo> benlake: that is correct
<benlake> thanks
<mpontillo> benlake: np. with kvm console access you should be able to recover in a normal way, such as init=/bin/bash on the kernel command line or some similar incantatin (haven't had to do that in awhile so I don't remember exactly)
<mpontillo> *incantation
<mpontillo> of course, that assumes you'd be okay with rebooting
<benlake> gotcha
<mpontillo> benlake: right, I think something like this still applies, even though the post is pretty old. https://askubuntu.com/questions/24006/how-do-i-reset-a-lost-administrative-password
<mpontillo> (heh, init=/bin/bash, that was a trick I used probably 20 years ago.)
<benlake> with devices you can define a parent. Is there not a way to assign a machine to machine relationship similarly?
<benlake> use case being kvm guests. would be nice to have the metadata as to which machines will die with the base machine
<benlake> anyone else being bit by the bridge forwarding delay âout of rangeâ issue? supposedly a fix is in kernel v4.4.8 - thatâs a ways off for xenial, no?
<catbus1> Hi, a question about the IP mode in https://docs.ubuntu.com/maas/devel/en/installconfig-commission-nodes#post-commission-configuration
<catbus1> If it's a managed subnet and if auto assign is selected, the node will get the IP not in the reserved IP range. But if it's dhcp, the node will get the IP from the reserved dynamic IP range?
<benlake> Re: forwarding delay. Value must be less than âhelloâ time; unless STP is off.
 * catbus1 finds managed vs unmanaged and reserved IP range confusing. 
<benlake> catbus1: I do as well.
<benlake> so auto assign uses anything not reserved
<benlake> dynamic range is for DHCP
<catbus1> another question, can I assume the fabric will show up as 1:1 mapping to the physical interfaces on the machine?
<benlake> reserved range is unused by MAAS
<catbus1> but reserved IP range is used by MAAS and the subnet is in unmanaged mode.
<benlake> when you say âis used by maasâ, where did you see maas us it?
<catbus1> *when* the subnet is in unmanaged mode.
<catbus1> "When management is disabled for a subnet, the definition of aÂ reserved IP rangeÂ differs from the managed mode. Here, aÂ reserved IP rangeÂ tells MAAS toÂ only allocate addresses from this rangeÂ (via 'Auto assign'). In addition, DHCP will never lease addresses from an unmanaged subnet." from https://docs.ubuntu.com/maas/devel/en/installconfig-network-subnet-management
<benlake> what version of maas are you using?
<benlake> Iâm 2.1.3 and I have no âmodeâ for a subnet.
<catbus1> I am on 2.2
<mup> Bug #1693644 opened: Enlistment does not validate min_hwe_kernel <MAAS:In Progress by ltrager> <https://launchpad.net/bugs/1693644>
<benlake> oic, then thatâs new to me.
<benlake> but reading that, it apparently changes the âreserved rangeâ that would otherwise not be used in âmanagedâ mode, to the range that will explicitly be used in âunmanagedâ mode.
<catbus1> yes.
<benlake> that ^^ is the answer to your original question :)
<catbus1> but if it's unmanaged, why is maas giving out ip addresses?
<benlake> did you reserve a range from this unmanaged subnet?
<catbus1> I didn't do anything yet, I am trying to understand first what's the expected behavior.
<benlake> if so, then MAAS will use it for any interface using âauto assignâ (at least that was the 2.1 term)
<benlake> if you donât want an unmanaged subnet to be used in any way, then just defined it as unmanaged and leave it alone
#maas 2017-05-26
<roaksoax> catbus1: a managed subnet can have 2 types of ranges. 1. DHCP range (dynamic) and 2. reserved.
<roaksoax> catbus1: machines with "auto assign" will get ip's from *outside* those two ranges
<roaksoax> catbus1: machines that PXE boot for enlistment, commissioning or dhcp from MAAS, will get ip's from (1)
<roaksoax> catbus1: there's no such thing as static range anymore
<catbus1> roaksoax: and for the unmanaged subnet?
<maas-user> hello there. i just installed maas on my ubuntu installation, however i cannot access the UI. can sb assist please?
<roaksoax> catbus1: the unmanaged subnet basically says "this subnet is not managed by MAAS, but you can assign IP's in this subnet to specific machines"
<roaksoax> catbus1: in other words, if set to "auto-assign" maas wont provide an IP
<roaksoax> catbus1: *unless* there is a reserved range that says "this subnet is unmanaged by maas, but I have X range available to use"
<roaksoax> catbus1: note that MAAS 2.x manages *subnets* vs managing *ranges* in 1.x
<roaksoax> maas-user: http://localhost:5240/MAAS
<roaksoax> maas-user: did you create a admin user too ?
<maas-user> yes
<maas-user> Unable to connect
<maas-user> no service is listening on port 5240
<roaksoax> maas-user: tail -f /var/log/maas/*.log
<maas-user> http://paste.offsec.com/?af2f6b324e476dd4#lqowLxlvi59s5n7WYwLMp8DFBV3X3TF0cRhaxZ5xcQU=
<maas-user> looks like having disabled ipv6 might cause this: https://bugs.launchpad.net/maas/+bug/1663340
<maas-user> ok i am going to reboot to check if that solves the problem.
<catbus1> roaksoax: another question, can I assume the fabric will show up as 1:1 mapping to the physical interfaces on the machine? "AÂ fabricÂ is a set of interconnected VLANs that are capable of mutual communication. A fabric is a logical grouping of unique VLANs. A default fabric ('fabric-0') is created for each detected subnet when MAAS is installed." <-- what does this mean?
<roaksoax> catbus1: e.g
<roaksoax> rack controller has:
<roaksoax> eth0
<roaksoax> eth0.10
<roaksoax> etho.20
<roaksoax> eth1.30
<roaksoax> eth1.40
<roaksoax> catbus1: that wil reflect on
<roaksoax> fabric-0 with untagged, vlan10 and vlan20
<roaksoax> fabric-1 with untaged, vlan30, vlan40
<maas-user> ok looks like maas now works when enabling ipv6.
<catbus1> roaksoax: OK. why don't we just list fabric-0 the interface name, and list vlan and subnet accordingly based on discovery.
<catbus1> and  A default fabric ('fabric-0') is created for each detected subnet when MAAS is installed.'
<catbus1> and 'A default fabric ('fabric-0') is created for each detected subnet when MAAS is installed.' is this correct statement? I could have subnet defined for each vlan, but only 1 fabric-# is created for each detected interface, right?
<roaksoax> catbus1: the fabric auto-creating is a best case attempt to auto-discover things
<roaksoax> catbus1: it is not exact science
<roaksoax> catbus1: the goal of it is to try to discovery different fabric/vlans
<roaksoax> catbus1: the goal of it is to try to discovery different fabric/vlans/subnets
<roaksoax> and whether they can mutually communicate
<roaksoax> catbus1: a fabric is 1 or multiple switches that are trunked to each other
<roaksoax> catbus1: so in my example, you are saing that fabric-0 (switch1, switch2, switch3) has 3 vlans, untagged, vlan10, vlan20
<catbus1> thanks for the explanation. i will play with it to get myself familiar with the concepts and terms.
<ThiagoCMC> Hey guys, to change MaaS' server own IP, can I just update its /etc/network/interfaces file and reboot it?
<roaksoax> ThiagoCMC: yup
<roaksoax> ThiagoCMC: all you need
<ThiagoCMC> Perfect!
<catbus1> the cloud-init handler.py at the deployment phase shows failed posting event: finish or start of various modules. where should I look at to stop this from happening, it seems it's taking a long time for each try, at the end deployment failed due to curtin failures.
<catbus1> nm. will move on to work on something else now.
#maas 2017-05-27
<mup> Bug #1660179 changed: [2.1.2] A number of servers fails Deployment following PXE local boot at around same time <oil> <MAAS:Expired> <https://launchpad.net/bugs/1660179>
<mup> Bug #1669548 changed: rack controller drops initial registration with region <MAAS:Expired> <https://launchpad.net/bugs/1669548>
<testengr> hello
#maas 2017-05-28
<mup> Bug #1676461 changed: Interface links differ from newly commissioned nodes vs recommissioned nodes with previously set interfaces <MAAS:Expired> <https://launchpad.net/bugs/1676461>
#maas 2018-05-21
<app> hello?
<mup> Bug #1732389 changed: [2.3rc3, UI] The padding of the icon in the commissioning list is not right <2.3qa> <papercut> <ui> <MAAS:Fix Released by deadlight> <https://launchpad.net/bugs/1732389>
<mup> Bug #1721454 changed: Finding how to rename a node is difficult <confusing-ui> <ui> <ux> <MAAS:Triaged by m-vrachnis> <https://launchpad.net/bugs/1721454>
<mup> Bug #1657851 changed: [UI, 2.2] CSS refers to image-background-paper.png, which no longer exists <ui> <MAAS:Fix Released by deadlight> <https://launchpad.net/bugs/1657851>
<mup> Bug #1680790 changed: [Device discovery - Enable/Disable toggle] The tooltip works as a button to interact with the toggle <papercut> <ui> <MAAS:Fix Released by deadlight> <https://launchpad.net/bugs/1680790>
<mup> Bug #1728891 changed: [2.3b3, UI] In Pods, the composed machine column header works only once for sorting the column  <2.3qa> <ui> <MAAS:Fix Released by deadlight> <https://launchpad.net/bugs/1728891>
<mup> Bug #1681401 changed: [UI, 2.2.0rc2] Pods overview - Pods table broken at 1024px resolution, 'composed machines' row heading truncates below table in centre <ui> <MAAS:Fix Released by deadlight> <https://launchpad.net/bugs/1681401>
<mup> Bug #1681800 changed: [2.2, UI] The (row) contextual menu didn't close when I clicked on Take action <papercut> <ui> <ux-qa-2.2> <MAAS:Fix Released by deadlight> <https://launchpad.net/bugs/1681800>
<mup> Bug #1771465 changed: Unable to create tabs in MAAS 2.4.0~beta2-6865-gec43e47e6-0ubuntu1 <MAAS:Invalid> <https://launchpad.net/bugs/1771465>
<mup> Bug #1772490 opened: deployment timed out after 40 minutes <MAAS:New> <https://launchpad.net/bugs/1772490>
<mup> Bug #1772490 changed: bcache: register_bcache() error <curtin:New> <MAAS:Invalid> <linux (Ubuntu):New> <https://launchpad.net/bugs/1772490>
<mup> Bug #1772490 opened: bcache: register_bcache() error <curtin:New> <MAAS:Incomplete> <linux (Ubuntu):New> <https://launchpad.net/bugs/1772490>
<mup> Bug #1772511 opened: [2.3,2.4] op=netboot_off no longer logged in regiond.log <MAAS:New> <https://launchpad.net/bugs/1772511>
<mup> Bug #1717983 changed: replacement of isc-dhcp-client with with systemd-networkd for dhclient needs integration <amd64> <apparmor> <apport-bug> <artful> <id-59c57605d1dfa992a27e9102> <netplan-transition> <avahi (Ubuntu):Invalid> <cloud-init (Ubuntu):In Progress> <controlaula (Ubuntu):Invalid>
<mup> <ddclient (Ubuntu):Triaged> <maas (Ubuntu):Invalid> <madwimax (Ubuntu):Triaged> <ntp (Ubuntu):Fix Released> <openresolv (Ubuntu):Won't Fix> <resolvconf (Ubuntu):Won't Fix> <samba (Ubuntu):New> <sendmail (Ubuntu):New> <ubuntu-meta (Ubuntu):Triaged> <https://launchpad.net/bugs/1717983>
#maas 2018-05-22
<mup> Bug #1772616 opened: Duplicate MAC or hostname causes MAAS to confuse rack controllers <sts> <MAAS:New> <https://launchpad.net/bugs/1772616>
<tosaraja> any advice on how to proceed? I upgraded my Ubuntu 16.04 running MAAS 2.2.2 to first 2.3 and now to Ubuntu 18.04 running 2.4 with the result that I get this and nothing starts: provisioningserver.rpc.clusterservice: [critical] Failed to contact region. (While requesting RPC info at b'http://[::1]:5240/MAAS/rpc/').
<ananke> I'm completely baffled. something had to be introduced lately in maas that breaks all of my c6100 nodes. they kernel panic after trying to boot
<ananke> and i'm running the 'stable' 2.3.3
<roaksoax> win /win 4
<enrico_> hello community.. I have a gap somewhere, hope you can help! I have two bare-metal on the same network without dhcp, on the first server I installed centos, then kvm, then ubuntu, then maas into ubuntu vm
<enrico_> on the second bare-metal just centos
<enrico_> but I dont detect the second machine
<enrico_> both server are two Dell PowerEdge R430
<enrico_> I activate IPMI in order to use PXE on the second server
<enrico_> the dhcp.maas is not assigning ip on the second server
<enrico_> do you have any suggestion/remark/advise ? anything is accepted thanks you
<roaksoax> enrico_: hi there. I dont fully understand how your environment is setup. If you have more info on that it would be helpful.
<roaksoax> enrico_: but if you are running maas on a vm, you would need tomake sure that there's a bridge on the same network as the other machine
<enrico_> yes that's it bridge between vm interface and host on the same network
<enrico_> I gave static addr to these machines
<enrico_> and I able to ping the internet
<enrico_> I am*
<enrico_> form the gui interface dhcp It seems working
<enrico_> but is does not due to in the second server I dont get any ip addr ever with specific request dhclient
<roaksoax> enrico_: check whether dhcp is runnning first
<roaksoax> enrico_: against the rgityh interface inside the VM
<roaksoax> and if it is, i would think its an issue with the bridge
<enrico_> ok do you know if maas run dhcpd service or an internal one?
<roaksoax> enrico_: maas runs its own iosc-dhcp
<roaksoax> well, it is isc-dhcp just a different job/thread for it
<enrico_> systemctl status iosc-dhcp ?
<enrico_> roaksoax yes problem with dhcp service
<enrico_> thanks you
<mup> Bug #1772679 opened: builtins.ValueError: too many values to unpack (expected 3) <MAAS:New> <MAAS 2.4:New> <https://launchpad.net/bugs/1772679>
<roaksoax> enrico_: maas has maas-dhcpd e.g. sudo service maas-dhcpd status
<enrico_> yes checked and not there
<enrico_> I just install maas from package
<enrico_> trying by ISO
<Deknos> your docs-url is outdated.
<sentinel-prime>  roaksoax as far as i can tell it still isn't working it keeps hanging on reached tagetcloud-init target also it has troble geting files from the internet
#maas 2018-05-23
<sentinel-prime> roaksoax you still here
<BlackDex> Hmm, i just tried to deploy ubuntu 16.04 on a few systems and it failed because it tried to fetch stuff via ipv6, but there is no ipv6 available
<myrat> hello blackdex
<rbasak> I believe Ubuntu will in general only try to fetch stuff via IPv6 if it's been told that IPv6 is available.
<rbasak> Perhaps your network is advertising IPv6 availability even though it isn't?
<BlackDex> Hmm, it shouldn't
<BlackDex> lets see
<BlackDex> i will try to check it again
<vogelc> Can I deploy windows images without paying for support?  I can upload a Windows image but it will never sync with the controllers
<mup> Bug #1772906 opened: Pods can't be updated via the API without passing power_address <MAAS:In Progress by bjornt> <https://launchpad.net/bugs/1772906>
<mup> Bug #1772490 changed: 'Deploying' timed out after 40 minutes / Failedbcache: register_bcache() error <curtin:Invalid> <MAAS:Invalid> <linux (Ubuntu):Incomplete> <https://launchpad.net/bugs/1772490>
<sentinel-prime> roaksoax as far as i can tell it still isn't working it keeps hanging on reached tagetcloud-init target also it has troble geting files from the internet
#maas 2018-05-24
<BlackDex> is there a quick way of configuring multiple nodes which have the same network interface configuration? like i have to manually creat bonds on several nodes. is there a way to do this on all nodes at the same time? or some small script somewhere?
<mup> Bug #1773133 opened: Tooltip for "Enabled" checkbox truncated  in settings/dhcp snippet <2.3rc3> <ui> <MAAS:New> <https://launchpad.net/bugs/1773133>
<mup> Bug #1773150 opened: [2.4.0~rc1] smartctl verify fails due to Unicode in Disk Vendor Name <smartctl> <tests> <MAAS:New> <https://launchpad.net/bugs/1773150>
<roaksoax> BlackDex: i dont have one, but you can do that over the api
<roaksoax> BlackDex: (e.g., create your own scrip)
<BlackDex> roaksoax: i thought so ;)
<BlackDex> thx
<mup> Bug #1768800 changed: [SRU] MAAS 2.4.0beta3 to bionic <maas (Ubuntu):Invalid> <https://launchpad.net/bugs/1768800>
<mup> Bug #1773201 opened: [SRU] MAAS 2.4.0 <maas (Ubuntu):New> <maas (Ubuntu Bionic):New> <https://launchpad.net/bugs/1773201>
<klj1218> Installing MAAS on 18.04, installs version 2.4.0~beta2 ... what's an ETA for a GA release of 2.4.0? Is there another repo I could add to pull more recent builds of 2.4.0, until it's released?
<roaksoax> klj1218: its in the process of being released
<roaksoax> klj1218: e.g. we are preparing it
<roaksoax> klj1218: you could grab it from ppa:maas/next-proposed
<klj1218> roaksoax: ok, thanks ... I assume after GA is released I would then be able to switch over to ppa:maas/stable, right?
<roaksoax> klj1218: yes, or get it from the bionic archive
<mup> Bug #1773201 changed: [SRU] MAAS 2.4.0 <maas (Ubuntu):Fix Released> <maas (Ubuntu Bionic):New> <maas (Ubuntu Cosmic):Fix Released> <https://launchpad.net/bugs/1773201>
<mup> Bug # changed: 1693256, 1730525, 1749210, 1763217, 1763218, 1768870, 1770126, 1770620, 1770741, 1771448, 1771451, 1771461
<mup> Bug # opened: 1693256, 1730525, 1749210, 1763217, 1763218, 1768870, 1770126, 1770620, 1770741, 1771448, 1771451, 1771461
<mup> Bug # changed: 1693256, 1730525, 1749210, 1763217, 1763218, 1768870, 1770126, 1770620, 1770741, 1771448, 1771451, 1771461
<mup> Bug #1773201 opened: [SRU] MAAS 2.4.0 <maas (Ubuntu):Fix Released> <maas (Ubuntu Bionic):New> <maas (Ubuntu Cosmic):Fix Released> <https://launchpad.net/bugs/1773201>
<mup> Bug #1773201 changed: [SRU] MAAS 2.4.0 <maas (Ubuntu):Fix Released> <maas (Ubuntu Bionic):New> <maas (Ubuntu Cosmic):Fix Released> <https://launchpad.net/bugs/1773201>
<mcsmash> Hi guys. I have some questions about dhcp. My controller is set up on a machine with two network interfaces. How do I ensure that MaaS only provides dhcp over a specific one of them?
<roaksoax> mcsmash: you cannot select which interface to enable DHCP on. MAAS uses tghe VLAN information to enable DHCP and automatically selects which interface to do so
<roaksoax> so if your rack controller has an interface in the given VLAN, DHCP will be enabled against that interface
#maas 2018-05-25
<mup> Bug #1773384 opened: [2.5, 2.4, UI] Power status wraps to second line <MAAS:Triaged by deadlight> <MAAS 2.4:Triaged> <https://launchpad.net/bugs/1773384>
<mup> Bug #1773385 opened: [2.5, 2.4, UI] Error as a notification in pod refresh <MAAS:Triaged by deadlight> <MAAS 2.4:Triaged> <https://launchpad.net/bugs/1773385>
<mup> Bug #1773387 opened: [2.5, 2.4, UI] Pod 'Configuration' formatting for 'Type' doesn't match  <MAAS:Triaged by deadlight> <MAAS 2.4:Triaged> <https://launchpad.net/bugs/1773387>
<mup> Bug #1773405 opened: MAAS conflates untagged vlans with vid 0 <MAAS:New> <https://launchpad.net/bugs/1773405>
<enrico_> hello, I have a problem with my maas-dhcp
<enrico_> it does not responding to dhcp requests
<enrico_> I see the request getting till my maas-rack/region-controller
<enrico_> but no offers
<enrico_> I reserved a dynamic range on the subnet
<enrico_> what could I explore?
<mup> Bug #1773422 opened: Discover fabric from LLDP when available <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1773422>
<mup> Bug #1773437 opened: [2.5, UI] Adding a second resource pool after adding a previous one doesn't clear form <MAAS:Triaged by bjornt> <https://launchpad.net/bugs/1773437>
<mup> Bug #1773442 opened: [2.5] MAAS should use python3-libvirt instead of virsh <MAAS:Triaged> <https://launchpad.net/bugs/1773442>
<mup> Bug #1773454 opened: [2.5, UI] Assigning multiple machines to a newly created pool only does for the first machine <resource-pools> <MAAS:Triaged by bjornt> <https://launchpad.net/bugs/1773454>
<mup> Bug #1773455 opened: [2.5, UI] Action menu for 'Set resource pools' has too much whitespace <resource-pools> <MAAS:Triaged> <https://launchpad.net/bugs/1773455>
<mup> Bug #1773456 opened: [2.5, UI] Resource pool listing page should link to the machine listing with a filter <resource-pools> <MAAS:Triaged> <https://launchpad.net/bugs/1773456>
#maas 2018-05-26
<bdx> hello
<bdx> trying set up a storage network, I have these mellanox cx354a 40Gb cards in my nodes
<bdx> it seems I need a driver installed for the ubuntu to recognize the cards
<bdx> I've searched around for this and see a bit of banter in a few bugs and mailing list posts, but no solution
<bdx> solution that allows maas to preload the driver in the ephemeral image
<bdx> such that the 40Gb cards would be accounted for in commissioning
<bdx> and maas would be able to manage the mellanox card interfaces
<bdx> I'm sure people have hit this before
<bdx> so ..... I guess I'm wondering if theres a solid path to managing/installing 3rd party drivers that someone could share with me
<bdx> I'm going to attempt to create a commissioning script to pull down the drivers and install them ... possibly this is the way
<roaksoax> bdx: have you tried /etc/drivers.yaml ?
<mup> Bug #1667863 changed: if a subnet has multiple static routes, the network interfaces file is invalid <cloud-init:Expired> <curtin:Invalid> <MAAS:Expired> <https://launchpad.net/bugs/1667863>
<bdx> roaksoax: I'm seeing something in /snap/maas/current/etc/maas/drivers.yaml
<bdx> roaksoax: I'm not sure that will work for the mellanox drivers, but I'll look into it further
<bdx> thanks
<mup> Bug #1773576 opened: drivers.yaml should live in a writable directory <MAAS:New> <https://launchpad.net/bugs/1773576>
<mup> Bug #1773576 changed: drivers.yaml should live in a writable directory <MAAS:New> <https://launchpad.net/bugs/1773576>
<mup> Bug #1773576 opened: drivers.yaml should live in a writable directory <MAAS:New> <https://launchpad.net/bugs/1773576>
<sentinel-prime> roaksoax you here
#maas 2018-05-27
<mup> Bug #1773671 opened: MAC address column should use mono font <MAAS:New> <https://launchpad.net/bugs/1773671>
<mup> Bug #1773698 opened: observer-mdns fails on unicode issue <MAAS:New> <https://launchpad.net/bugs/1773698>
#maas 2020-05-18
<mup> Bug #1879205 opened: maas config returns "AttributeError: 'Namespace' object has no attribute 'mode'" <MAAS:New> <https://launchpad.net/bugs/1879205>
<mup> Bug #1879205 changed: maas config returns "AttributeError: 'Namespace' object has no attribute 'mode'" <MAAS:New> <https://launchpad.net/bugs/1879205>
<mup> Bug #1879205 opened: maas config returns "AttributeError: 'Namespace' object has no attribute 'mode'" <MAAS:New> <https://launchpad.net/bugs/1879205>
<mup> Bug #1848781 changed: [UI] MAAS keeps collapsing machine listings <ui> <ux> <MAAS:Fix Released by blr> <https://launchpad.net/bugs/1848781>
<mup> Bug #1848781 opened: [UI] MAAS keeps collapsing machine listings <ui> <ux> <MAAS:Fix Released by blr> <https://launchpad.net/bugs/1848781>
<mup> Bug #1848781 changed: [UI] MAAS keeps collapsing machine listings <ui> <ux> <MAAS:Fix Released by blr> <https://launchpad.net/bugs/1848781>
<mup> Bug #1848781 opened: [UI] MAAS keeps collapsing machine listings <ui> <ux> <MAAS:Fix Committed by blr> <https://launchpad.net/bugs/1848781>
#maas 2020-05-19
<mup> Bug #1879416 opened: MAAS no longer handling commissioning script processing failures <MAAS:In Progress by ltrager> <MAAS 2.7:In Progress by ltrager> <https://launchpad.net/bugs/1879416>
<mup> Bug #1879416 changed: MAAS no longer handling commissioning script processing failures <MAAS:In Progress by ltrager> <MAAS 2.7:In Progress by ltrager> <https://launchpad.net/bugs/1879416>
<mup> Bug #1879416 opened: MAAS no longer handling commissioning script processing failures <MAAS:New> <MAAS 2.7:In Progress by ltrager> <https://launchpad.net/bugs/1879416>
<mup> Bug #1879416 changed: MAAS no longer handling commissioning script processing failures <MAAS:New> <MAAS 2.7:In Progress by ltrager> <https://launchpad.net/bugs/1879416>
<mup> Bug #1879416 opened: MAAS no longer handling commissioning script processing failures <MAAS:New> <MAAS 2.7:In Progress by ltrager> <https://launchpad.net/bugs/1879416>
<mup> Bug #1879427 opened: Copying a section of machine commissioning/testing output does not include new lines <ui> <MAAS:New> <https://launchpad.net/bugs/1879427>
<mup> Bug #1879493 opened: 'maas admin boot-resources is-importing' incorrectly reports finished importing, even though the image is still "Waiting for rack controller(s) to sync" or "Syncing to rack controller(s)" <MAAS:New> <https://launchpad.net/bugs/1879493>
<mup> Bug #1879493 changed: 'maas admin boot-resources is-importing' incorrectly reports finished importing, even though the image is still "Waiting for rack controller(s) to sync" or "Syncing to rack controller(s)" <MAAS:New> <https://launchpad.net/bugs/1879493>
<mup> Bug #1879493 opened: 'maas admin boot-resources is-importing' incorrectly reports finished importing, even though the image is still "Waiting for rack controller(s) to sync" or "Syncing to rack controller(s)" <MAAS:New> <https://launchpad.net/bugs/1879493>
<mup> Bug #1879493 changed: 'maas admin boot-resources is-importing' incorrectly reports finished importing, even though the image is still "Waiting for rack controller(s) to sync" or "Syncing to rack controller(s)" <MAAS:New> <https://launchpad.net/bugs/1879493>
<mup> Bug #1879493 opened: 'maas admin boot-resources is-importing' incorrectly reports finished importing, even though the image is still "Waiting for rack controller(s) to sync" or "Syncing to rack controller(s)" <MAAS:New> <https://launchpad.net/bugs/1879493>
<mup> Bug #1879509 opened: IPv4 DHCP and IPv6 "static assign" produces a backtrace <MAAS:New> <https://launchpad.net/bugs/1879509>
<mup> Bug #1879509 changed: IPv4 DHCP and IPv6 "static assign" produces a backtrace <MAAS:New> <https://launchpad.net/bugs/1879509>
<mup> Bug #1879509 opened: IPv4 DHCP and IPv6 "static assign" produces a backtrace <MAAS:New> <https://launchpad.net/bugs/1879509>
<mup> Bug #1879561 opened: 2.7 snap install fails on lxc containers <MAAS:New> <https://launchpad.net/bugs/1879561>
<mup> Bug #1879561 changed: 2.7 snap install fails on lxc containers <MAAS:New> <https://launchpad.net/bugs/1879561>
<mup> Bug #1879561 opened: 2.7 snap install fails on lxc containers <MAAS:New> <https://launchpad.net/bugs/1879561>
<mup> Bug #1879563 opened: snap has no way of getting maas-rack support-dump --networking informatoin <MAAS:New> <https://launchpad.net/bugs/1879563>
<mup> Bug #1879563 changed: snap has no way of getting maas-rack support-dump --networking informatoin <MAAS:New> <https://launchpad.net/bugs/1879563>
<mup> Bug #1879563 opened: snap has no way of getting maas-rack support-dump --networking informatoin <MAAS:New> <https://launchpad.net/bugs/1879563>
#maas 2020-05-20
<mup> Bug #1879493 changed: 'maas admin boot-resources is-importing' incorrectly reports finished importing, even though the image is still "Waiting for rack controller(s) to sync" or "Syncing to rack controller(s)" <MAAS:Invalid> <https://launchpad.net/bugs/1879493>
<mup> Bug #1879772 opened: UI should show default VM composition values <ui> <MAAS:New> <https://launchpad.net/bugs/1879772>
<mup> Bug #1879772 changed: UI should show default VM composition values <ui> <MAAS:New> <https://launchpad.net/bugs/1879772>
<mup> Bug #1879772 opened: UI should show default VM composition values <ui> <MAAS:New> <https://launchpad.net/bugs/1879772>
<mup> Bug #1879772 changed: UI should show default VM composition values <ui> <MAAS:New> <https://launchpad.net/bugs/1879772>
<mup> Bug #1879772 opened: UI should show default VM composition values <ui> <MAAS:New> <https://launchpad.net/bugs/1879772>
<mup> Bug #1879774 opened: UI does not show overcommit configuration for LXD Pods <ui> <MAAS:New> <https://launchpad.net/bugs/1879774>
<mup> Bug #1879772 changed: UI should show default VM composition values <ui> <MAAS:New> <https://launchpad.net/bugs/1879772>
<mup> Bug #1879774 changed: UI does not show overcommit configuration for LXD Pods <ui> <MAAS:New> <https://launchpad.net/bugs/1879774>
<mup> Bug #1879772 opened: UI should show default VM composition values <ui> <MAAS:New> <https://launchpad.net/bugs/1879772>
<mup> Bug #1879774 opened: UI does not show overcommit configuration for LXD Pods <ui> <MAAS:New> <https://launchpad.net/bugs/1879774>
#maas 2020-05-21
<mup> Bug #1879827 opened: Include unsupported_arches in BootResources websocket <MAAS:In Progress by ltrager> <https://launchpad.net/bugs/1879827>
<mup> Bug #1879827 changed: Include unsupported_arches in BootResources websocket <MAAS:In Progress by ltrager> <https://launchpad.net/bugs/1879827>
<mup> Bug #1879827 opened: Include unsupported_arches in BootResources websocket <MAAS:In Progress by ltrager> <https://launchpad.net/bugs/1879827>
<mup> Bug #1879827 changed: Include unsupported_arches in BootResources websocket <MAAS:In Progress by ltrager> <https://launchpad.net/bugs/1879827>
<mup> Bug #1879827 opened: Include unsupported_arches in BootResources websocket <MAAS:In Progress by ltrager> <https://launchpad.net/bugs/1879827>
<mup> Bug #1879827 changed: Include unsupported_arches in BootResources websocket <MAAS:In Progress by ltrager> <https://launchpad.net/bugs/1879827>
<mup> Bug #1879827 opened: Include unsupported_arches in BootResources websocket <MAAS:In Progress by ltrager> <https://launchpad.net/bugs/1879827>
<mup> Bug #1879933 opened: ppc64el / arm64 - issues with cloud-init setting default route <MAAS:New> <https://launchpad.net/bugs/1879933>
<mup> Bug #1879978 opened: maas status always says supervisord is restarting without sudo <MAAS:Triaged> <https://launchpad.net/bugs/1879978>
<mup> Bug #1879979 opened: [UI,feature] Subnets page should distinguish between DHCP and DHCP Relay <MAAS:New> <https://launchpad.net/bugs/1879979>
<mup> Bug #1879986 opened: [UI] Updated node-script not showing in UI <MAAS:New> <https://launchpad.net/bugs/1879986>
<mup> Bug #1879988 opened: MAAS packages for bionic are beta in ppa:maas/2.7 <MAAS:New> <https://launchpad.net/bugs/1879988>
<fritchie> Maas created an ipmi user on all nodes named maas, where is the password for this user account stored?
<fritchie> nm, found it
<mup> Bug #1880016 opened: show image last synced time  <MAAS:New> <https://launchpad.net/bugs/1880016>
<mup> Bug #1880016 changed: show image last synced time  <MAAS:New> <https://launchpad.net/bugs/1880016>
<mup> Bug #1880016 opened: show image last synced time  <MAAS:New> <https://launchpad.net/bugs/1880016>
#maas 2020-05-22
<mup> Bug #1880208 opened: MAAS 2.7.1 - "No Such Resource" after fresh install  <MAAS:New> <https://launchpad.net/bugs/1880208>
<mup> Bug #1880208 changed: MAAS 2.7.1 - "No Such Resource" after fresh install  <MAAS:New> <https://launchpad.net/bugs/1880208>
<mup> Bug #1880208 opened: MAAS 2.7.1 - "No Such Resource" after fresh install  <MAAS:New> <https://launchpad.net/bugs/1880208>
#maas 2020-05-23
<mup> Bug #1866857 changed: MAAS not finding disks - HP DL360e <MAAS:Expired> <https://launchpad.net/bugs/1866857>
<mup> Bug #1866857 opened: MAAS not finding disks - HP DL360e <MAAS:Expired> <https://launchpad.net/bugs/1866857>
<mup> Bug #1866857 changed: MAAS not finding disks - HP DL360e <MAAS:Expired> <https://launchpad.net/bugs/1866857>
#maas 2020-05-24
<mup> Bug #1880400 opened: [Feature Request] - Add "deployment scripts" to UI - Settings\Scripts \... <MAAS:New> <https://launchpad.net/bugs/1880400>
<mup> Bug #1880400 changed: [Feature Request] - Add "deployment scripts" to UI - Settings\Scripts \... <MAAS:New> <https://launchpad.net/bugs/1880400>
<mup> Bug #1880400 opened: [Feature Request] - Add "deployment scripts" to UI - Settings\Scripts \... <MAAS:New> <https://launchpad.net/bugs/1880400>
<mup> Bug #1880448 opened: [ui, feature] The UI should warn or prevent users from deploying if there is an issue with the rack controller <MAAS:New> <https://launchpad.net/bugs/1880448>
