#maas 2013-03-18
<atanasb> Hello everyone
<atanasb> I just finished installing MAAS
<atanasb> I have a problem with the configuration of my nodes
<atanasb> is this the place to ask such questions?
<atanasb> :)
<melmoth> i m having problem enlisting nodes when i m behind a proxy
<melmoth> i try to change /usr/share/maas/preseeds/generic so that i have "d-i     mirror/http/proxy string http://http://my.proxy:8000/"
<melmoth> but when i enlist a node, it s console still show temporary failure resolving archive.ubuntu.com
<melmoth> did i do something wrong ? was i suppose to restart some service ? any hint as to what i may have missed ?
<melmoth> still, the node appears as declared.
<melmoth> racedo any idea ? ^
<melmoth> still, i cannot bootstrap , i added the proxy def in the /usr/share/maas/preseeds/preseed_master file, but it does not seem to be used
<melmoth> lets try to set the proxy in enlist_userdata and re enlist the node then.
<roaksoax> melmoth: yes
<roaksoax> melmoth: enlistment doesn't use the normal preseeds, it uses enlist_userdata
<melmoth> enlisting worked, but now not the bootstraping. i m tryoing to add apt.conf manually in /var/lib/maas/ephemeral/precise/ephemeral/amd64/20121008/disk.img
<roaksoax> melmoth: it is not bootstrapping because it is not accessing the ppa:
<roaksoax> ?
<melmoth> no, i havent reach this stage yet. :)
<melmoth> that s what i want to try out, the workarond you mentionned last week
<roaksoax> melmoth: there's no need to modify disk.img when you can modify the cloud init preseeds/user data to add the proxy
<melmoth> i try, i failed
<roaksoax> melmoth: is this a customer?
<melmoth> no, its just me having nothing more urgent to play with
<roaksoax> melmoth: ok, is this a lab i could access to?
<melmoth> yep, arion on boston.
<melmoth> hold on, just trying to bootstrap after my change in the image
<roaksoax> melmoth: ok, butyou have to differentiate various things. 1. only enlisting and commissioning use the image 2. the installation process is done via normal installation (doesn';t use the image).
<melmoth> ah, then it ll failed....
<melmoth> but i did put the porxy in the /usr/share/maas/preseeds/preseed_master
<roaksoax> melmoth: preseed_master automatically uses the proxy in MAAS
<melmoth> i set apt_proxy: in /usr/share/maas/preseeds/enlist_userdata, and set the proxy in /usr/share/maas/preseeds/preseed_master
<melmoth> and in the image
<roaksoax> melmoth: you don't need to modify preseed_master: http://paste.ubuntu.com/5625566/
<roaksoax> melmoth: http://paste.ubuntu.com/5625568/
<melmoth> hmmmm, in enlist_userdata i did not put apt_proxy: http://{{server_host}}:8000/ but my proxy...
<melmoth> may be i should have just uncomment it without changing the server_hosr macro ?
<roaksoax> melmoth: {{server_host}} refers to the address of the MAAS Region Controller
<roaksoax> where the MAAS proxy is running (squid-deb-proxy)
<melmoth> ok... i ll try that out. from scratch again, just to be sure :)
<melmoth> i ll have more news by tomorrow.
<melmoth> thanks
<roaksoax> melmoth: now you might find some situations on which it cannot import the gpg key for the PPA... that needs to be resolved differently and can't remember how is it that we did it
<melmoth> that s what i want to try out this week.
<melmoth> i bet i ll ask more help about it here in the near future....
<roaksoax> indeed
<aberdine_> Hello. I'm trying to get MAAS up and running on Quantal to provision Quantal machines. I can't get the import pxe tool to download the quantal images but it doesn't by default and error if I add the config to the import-pxe config file
<roaksoax> aberdine_: modify /etc/maas/import_pxe_files
<roaksoax> aberdine_: and there would be something like #IMPORT_SQUASH_FS=0 remove the comment and try to import the images again
<roaksoax> aberdine_: if it continues to fail, set that to 1 and that should be ir
<roaksoax> be it
<aberdine_> thanks roaksoax. It was failing at the squashfs import
<aberdine_> it seems to be running now
<aberdine_> Now I've just got to figure out why it things it's install the machine went it's done nothing
<roaksoax> aberdine_: how so?
<aberdine_> I do the first PXE boot, then accept it via the web interface. Reboot and boot of net and it keeps going with the enlist process
<aberdine_> It never actually installs anything
<roaksoax> aberdine_: so there's 3 steps in maas 1. enlistment. 2. commissioning 3. deployment (which leads to installation)
<roaksoax> aberdine_: so you enlist a machine and it has a 'Declared' Status on the WebUI
<roaksoax> aberdine_: you do "Accept & Commission"
<aberdine_> yep, got that
<aberdine_> and the second one
<roaksoax> aberdine_: and it will accept the node, and it will commision
<aberdine_> It's now saying 'ready'
<roaksoax> aberdine_: ok so, how are you deploying it then?
<aberdine_> via a PXE boot
<roaksoax> aberdine_: right, but once 'Ready' you need to tell it to *deploy* via the WebUI, or via juju
<roaksoax> i'd recommend juju
<aberdine_> I don't see a deploy option
<aberdine_> I have a greyed out start
<aberdine_> I need to play with it a bit more I think
<roaksoax> aberdine_: what meesage is shown when you put the mouse on top? I think you haven't added the SSH key for the MAAS user
<roaksoax> that is deploying the system
<roaksoax> you need to specify one
<aberdine_> added the SSH key toâ¦?
<roaksoax> aberdine_: on the right corner, clic on the user
<roaksoax> then go to Settings
<roaksoax> err
<roaksoax> PReferences
<aberdine_> that needs my ssh public key in?
<roaksoax> then 'Add SSH Key', which is your public key
<aberdine_> what's that for? Post install config?
<roaksoax> aberdine_: yes it needs your public ssh key, otherwise you won;'t be able to log into the server
<aberdine_> ah :)
<aberdine_> So, I've enlisted and commissioned the machine. It's on its second boot now
<aberdine_> it has a hostname this time
<aberdine_> hmm
<aberdine_> this looks promising
<aberdine_> it's downloading stuff
<aberdine_> and shuts down
<aberdine_> and start node
<aberdine_> ahha
<aberdine_> an installer :)
<aberdine_> excellent. Thanks roaksoax
<roaksoax> cool
<aberdine_> on the road to building my own openstack cloud :)
<roaksoax> cool :)
#maas 2013-03-19
<Sargun> Who here is using Maas
<Vee_> can anyone tell me what tftp server is used in 12.10server(MAAS) ?
<bigjools> Vee_: a custom one
<bigjools> written specifically for maas
<Vee_> bigjools, where is the .conf file located ?
<bigjools> Vee_: .conf for what?
<Vee_> I have a problem booting up nodes, they are not able to get all files from the tftp server. the tftp server is up and running(tried a tftp client to download files, and some worked others did not)
<bigjools> Vee_: anything like this? https://bugs.launchpad.net/maas/+bug/1155556
<ubot5> Launchpad bug 1155556 in MAAS "HP ProLiant DL380 G7 tftps kernel, but initrd tracebacks in tftp server. DL380 G6 succeeds." [High,Triaged]
<Vee_> bigjools, No, my nodes cant seem to find pxelinux.cfg/default or MAC_ADDRESS and these two files exist under /var/lib/maas/tftp/pxelinux.cfg but i can manially download kernel and initrd with a tftp client
<Vee_> bigjools, all files under tftp folder has the same owner/group
<bigjools> some stuff is auto generated based on what state maas thinks the file is in
<bigjools> s/file/node/
<Vee_> bigjools, do you know where i can read up on how maas generates these files ?, i cant seem to find much real info on the MAAS project
<bigjools> maas.ubuntu.com
<Vee_> bigjools, ive read thoose pages, but i would really apreciate more in-depth docs. What do you mean by s/ ?
<bigjools> I said "file" but meant "node"
<bigjools> all the most recent docs are on that site
<bigjools> we don;t have developer docs as such
<bigjools> if it doesn;t work you need to file a bug
<Vee_> bigjools, do u know if i can disable the MAAS tftp and setup tftpd-hpa for axample to try and find where it fails cause im using a cisco router for dhcp, and i dont know where the fault is
<bigjools> Vee_: no, you cannot do that
<Vee_> bigjools, okey. Thank you for your help in this matter.
<bigjools> Vee_: sorry I can't help more - it does sound like a bug
<Vee_> bigjools, it might be, but im kinda new at this so i dont want to file a bug, until i know that i havent messed anything up ;-)
<bigjools> Vee_: It's better that you file a bug and we resolve it - it's a good place to have a wider discussion as more people will see it
 * bigjools afk for 30m
<Vee_> bigjools, i will continue to troubleshoot, but if i cant solve it in an hour i will file a bug report. thx
<melmoth> still trying to use maas behind a proxy. Still failing. This time i just commented out "apt_proxy: http://{{server_host}}:8000/" in /usr/share/maas/preseeds/enlist_userdata
<melmoth> when i juju bootstrap, the node (wich was in ready state) installation fail with:
<melmoth> wget -q http://archive.ubuntu.com/ubuntu/dists/precise/Release -O - | grep -E '^(Suite|Codename):'
<melmoth> mirror does ot support the specified release (precise)
<melmoth> i did not see a dns request coming from the node for archive.ubuntu.com, so i guess it s trying to use the proxy all right
<druiid> Howdy. Anybody around to answer a question (probably more a question for devs)?
<druiid> Anybody around?
<Catbuntu> Hi
<druiid> Guess I'll try one last time before turning to mailing-list. Any devs around?
#maas 2013-03-20
<Sargun> Does MaaS reprovision nodeds when I redeploy packages? Additionally is it rack away?
<Sargun> *aware?
<bigjools> if you are using juju it deploys a new machine on demand
<Vee_> hi! can someone please help me with the environments.yaml file? if i am using a maas cluster, what needs to be inserted into the file?
<jgm90> hello
<jgm90> i have this message
<jgm90> The region controller does not know whether any boot images have been imported yet. If this message does not disappear in 5 minutes, there may be a communication problem between the region worker process and the region controller. Check the region worker's logs for signs that it was unable to report to the MAAS API.
<jgm90> and not disapear
<Vee_> i am stuck, can someone please help me ? I need to get past juju bootstrap: 229 INFO Bootstrapping environment 'maas' (origin: distro type: maas)...
<Vee_> 2013-03-20 ,880 ERROR No matching node is available.
<melmoth> Vee_, do you have at least one node in ready state in the list of nodes ?
<Vee_> they've all booted properly and ive set maas to accept all, but they are all in state commissioning
<Vee_> melmoth, they've all booted properly and ive set maas to accept all, but they are all in state commissioning
<melmoth> you need at least one ready to bootstrap
<Vee_> melmoth, how do i achieve that ?
<melmoth> from my experience, once i edited a node and "accept and ocmission" it, it has to reboot
<melmoth> then, it install some stuff, makes some test, end up in ready state and is powered off again.
<Vee_> okey, mine just shutdown after enlisting itself. Maybe my problem is the pxe/ipmi bootup then
<melmoth> that s normal i think. It just needs to be rebooted once you have comissionned it.
<melmoth> wich i think should be done via ipmi, but on my lab i only use vm, no ipmi, i just powered boxes on and off manually
<Vee_> melmoth, so you think that if i go and push the power butttons on the nodes they will change state to ready efter some time?
<melmoth> i hope so.
<Vee_> melmoth, i am trying it now
<Vee_> melmoth, THANK U, Sometimes the easier solution the more hair u tare
<Vee_> melmoth, Thats it now it works to bootstrap
<melmoth> good
<Vee_> melmoth, U Saved my day!!! THX
<jlondon> Howdy. Any devs around?
<AskUbuntu> Different partition layouts per group/tag | http://askubuntu.com/q/270475
<roaksoax> jlondon: ask your question, and if someone knows the answer they will be able to help you
<jlondon> Is there the ability to specify per tag/group preseed files?
<jlondon> Need to have different partitions and it appears that I'd have to have some if-else type statements to do it currently (if even that is possible).
<roaksoax> jlondon: i can't remember whether you can use tags in the preseed templating
<roaksoax> but if you add tags, and test that in the preseed templating you could do it
<jlondon> Hmm. K. Any idea on what the variable names available to the template would be? Would it be node.tag?
#maas 2013-03-21
<melmoth> I'm trying to use maas (1.2+bzr1360+dfsg-0ubuntu1~ppa1 ) behind a proxy
<melmoth> I enabled  "apt_proxy: http://{{server_host}}:8000/" in /usr/share/maas/preseeds/enlist_userdata , and was able to enlist and commission a node.
<melmoth> Then i try to bootstrap, the node starts, but the installation fail:
<melmoth> wget -q http://archive.ubuntu.com/ubuntu/dists/precise/Release -O - | grep -E '^(Suite|Codename):'
<melmoth> mirror does ot support the specified release (precise)
<melmoth> any idea what i may have missed ?
<melmoth> from a tcpdump i can see the zookeeper downloading the installer, the preseed file (with the proxy set in it)
<melmoth> but then, it fail. and the funny thing is, i do not see any trace of a wget to archive.ubuntu.com
<melmoth> nor a name resolution attempt.
<melmoth> no idea exactly where to look at.
<melmoth> hmmm, on the preseed file the proxy is syppose to be the maas node on port 8000
<melmoth> but there s nothing listening on port 8000 on my maas box
<melmoth> hmm, squid deb proxy was not started....
<melmoth> still, same behaviour
<roaksoax> melmoth: checkl if squid-deb-proxy is actually running
<roaksoax> but that's it
<roaksoax> proxy refers to the region controller
<roaksoax> and it does work
<roaksoax> tail -f /var/log/squid-deb-proxy/access.log
<melmoth> roaksoax, the problem was due to the fact that the maas box itself is behind a proxy.
<melmoth> when zookeeper asked maas's proxy for http://archive.ubuntu.com/ubuntu/dists/precise/Relase, it was not able to get the page.
<melmoth> at least it had a problem with the lab's proxy itself.
<roaksoax> that';yeah
<roaksoax> yeah
<melmoth> next thing i try is to put the lab proxy for apt_proxy: in the enlist_userdata file.
<melmoth> and see what happens.
<newellista> Just install MAAS on Ubuntu 12.10 in a VirtualBox VM.  Trying to hit the web portal, and I get a 500 error.  /var/log/apache2/error.log shows some python errors.  Suggestions?
#maas 2013-03-22
<AskUbuntu> openstack-dashboard login | http://askubuntu.com/q/271382
#maas 2013-03-23
<AskUbuntu> MAAS 12.10 import-pxe-files fails | http://askubuntu.com/q/271607
#maas 2013-03-24
<sinapsis> There is any way of re-provisioning a server
<sinapsis> without deleting the node?
#maas 2014-03-17
<jtv> bigjools: we were talking though about why the sm15k code _was written_ as a celery task...  I don't see any other way to make such requests of the pserv _prior to the sprint_.
<bigjools> jtv: oh yes, that is the case
<bigjools> jtv: just saying that we can get rid of the task and make this async
<jtv> Gotcha.
<bigjools> then the design moves towards the vision
<smoser> rvba, can you tell me how to set the global kernel opts via cmdline ?
<rvba> smoser: sure, just one secâ¦
<rvba> smoser: the name of the config option is 'kernel_opts':  maas <maasnamee> maas set-config name=kernel_opts value='my kern opts'
<smoser> thanks rvba
<smoser> rvba, how do i set "use-fastpath-installer" globally ?
<smoser> i thought it was this:
<smoser> $ maas maaslocal tag update use-fastpath-installer definition="true()"
<smoser> Not Found
<smoser> never mind. have to create it first
<rvba> I was about to say that :)
<rvba> smoser: maas maaslocal tags new name=use-fastpath-installer definition="true()"
<smoser> https://bugs.launchpad.net/maas/+bug/1293661
<ubot5> Ubuntu bug 1293661 in MAAS "cannot use fast path installer to deploy other than trusty" [Undecided,New]
<smoser> that seems significant
<tych0> smoser: it should work, right?
<tych0> just that the precise images (or whatever release) don't get synced by default?
<smoser> yeah. that would make it work.
<tych0> i see, ok
<smoser> it seems to me that the value maas gets for 'ip' in the ipmi_template is completely bogus
<smoser> opened bug https://bugs.launchpad.net/maas/+bug/1293791
<ubot5> Ubuntu bug 1293791 in MAAS "ipmi template tries to apply ipmi to *hosts* address rather than ipmi address" [Undecided,New]
<tych0> smoser: ah, that might actually be my fault
<tych0> smoser: is ip_address part of the template?
<tych0> oh, no
<tych0> i don't have any idea what that is doing
#maas 2014-03-18
<bigjools> jtv: in src/maasserver/tests/test_api_node.py I am wondering if the tests that do things like start() are creating real celery teasks
<jtv> bigjools: I recall seeing task code running (from tracebacks, unrelated) when the node/nodes API tests did things like accept a node.
<jtv> Oh, and I think one thing that happened was:
<jtv> Some tests get run in scenarios for different kinds of user (regular vs. admin, sometimes I think anon as well).
<jtv> Something I hate, by the way.
<jtv> Anyway, when the admin tests enlist a node through the API...
<jtv> ...they are of course auto-accepted...
<jtv> ...which of course sends them straight into commissioning...
<jtv> ...including a power action to start them.
<bigjools> yeah so the power action is what I am getting at
<bigjools> jtv: so we have a celery fixture as self.celery in the maasserver tests, right?
<bigjools> I don't know whether it goes as far as issuing actual tasks
<jtv> Yes â it slows down the tests a little bit, but many tests seem to rely on it.
<jtv> Does the celery fixture actually stop celery tasks though?  Or does it ensure their delivery, just without a transport?
<jtv> Looking at the docstring, I infer the latter.
<bigjools> ok right it does them sync
<bigjools> aaaiieeeeeeeee
<bigjools> fuck
<jtv> Ay caramba
<jtv> Â¡Aiaiay!
<bigjools> Â¡Merda!
<jtv> Meanwhile, Blake's branch has failed to land 3 times â twice because of that weird expected-to-be-called-once test bug, once because of a new one.
<bigjools> sheesh
<jtv> It's mierda, with an âiâ
<jtv> By ânew one,â I don't necessarily mean one he introduced... looks like another one that was already lurking in the code.
<bigjools> yeah
<bigjools> that one is very rare
<bigjools> I suspect all of this is a consequence of those celery tasks we just talked about
<jtv> Ahhh, it's an ExternalProcessError from rndc â but with a traceback this time.  So arguably this is progress.
<bigjools> eek not updated my trusty machine in a week and..... about a million packages to get
<jtv> Yup.
<jtv> But if you had other machines updating in the background, many of them will be in cache already.
<bigjools> on the bright side the coffee I just made is excellent
<bigjools> no, I had not updated any of my machines so the cache was very cold
<bigjools> unlike this coffee, which is hawt
<jtv> Then your machines get to enjoy full cache re-use.
<bigjools> and all I am trying to do is get tycho's branch tested before I approve it
<jtv> The rndc error looks like a port-is-in-use.  :/
<bigjools> good old isolation errors!
<jtv> The real hello-old-friend here is a traceback going through a save() into a signal handler and from there into a celery task which then dives deeper into a callback chain.
<jtv> In this case though, it's all intentional.
<bigjools> we need to limit these types of tests to a separate set of tests that are obviously integration tests and work hard to keep the integration/unit split
<jtv> I see it as mostly a practices issue.  To me, âintegration testâ is a relative term â the test still generally isolates some part of the application.
<jtv> Just a bigger part than a unit test.
<bigjools> jtv: well what I mean is, let's make the celery fixture do nothing by default
<jtv> Absolutely, yes!
<bigjools> and make the tests that need it explicitly turn it on
<jtv> But I'm warning you: it'll affect loadsatests.
<bigjools> it will be painful to fix but better
<jtv> Yup.
<bigjools> it's tech debt
<bigjools> sad but true
<bigjools> damn I need an intern :)
<jtv> I know it's been a hard day, Mr. President, but don't you want to wait until Hilary is out of the running?
<jtv> I also wish we could just roll up our sleeves and replace all signals with explicit calls.  But the very essence of the problem is that those calls are spread out and implicit.
<bigjools> and there's no other way sometimes I think?
<jtv> There are other things we could do: disable the signals by default during testing, or issue warnings and act later, or just live with the problem.
<bigjools> yeah, I'd like signals disabled too.
<bigjools> all of this stuff a) slows down tests, b) causes spurious side effects
<jtv> And let's not forget: c) makes it harder to reason about what goes on
<jtv> âjust mentioning that because we are seeing cryptic test failures from time to time.
<bigjools> jtv: well yes that's b) really
<bigjools> rvba: what part of oleg's stuff cannot be landed in parallel to the existing import?
<bigjools> I don't understand why
<rvba> bigjools: have a look at https://code.launchpad.net/~strikov/maas/maas-new-metadata-format/+merge/210843 The changes to src/provisioningserver/pxe/config.py will break the package until the new script is used.
<rvba> bigjools: same for the changes to src/provisioningserver/kernel_opts.py (we can probably improve what has been done here a bit btw)
<bigjools> rvba: stuff like this seems grossly unnecessary:
<bigjools> 501	-    root = String(if_missing="/var/lib/maas/tftp")
<bigjools> 502	+    root = String(if_missing="/var/lib/maas/boot-resources/current/")
<rvba> bigjools: I agree, but that's not what I'm talking about
<rvba> bigjools: that's precisely why I didn't want to land the whole branch but just the raw script: so that we can improve things the way was want.
<rvba> s/was/we/
<gmb> G'moaning.
<jtv> Hi gmb
<rvba> Hello gmb
<bigjools> rvba: ok so the whole structure/naming of the images is different now?
<bigjools> greetings gmb
<rvba> bigjools: we need to investigate that.  The only thing that seems to have changed in this regard is get_ephemeral_name().
<bigjools> rvba: well I am referring to the stuff in pxe/config/py
<bigjools> config.py
<bigjools> di-<thing> and boot-<thing>
<bigjools> instead of initrd and linux
<rvba> Yeah, the name of the files clearly has changed.
<rvba> The structure, I'm not sure.
<bigjools> I don't know why they changed
<bigjools> and the change in src/provisioningserver/pxe/tftppath.py is quite perplexing
<rvba> I think the two changes are linked.
<rvba> di-* is for install
<rvba> boot-* is for commissioning
<bigjools> yes
<bigjools> cutting it as fine as ever with this stuff :/
<jtv> Yay!  Image migration, image import, commissioning, fast-path install, and classic install all work with the labels.
<jtv> It even works with Trusty, because the import script doesn't actually report the images as non-"release" yet.
<jtv> rvba: question about the new import-script integration branch...
<jtv> How do the changes in the armhf templates work?
<jtv> Do they just override a parameter to the template?
<jtv> And if so, does this mean that we stop supporting the highbank subarch name?
<jtv> Do we no longer need to support it because the simplestreams data gives us generic?
<jtv> I'm asking because the overridden variable is for _newer_ releases than Raring, not older ones.
<rvba> jtv: I'm told the new data will explicitly include subarches=['highbank', 'generic'] for the 'generic' boot resources.
<jtv> Ah that explains.  Thanks.
<rvba> jtv: I'd like to see it for myself but we have to wait for the metadata to be publishedâ¦
<jtv> Yeah.  It's a bit like boring an undersea tunnel and having to trust that you're going to meet up with the people working from the other end.
<jtv> gmb: if you hadn't said anything about the "release" fallback, I wouldn't have worried about it.  But if it's not something that should happen in real life, I'd prefer not to return a sane label to an insane world.
<gmb> jtv: Yeah, that's my feeling too. I'll fix the world.
<gmb> (A bit)
<jtv> Nah, let the world stew in its own venom.  Just don't give it a label that will look (when debugging) as if there has to be an image.
<jtv> In fact, I wonder if it might be worth returning something recognisable as a hint...
<gmb> jtv: Hmm... 'invalid-label' seems a good start. Either that or "FOAD". Maybe that's too subtle.
<jtv> Insert joke at the expense of your favourite group here.
<jtv> But "invalid label" is the outcome of something more profound: no image!
<jtv> That, I should think, is what the user needs to know.
<jtv> Question is, is that best expressed on the node's console or in the server logs?
<gmb> Clarity clarity clarity.
<jtv> I'm not sure what you mean.  Could you explain?
<jtv> <deadpan>
<gmb> ROFLYSST.
<jtv> "at your silly statement"..?
<gmb> Rolling on Floor Laughing, Yet Somehow Still Typing.
<jtv> Ah!
<jtv> Useful one.  Thanks.
<gmb> (It's a Billy Bailey-ism)
<gmb> Bill*
<gmb> ANYROAD
<gmb> jtv: I think it should probably go in the server's logs; I don't know how often people look at the node's console whilst it's booting (especially in large-scale deployments). That said, there's no harm in putting it in both.
<jtv> Fair enough...  Then I'd say pxeconfig should just raise an exception in this situation, so that both it and the cluster controller are in a position to log it.
<gmb> jtv: Right.
<jtv> And if the cluster controller wants, it can convey problems to the node's console through silly results, but...
<jtv> ...see your point above.
<gmb> Indeed.
<gmb> On it.
<jtv> And while you're there, can I just put in a good word for simple conditionals?
<jtv> "if latest_image is not None" with an "else" makes for increased likelihood of future mistakes.
<jtv> There are two schools of thoughts about this â "most normal condition first" and "avoid unnecessary negation."
<gmb> jtv: Yeah... In this case the latter seems the right path.
<gmb> And an early escape from insanity.
<gmb> ("There's no latest image; fuck it, raise an exception.")
<jtv> Huzzah.  Labels have landed.
<rvba> jtv: \o/.  Please update the integration branch.
<jtv> Will do.
<rvba> Ta.
<jtv> Blake's branch failed to land (in this latest attempt) because an architecture in the registry has its pxealiases field set to None.  Does anyone know why that might be?
<jtv> Hmm... looks like ArchitectureRegistry expects that field to be iterable, and yet it defaults to None.
<jtv> Why isn't that breaking other branches?
<jtv> Uh-oh.  That's dependent on coincidental dict ordering, isn't it?
<rvba> jtv: is it?  I'd say get_by_pxealias() is simply broken.
<jtv> Yes, but in a way that will pass tests sometimes.
<jtv> Depends on the ordering of the dict iteration in get_by_pxealias().
<jtv> This is what happens when we skimp on negative tests.
<rvba> pxealiases should probably be an empty tuple by default.  Instead of None.
<jtv> Either will do.
<jtv> Just not this.  :)
<jtv> I'm fixing it.
<rvba> jtv: the more I look into moving the config for the new import script into a new file, the more I think it's a rabbit holeâ¦ because of the presence of the boot/ephemeral/images_directory config.
<rvba> It's used heavily in the provisioning server itself.
<rvba> Yes, we could probably have that stored on the BootImages objects.
<rvba> But it's a lot of work for very little gain.
<rvba> jtv: what do you think?
<jtv> Let me just finish what I'm doing here...
<jtv> BRB
<gmb> jtv: So, doing what we wanted with the exception from pxeconfig() is causing a raft of test failures that are proving *very* hard to fix. I'm going to grab some lunch then take one last stab at it. If that doesn't work I'll fall back to returning an obviously-wrong label for the time being and file a bug.
 * gmb lunches 
<gmb> \
<jtv> gmb: well at least that would give it a good _reason_, which is also good.  :)
<gmb> jtv: Can you give https://code.launchpad.net/~gmb/maas/label-in-pxe-config/+merge/211480 a thumbs up so we can land it?
<jtv> Looking
<jtv> gmb: approved with comments.
<gmb> jtv: You have given voice the the inner monologue that I had when I wrote the test... I got distracted by the no-such-image nonsense.
<gmb> *sigh*
<gmb> Always listen to yourself.
<gmb> Unless you tell yourself to kill people.
<jtv> Glad to hear you were thinking along the same lines.
<jtv> Otherwise I might have come across as a bit of a pain in the neck.
<gmb> jtv: I find that writing code is like sculpture.
<gmb> You just remove all the bits that don't look like a horse.
<gmb> Except by committee.
<gmb> So sometimes you get a camel.
<jtv> There is of course one glaring and fatal flaw in your reasoning.
<jtv> Why would we need code to look like a horse?\
<gmb> YOU ARE NO FUN
 * gmb wants a pony
<Jeffrey> I have about 8 blade servers that I am in the process of getting MaaS to work with. I have all the blades enlisted with the MaaS Controller, and it boots into pxe boot and boots the image. But after installing the image it says "boot sector signature not found" and then drops me to a boot prompt. Can anyone help me troubleshoot this?
#maas 2014-03-19
<bigjools> jtv: quick pre-imp?
<rvba> jtv: gmb: The following (taken from the most recent failure in the test lab) looks like a fallout from the recent 'label' work: http://paste.ubuntu.com/7118396/
<gmb> rvba: Damn.
<gmb> rvba: I need to step out for a little while right now but I'll glom onto this as soon as I get back. Best to email it to jtv too as he knows more about the label stuff than I.
<rvba> gmb: okay.  I'll have a look now;  let's talk about it when you're back.
<gmb> rvba: Cool, thanks.
 * gmb -> back in a wee while
<rvba> gmb: Could you please have a look at: https://code.launchpad.net/~rvb/maas/bug-import-eph-crash/+merge/211673
<bigjools> rvba: TypeError: install_image_from_simplestreams() takes at least 4 arguments (4 given)
<bigjools> lol?
<bigjools> :)
<bigjools> rvba: want me to review that?
<rvba> bigjools: sure
<rvba> bigjools: that's if you rather do that than talk to me :)
<bigjools> rvba: ok let's try and see if 3g holds up
<bigjools> I'll call you
 * gmb returns
<gmb> Thanks for fixing that rvba. Sorry I had to be afk for the duration.
 * gmb didn't time it that way. Promise.
<rvba> gmb: no worries
<rvba> gmb: building a package with the latest trunk now
<gmb> rvba: Is there any card from the new import script work that you'd like me to pick up in particular, or should I just grab something at random?
<bigjools> rvba: did my change fix ipmi in the lab?
<rvba> bigjools: I was precisely in the process of testing this when I came across bug 1294516.
<ubot5> bug 1294516 in MAAS "maas-import-ephemerals crashes" [Critical,Fix committed] https://launchpad.net/bugs/1294516
<rvba> bigjools: now that it's fixed, I'm testing the package again.
<bigjools> rvba: cool.  One more thing, unrelated, but when there's no boot images the architecture drop down is empty and there's no message saying why
<bigjools> remember the work we did for the power types?
<bigjools> that is missing in the arch dropdown
<bigjools> I added a card as this is a little more serious
<bigjools> as it will trap many people
<bigjools> I have to travel now, I will be late for the call later
<rvba> Okay.
<bigjools> probably at the top of the hour instead
<bigjools> hope you don;t mind waiting for me
<bigjools> :)
<rvba> :)
<rvba> bigjools: the int. tests passed with the new package.  Starting a new test run just for safetyâ¦
<bigjools> \o/
<jtv> Why is "maas-region-admin dbshell" broken again?  I thought I'd fixed that.
<bigjools> jtv: yeah me too, I saw that earlier :/
<rvba> bigjools: Second run is not over yet but it's passed the point where it failed before.  I think we can consider the bug fixed.
<rvba> gmb: I'm going to work on the boot images stuffâ¦ so you're can grab the "Architecture drop-down empty and no message why (see description)" task if you want :)
<gmb> rvba: WFM.
<jtv> bigjools: Ahh, it's the --installed option.
<bigjools> jtv: whaaaa?
<jtv> bigjools: run dbshell with the --installed option.
<jtv> We still need a user-friendly error, don't we?
<rvba> Do you guys think it makes sense to deal with boot images in the API globally on only on a cluster per cluster basis?
<rvba> I mean, is it useful to have a way to list all the boot images?  Or do we want the API to operate on a nodegroup object?
<rvba> In one case, listing bootimages is done with /api/boot-images/op=list
<rvba> In the other case, it's /api/nodegroups/<ng_uuid>/boot-images/op=list
<jtv> Think in batches.
<jtv> I'd just make nodegroup a constraint on a global nodegroups listing.
<jtv> Although... this isn't very scale-sensitive.
<jtv> Never mind me.
<rvba> Not really sure which option is best.
<rvba> Nodes objects are defined "globally" (although they are related to nodegroups) because it was important to be able to manage them as a set.
<jtv> In terms of the functionality we have in mind, having a separate list per nodegroup seems the most appropriate.
<rvba> Interfaces are defined on nodegroups.
<jtv> I think it all depends on how likely we are to need a cross-nodegroup listing.
<jtv> For the uses we have, we plan to move away from that.
<rvba> Yeah, defining this globally only gives us that: a cross-nodegroup listing.
<rvba> Or rather "gives us only that"
<jtv> If we need it in rare cases, I don't think we need to worry about a client having a few extra round trips to make.
<jtv> Either "only" is correct.
<rvba> All right, I'll define this only the clusters objects.  It's definitely a bit cleaner to do it this way.
<zchander> HI, is anyone familiar with preseed settings for MaaS? I want to partition a disk while commissioning
<perrito666> hello fine people, is anyone available to review a maas related juju-core change? https://codereview.appspot.com/77850043 there are a couple of lines with doubts and you might have the answer
<mgz> rvba: ^ pls :)
<rvba> perrito666: sure, I'll have a look in a sec.
<perrito666> rvba: thank a lot
<perrito666> *thanks
<rvba> perrito666: I think I replied to your question, see the MP.
<perrito666> rvba: thank you,checking
 * gmb -> afk for a while
<perrito666> rvba: your changes got applied, thanks for the input
<rvba> np
<tych0> hi rvba, is there a way to add and remove tags via the UI?
<rvba> tych0: no, you have to use the API/CLI.
<tych0> ok, cool
#maas 2014-03-20
<bigjools> roaksoax: can you bless this please? https://code.launchpad.net/~julian-edwards/maas/packaging/+merge/211668
<rvba> bigjools: is there something fundamentally wrong with https://code.launchpad.net/~rvb/maas/bootimage-ui/+merge/211761 or did you just forget to mark it 'Approved'?
<jtv> Where did Oleg add his comments?  I don't see them in the new-import-script-integration branch.
<jtv> Oh, wait
<rvba> jtv: https://code.launchpad.net/~strikov/maas/maas-new-metadata-format/+merge/210843
<jtv> trunk now, right?
<jtv> Thanks.
<jtv> Do we have parallel branches now?
<jtv> I've been working off the new-*-integration one.
<rvba> jtv: yeah, we need to integrate Oleg
<rvba> 's work
<jtv> Should we start by just making all of it live in trunk, even if not active yet?
<jtv> Keep the old and the new entries in pserv.yaml, etc.
<jtv> Or will it be too hard?
<rvba> jtv: I think it's doable.
<rvba> And probably the best option to avoid the big bang approach.
<jtv> Yeah.  It'll still be one functionally, but at least we won't be messing around with conflicting branches.
<jtv> I went through a weird jet-lag phase earlier today, and I was just constantly wondering what was where.  Scary!
<jtv> Trunk is nice and safe.  :)
<bigjools> rvba: I forgot, sorry.
<rvba> no worries
<bigjools> rvba, jtv: I'd like to get oleg using the integration branch
<bigjools> however I emailed him earlier and said we'd just take over the work
<jtv> Then we should figure out how to get his latest work into either maas or the integration branch, and the integration branch into trunk.
<bigjools> unless we changed any of the same code that is in trunk, we can just get rid of the one in trunk
<bigjools> did anything change in the integration branch?
<jtv> Not yesterday or today.
<jtv> I've been pulling it and not seeing changes.
<jtv> Nothing since Tue 2014-03-18 10:53:34 +0100
<bigjools> ok
<jtv> rvba: I'm trying to run the import script from the integration branch, against source http://maas.ubuntu.com/images/ephemeral-v2/daily/ â but it just fails because the snapshot directory is never created.  Do you get the same?
<rvba> jtv: I didn't try using maas.ubuntu.com yet.
<bigjools> I am about to try
<rvba> I've always used the fake data thus far.
<rvba> jtv: I'll try now.
<jtv> FWIW I got the same with the test repos, so I expect it's something I'm doing wrong.
<rvba> jtv: bigjools: I've integrated Oleg's most recent fixes to the import script in our integration branch.
<bigjools> awesome
<jtv> Great, thanks.  I'll re-merge.
<bigjools> let's get him using it as well
<bigjools> meanwhile, my "make install-dependencies" is still going 20 minutes later on this lcy02 instance
<rvba> Yeah, canonistack is a mess these days.
<rvba> Machines on lcy02 and lcy01 are slow as hell.
<bigjools> popular I guess
<rvba> (All the bootimages stuff is landed, I need to QA it but it should be quick)
<bigjools> maas seems to have about 6 million dependencies
<rvba> jtv: when I merge trunk into the integration branch I get a conflict related to the 'label' work.. could you have a look?  You can probably fix this quicker than me.
<jtv> Sure
<rvba> Ta
<jtv> I don't know about the armhf template though.
<rvba> We can take Oleg's version, 'highbank' is now explicitly supported by the 'generic' kernel.
<rvba>    "version": "14.04",
<bigjools> what/where do you configure the new source in the pserv.yaml?
<rvba>    "subarches": "generic,highbank,hwe-p,hwe-q,hwe-r,hwe-s,hwe-t",
<rvba>    "release": "trusty",
<rvba>    "arch": "armhf"
<rvba> bigjools: not sure what you meanâ¦?
<jtv> Comma-separated string?  Not a list?
<bigjools> rvba: the new simplestreams source, where do I configure it in oleg's changes?
<jtv> etc/maas/pserv.yaml
<rvba> bigjools: http://paste.ubuntu.com/7124389/
<rvba> See the top of the diff in https://code.launchpad.net/~maas-maintainers/maas/new-import-script-integration/+merge/211470
<bigjools> guys, I can see that much, but where in that config!
<rvba> The path.
<rvba> Sorry, I don't think I understand your question.
<jtv> Going to be hard to resolve that conflict when tests don't pass in the existing branch...
<rvba> jtv: yeah, I know :/
<jtv> If tests don't pass anyway, just go with the trunk version...
<jtv> The armhf template conflict is just two identical changes conflicting.  I thought they'd made bzr accept that without complaining.
<bigjools> formatting difference?
<bigjools> trailing spaces?
<jtv> No.
<jtv> I ran a diff.
<bigjools> :(
<bigjools> well I tried to run the new script and got this
<bigjools> IOError: [Errno 2] No such file or directory: u'/var/lib/maas/boot-resources//snapshot-20032014-094738//maas.meta'
<jtv> Same for me.
<jtv> That's the snapshot directory I mentioned earlier.
<jtv> It looks as if simplestreams is supposed to create it implicitly while synchronising.
<jtv> By the way, note the 20032014... yes that _is_ a date but it's little-endian.
<rvba> Hi strikov!
<strikov> rvba: Hey :)
<rvba> strikov: that's the integration branch: lp:~maas-maintainers/maas/new-import-script-integration
<gmb> bigjools: To confirm: when you had your empty drop down problem, what fixed it? Re-running import-(eph|pxe)?
<bigjools> gmb: in my case it was putting the tftp images back in the right place
<gmb> bigjools: But wouldn't running the script again had the same effecT?
<gmb> (I'm asking because the error should give some instruction as to how to get out of the problem state)
<bigjools> gmb: yes, but not in my case as I had a screwy package
<gmb> Well, we don't care about that. :)
<gmb> Okay, cool.
<bigjools> yes, the instruction should be the same as the bug warning banner about missing boot images
<bigjools> big*
<gmb> Right. That's what I'm going to steal :)
<bigjools> gmb: parfait
<allenap> Grr.
<rvba> allenap: \o/
<rvba> ;)
<bigjools> wb allenap
<allenap> Donât talk to me.
<allenap> ;)
<bigjools> so gmb, allenap, rvba, jtv: I shall make sure kanban cards are complete for the list on that doc
<bigjools> and then please feel free to start taking them
<bigjools> allenap: here's a good reason to start with a new config file, we need to write into it some config based on the current bootimages
<bigjools> does the yaml writer maintain comments?
<allenap> bigjools: Nope, it doesnât.
<bigjools> uh huh
<allenap> Afaik.
<bigjools> :)
<allenap> bigjools: However, you can just append to the yaml file and itâll dtrt.
<bigjools> allenap: true!
<allenap> When it comes to in-place updates to config files, thereâs nothing really compelling out there. Configobj is the closest Iâve seen, but thatâs kind of baroque.
<jtv> Do we need to store this in a config file at all?
 * allenap canât remember exactly what weâre storing.
<jtv> Parameters for the imports: arches, releases, source URLs.
<jtv> Now, the source URLs we need to have somewhere.
<lifeless> configObj is what bzr used
<jtv> But the rest I guess could be generated from a form.
<rvba> allenap: http://paste.ubuntu.com/7124600/
<jtv> Hi lifeless
<jtv> What I had in mind originally was: import link goes to a form page, where you can enter the releases and architectures you want, and _that_ gets pre-populated based on existing boot images.
<jtv> Oh, that doesn't work with multiple simplestreams sources does it?
<rvba> This is all the test failures we've got on the integration branch http://paste.ubuntu.com/7124602/
<jtv> I would suggest people start fixing in small branches...
<bigjools> wotcha lifeless
<rvba> bigjools: can you land your packaging branch?  I can't QA my changes right now because of the new dependency.
<bigjools> rvba: yes!
<rvba> jtv: yes, the failures can be easily divided into "topics"
<rvba> bigjools: ta
<jtv> rvba: so you never had that error where the snapshot directory did not exist?
<rvba> jtv: no
<jtv> And you used that config you pasted to Julian earlier?
<rvba> jtv: no, I was using the test data so that path was different.
<jtv> What path?
<jtv> Oh, the URL?\
<jtv> What did you use?  The path to the repo1 (or repo2) directory?
<rvba> Yeah, the URL.  Named 'path' in the config.
<jtv> file:// URL?
<allenap> lifeless: Ah, interesting, that makes me want to look again.
<rvba> Yes.
<jtv> That didn't work for me either.  Maybe it was the various problems in pserv.yaml...
<jtv> Because I noticed that you passed a comma-separated list for subarches, not a list like in the integration branch.
<jtv> Ugh.  When I try it against the simplestreams-v2 daily URL, it breaks because it looks for an sjson index.
<jtv> Which isn't there.
<bigjools> rvba: I can help fix tests
<bigjools> let me just get the int  branch
<jtv> strikov: do you know if, for manual testing, we can make the import script use index.json (as opposed to index.sjson) and skip any attempt at verifying signatures?
<rvba> bigjools: cool, the card contains a link with all the test failures.
<rvba> bigjools: I'm fixing the kernel opts-related failures now.
<strikov> jtv: its better to put signatures in place, i think
<strikov> jtv: let me tell how in a moment
<strikov> *tell you how
<bigjools> ta
<jtv> strikov: thanks.  It's better with signatures of course, but right now, there aren't any and we do need try out some manual runs.
<allenap> lifeless: While youâre there, would you be interested in something like https://code.launchpad.net/~allenap/maas/run-isolated-with-debugging/+merge/211803 in upstream subunit?
<rvba> https://code.launchpad.net/~rvb/maas/integ-fix-tests/+merge/211903
<strikov> jtv: bzr branch lp:simplestreams simplestreams
<strikov> cd simplestreams
<strikov> make gnupg
<strikov> ./tools/tenv js2signed /home/ubuntu/boot-resources-v2/
<strikov> jtv: that will sign your metadata with simplestream's default key which is in ./gpg/ folder
<jtv> strikov: not what I needed!
<strikov> jtv: then you can add this key to your keyring and all the checks will pass
<jtv> But I'm trying to import a stream that doesn't have any signatures at all.
<strikov> jtv: js2signed will add all the signatures automatically (create sjson from json)
<jtv> Oh, it inserts that on my end somehow?
<jtv> Instead of on the stream I'm trying to import from?
<strikov> jtv: which meta do you use? self-generated?
<jtv> No, Scott's online URL.
<jtv> http://maas.ubuntu.com/images/ephemeral-v2/daily/streams/v1/
<strikov> jtv: Ah. Try mine: http://162.213.35.97/boot-resources-v2/
<strikov> jtv: it's basically the same but with signatures
<strikov> jtv: you need to integrate simplestreams key though
<jtv> Thanks.  That will give me an exact mirror of Scott's otherwise?
<bigjools> rvba: can you talk me through that MP
<strikov> jtv: let me see if scott made any changes yesterday
<jtv> Thanks.
<jtv> AIUI labels were added.
<rvba> bigjools: this is to account for this http://paste.ubuntu.com/7124669/
<bigjools> rvba: I guess that's pretty simplified!
<rvba> Yeah, we don't need to patch things up anymore.
<strikov> jtv: well, he did (and that's good), we indeed need to disable sign check then
<bigjools> rvba: but this means we only keep the most recent locally?
<rvba> Yes.  That's what the import script does.
<jtv> strikov: yeah... for this kind of thing I really want to be close to the source, so we don't get everything jusssst right â for an obsolete version.
<rvba> Also, the 'info' file is now completely gone.
<jtv> rvba: get_ephemeral_name also gets a label, of course, in the branch I'm working on.
<rvba> Right.
<strikov> jtv: to disable sign check we need to (1) change index.sjson to index.json inside script and (2) implement stub policy handler for simplestreams
<strikov> jtv: does it work for you?
<jtv> strikov: sure, it's only for a temporary hack.  Thanks!
<strikov> jtv: give me a few moments
 * jtv gives strikov a dozen moments
<bigjools> rvba: fwiw not sure I'd bother with MPs for the int branch fixes
<rvba> bigjools: wfm
<bigjools> rvba: but for safety, did you set append_revisions_only?
<rvba> bigjools: no
<bigjools> rvba: better do it :)
<bigjools> since we're all going to be pushing up
<rvba> bigjools: how do I do that?
<rvba> bigjools: found it; done.
<bigjools> rvba: you were quicker than me
<bigjools> sftp to the branch location basically
<rvba> bzr config -d bzr+ssh://bazaar.launchpad.net/~maas-maintainers/maas/new-import-script-integration/ append_revisions_only=True
<bigjools> http://stackoverflow.com/questions/5413602/monotonically-increasing-bazaar-trunk-revision-numbers
<lifeless> allenap: hmm
<lifeless> allenap: so with v2 you can debug through the stream
<allenap> lifeless: Ah ha, okay. We ought to upgrade at some point then.
<lifeless> allenap: but, that wouldn't stop the dup madness
<lifeless> allenap: so I think that this is a simple bug and we should fix it in subunit
<lifeless> separately to any discussion about v2 upgrades
<allenap> lifeless: Okay, Iâll put a patch together.
<lifeless> let me look a little more
<lifeless> ok
<lifeless> so we replace fd 1
<lifeless> which means sys.stdout will still go to that fd
<lifeless> and that fd does need to be the fd of the parent pipe, or you won't get the test data
<lifeless> so yeah - I think this is a case for upgrade the connection to v2 and route stdin and out to the child
<lifeless> via v2 packets
<lifeless> should be fairly straight forward
<lifeless> get you debugging
<allenap> I think I need to read up on v2âs design.
<strikov> jtv: https://pastebin.canonical.com/106840/
<strikov> jtv: it disables sign check and switches from md5 to sha256
<jtv> Thanks!  I'll feel a lot better knowing that I can try things out against Scott's latest "real" data.
<jtv> allenap, bigjools, gmb, rvba: see strikov's paste above â the ephemeral-vs stream is not signed yet, so Oleg's patch should help us work around that.  Do Not Commit.  :)
<strikov> jtv: Right. Give me one more moment please -- it crashes with Scott's data due to some reason (not related to sign check)
<jtv> Whoopsie
<bigjools> yay? :)
<jtv> It's one step further than what I got.  :)
<rvba> jtv: we should probably steal the signature-related code from the old ephemeral import script.
<strikov> jtv: heh, that's not my problem though -- so of the entries in Scott's meta doesn't contain checksums
<rvba> And maybe extend it a bit to allow unchecked downloads.
<strikov> *some of
<jtv> rvba: For Freudian reasons, you probably know more about that code than I do...
<jtv> rvba: I don't think we have much signing-related code in there anyway.
<rvba> jtv: just an option to choose the keyring.
<bigjools> rvba: I am thinking that we can get rid of provisioningserver.import_images.tests.test_ephemerals_script entirely
<rvba> bigjools: not entirely, there are tests for helpers we still use in there.
<rvba> uec2roottar thingy, compose_filters
<bigjools> rvba: ok I'll do it
<strikov> jtv: well, i'd say that Scott's meta is broken in many ways
<jtv> ?
<rvba> Yay
<strikov> jtv: not all entries contain checksums (which is required for my script because its cache is checksum-indexed)
<jtv> Ouch
<strikov> jtv: that's definitely a requirement for meta to provide these checksums -- so Scott just didn't fix it yet
<rvba> strikov: it's important to keeps a list of all these problems with the new metadata.  Would you mind adding it to the document we looked at during the call?
<strikov> rvba: well, i don't think that's a real problem because Scott didn't tell me that his meta is ready yet
<strikov> rvba: so, he's working on it right now
<rvba> strikov: I know, but we should keep track of what creates problems for the import script.  So that we can make sure things are fixed when Scott releases a new version.
<strikov> jtv, rvba: how about not pulling resources w/o checksums available?
<strikov> jtv, rvba: that's a hack but it allows us to move forward
<jtv> You mean just ignoring them?  Sounds reasonable to me.
<rvba> strikov: yeah, that's a good workaround.
<strikov> rvba: understood, okay, will do
<rvba> strikov: ta
<jtv> Great, thanks.
<jtv> spasiba.
<bigjools> rvba: just pushed up to r2140
<rvba> Real-world boot images display, for those interested: http://people.canonical.com/~rvb/boot_images_ui.png
<jtv> Nice.
<rvba> The sorting could be better :)
<jtv> I was just writing that I wasn't going to ask about that, because...
<jtv> priorities!
<jtv> But it's nice to have some visibility at last.
<rvba> Yes
<jtv> Review needed: https://code.launchpad.net/~jtv/maas/labels-in-new-import-script/+merge/211910
<rvba> jtv: I'll take it
<jtv> Thanks.
<jtv> Disappointingly small, given the trouble it's caused.
<jtv> Argh!  I accidentally committed my pserv.yaml changes.
<jtv> Let me fix that.
<rvba> jtv: why? These changes are welcome.
<jtv> Not with the commented-out lines...
<jtv> I can add back the actual improvements.
<bigjools> who subscribed the team to the int branch?
<bigjools> don't do that
<jtv> Are we subscribed automatically maybe?
<bigjools> dunno
<jtv> Because it's owned by the team?
<strikov> rvba, jtv, allenap, bigjools, gmb: Workaround to be able to pull Scott's meta (choose armhf in pserv.yaml to avoid pulling tons of images): https://pastebin.canonical.com/106841/
<jtv> \o/
<rvba> strikov: ta
<rvba> This probably deserves a comment in the code though :)
<jtv> This isn't for committing â it's for experimenting.
<strikov> rvba: that a very dirty workaround :)
<rvba> Ah ok.
<jtv> Which I think is very empowering.
<rvba> I thought we wanted to commit thatâ¦ until simplestreams gets fixed.
<jtv> No, it's just a workaround I requested so we could experiment.
<rvba> Reviewer needed (tiny review) https://code.launchpad.net/~rvb/maas/bootimg-ui-sort/+merge/211912
<gmb> rvba:
<rvba> jtv: you need to manually merge your branch to get it landed on the integration branch.
<gmb> rvba: Approved, even :)
<rvba> heh, thanks gmb
 * gmb -> afk for a few hours; back later.
<strikov> jtv, rvba: Scott is fixing this hash issue right now
<rvba> strikov: cool
<jtv> Even better.
<bigjools> rvba: I've been staring at code and re-reading over and over and finally I think I need to accept I am too tired to continue.  I'll catch up tomorrow, don't forget your EOD email :)
<bigjools> I'll send one of my own
<jtv> nn bigjools
<bigjools> nytol
<rvba> nn bigjools
<jtv> Oh, strikov, one thing I was wondering about: why the strange date format in the name of the snapshot directory?  Why not YYYYMMDD?
<jtv> Much better for sorting!
<jtv> I noticed because the name looked like a date in 2003.  :)
<strikov> jtv: no idea.... that was the last thing i worried about. YYYYMMDD looks really well ;)
<jtv> If it doesn't cause any problems, would you mind if I changed it?
<strikov> jtv: sure
<jtv> Thanks.
<strikov> integra
<strikov> ouch, sorry
<alexpilotti> allenap: ping
<jtv> strikov: looks like I got a successful import...  the files are still placeholders.
<alexpilotti> hi guys
<strikov> jtv: really?
<strikov> 1.4G -rw-r--r--  9 root root 1.4G Mar 20 11:49 root-image
<alexpilotti> I'm working on the maas latest bbits, and with today's brz pull I have a few issues :-)
<strikov-lunch> jtv: I'll return back in 15 mins and do a deeper check
<strikov-lunch> jtv: we shouldn't have placeholders there afaik and that looks like a bug
<alexpilotti> The first error in the logs is: [Thu Mar 20 14:22:20.513813 2014] [proxy:error] [pid 16550:tid 46944109119232] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:5243 (localhost) failed
<alexpilotti> it was working fine with yesterday lates bzr bits, so I wonder if anybody has an idea by any chance :-)
<rvba> allenap: can you help alexpilotti please ^
<alexpilotti> allenap: tx!
<alexpilotti> allenap rvba: a stack trace of a related error: http://paste.openstack.org/show/73903/
<alexpilotti> allenap rvba: narrowed down to not being able to start: /home/cloudbase/maas/bin/python /home/cloudbase/maas/bin/maas-region-admin runserver 5243 --settings=maas.demo --noreload
<alexpilotti> getting "ImportError: cannot import name close_old_connections"
<strikov> rvba, jtv: Scott updated his meta. Now it's signed and contains all the required hashes
<strikov> rvba, jtv: checking my script against it right now
<allenap> Hi alexpilotti. Looking now.
<alexpilotti> allenap: tx
<allenap> alexpilotti: The first error implies that the Django app is not up. Try `make status` to check if itâs been started, then look at logs/webapp/current to see what might be the issue.
<allenap> The second error the same.
<allenap> alexpilotti: Ah, okay, I read a bit more of what you wrote :)
<alexpilotti> allenap: webapp is getting continuously respawned
<alexpilotti> e.g:
<alexpilotti> services/web: up (pid 7565) 125 seconds, normally down
<alexpilotti> services/webapp: up (pid 10030) 0 seconds, normally down
<alexpilotti> services/web: up (pid 7565) 140 seconds, normally down
<alexpilotti> services/webapp: up (pid 10251) 1 seconds, normally down
<allenap> alexpilotti: Are you running this on Trusty? Can you check the version of Django youâre using? I wonder if close_old_connections only appears in 1.6.
<alexpilotti> yeap trusty, did an apt-get upgrade along with the bzr pull
<allenap> alexpilotti: Run: apt-cache policy python-django
<alexpilotti> python-django                           1.6.1-2
<alexpilotti> python-django:
<alexpilotti>   Installed: 1.6.1-2
<alexpilotti>   Candidate: 1.6.1-2
<alexpilotti>   Version table:
<alexpilotti>  *** 1.6.1-2 0
<alexpilotti>         500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
<alexpilotti>         100 /var/lib/dpkg/status
<allenap> alexpilotti: And: bin/py -c 'import django; print django.__file__'
<allenap> In the branch.
<alexpilotti> "/usr/local/lib/python2.7/dist-packages/django/__init__.pyc"
<allenap> Ah, youâve got a version of Django in /usr/local that might be stale.
<alexpilotti> allenap: checking!
<alexpilotti> allenap: good ctach: python -c "import django; print django.get_version()"
<alexpilotti> 1.3.1
<alexpilotti> removed, everything is good now, tx!
<tych0> hi allenap, do you have some time to chat today?
<allenap> tych0: Yes! I assume to talk about LXC? Do you want to get this done in time for Trusty?
<tych0> allenap: that was the idea
<tych0> i might just bag it, though
<tych0> you guys don't seem to like the patch
<allenap> tych0: Yeah, sorry. I do like the idea though. I guess itâs mainly for testing, right?
<tych0> and for use in the cloud installer
<tych0> we're already doing this but we have a race condition that this would solve
<tych0> anyway, i'm open to suggestions
<tych0> but i don't want to waste any more time if it's not going to go in
<allenap> tych0: If it can wait a few weeks it would make me happy. Iâd like to get it in, but properly. For example, we may want to add a hook to decommission a machine, to avoid that power-off-equals-destroy hack.
<tych0> allenap: from my POV we could just power it off and leave it alive, and delete it next time it comes up
<tych0> that's basically what maas already does
<tych0> i don't mind either way, really
<tych0> allenap: waiting a few weeks doesn't really do it for me. if it's not in trusty we can't use it in the cloud installer, so i have much less incentive to fix it.
<allenap> tych0: We do have nascent plans to overhaul the transitions a node goes through. Supporting this would be a good use-case. If it can wait, letâs do it properly.
<allenap> tych0: Okay, letâs talk at 1430 UTC. Is that okay?
<tych0> allenap: that's in 15 minutes or so?
<allenap> tych0: Yep.
<tych0> allenap: sounds good
<allenap> gmb, rvba, jtv: Either of you want to talk about LXC in MAAS too?
<allenap> a/Either/Any/
<rvba> allenap: I think I'll passâ¦ I'm too deep into the integration work.
<allenap> tych0: Problems without hangout?
<allenap> Or with even.
<allenap> tych0: Try https://talky.io/maas
<tych0> allenap: joining now
#maas 2014-03-21
<jtv1> bigjools: let me just look up the change that's needed...
<rvba> jtv1: bigjools: Did you guys manage to run the script end-to-end?
<bigjools> jtv1: thank you sir
<jtv1> rvba: I'm running it now.
<bigjools> rvba: I think jtv did, I have been out all day so only just getting up to speed
<jtv1> It's actually imported an image already.
<jtv1> It takes a while, obviously.
<rvba> jtv: are you using the int-fix-boot-imgs patch?
<jtv> No, not yet.
<jtv> Wanted to see the "before" state first.
<rvba> Okay.
<jtv> bigjools: edit mirror_info_for_path
<jtv>     policy = policy_read_signed
<jtv> becomes:
<jtv>     policy = lambda content, *args, **kwargs: content
<bigjools> thanks
<jtv> That'll teach it.
<bigjools> now I get ValueError: No JSON object could be decoded
<jtv> Hwrg
<jtv> Source URL is http://maas.ubuntu.com/images/ephemeral-v2/daily/streams/v1/index.json ?
<jtv> I should get used to calling it "source path" really.
<bigjools>     - path: "http://maas.ubuntu.com/images/ephemeral-v2/daily/streams/v1/index.json"
<jtv> release "trusty", arch "i386", subarches "generic"?
<bigjools> well it has * * * at the moment
<jtv> All as strings?
<jtv> Because we originally had subarches: ['*'] in the example, but it should be a string.
<jtv> Double-quoted, I think.
<jtv> (Not that it's likely to matter)
<rvba> subarches is a list.
<bigjools> all strings
<bigjools> doesn't make any different
<bigjools> I am running straight from the integration branch here, you must have other changes
<jtv> Nope.  But I did have that error earlier...  I wonder if it's just its way of saying "I didn't find anything matching your requirements."
<jtv> Try setting arch/subarches/release.
<jtv> rvba: did subarches become a list?  In the integration branch as I have it (pulled earlier today) it was still a comma-separated string.
<bigjools> ok how are you running the script?
<bigjools> I use bin/py scripts/maas-import-pxe-files
<rvba> jtv: AFAIK, it's been a list since the beginning of the weekâ¦ let me checkâ¦
<bigjools> it's currently not a list
<jtv> bigjools: ah-HAH.  That'll import the globally installed maas modules, won't it?
<jtv> Try running sudo PYTHONPATH=./src scripts/maas-import-pxe-files
<jtv> rvba: no, the pserv.yaml in the branch used to say "[*]" but that didn't actually work.
<rvba> Him, something is wrong then.
<rvba>  subarches = Set(if_missing=['*'])
<rvba> That's how it's defined.
<rvba> s/Him/Hum/
<jtv> When you pasted examples for Julian yesterday, you had subarches as a single comma-separated string.
<bigjools> jtv: I don't have globally installed modules :)
<bigjools> rvba, jtv: ok so I am not sure what else I need to do here to get the script working
 * bigjools dist-upgrades
<jtv> Careful!
<jtv> Remember the old and new pserv.yaml are mutually incompatible.
<jtv> If you have an old pserv.yaml with a new codebase, or vice versa, the upgrade hangs.
<bigjools> jtv: I am not using any packages
<jtv> OK
<bigjools> this is completely from branch
<bigjools> on a fresh canonistack instance
<jtv> Not promising it'll help me understand, but do you have a traceback?
<bigjools> jtv: http://paste.ubuntu.com/7129350/
<jtv> thx
<bigjools> looks like it barfs on the index
<jtv> Most likely, yes.
<rvba> bigjools: I'm running the script nowâ¦
<jtv> For me it completed the download, then broke because it didn't have the int-fix-boot-imgs branch yet.
<jtv> Which I'm trying now.
<jtv> bigjools: that looks like a failure I had earlier.
<jtv> And I'm pretty sure I fixed it by changing pserv.yaml.
<bigjools> I am going to have to break for a bit shortly, I am home alone with twins
<bigjools> there's only so much kids tv that will sate them
<rvba> Script running okay thus far (here is my pserv.yaml http://paste.ubuntu.com/7129354/)
<rvba> Okay, it failed in the end because I don't have the changes from int-fix-boot-imgs.
<rvba> jtv: same as what you got.
<jtv> bigjools: the "boot" part of my pserv.yaml is http://pastebin.ubuntu.com/7129356/
<jtv> Now going to try with the new branch, which includes some label stuff so it'll find a new reason to break.
<rvba> Running the int-fix-boot-imgs branch (plus Scott's fixes which are only in trunk)â¦
<rvba> uec2roottar runningâ¦
<rvba> Script finished running without errors.
 * rvba checks the outputâ¦
<bigjools> so I have a pristine int branch with rvba's pserv.yaml and I get the json decode error
<jtv> And then... commissioning, deploying with fpi, and deploying without fpi!
<jtv> bigjools: what about the policy patch?
<bigjools> I have that
<bigjools> that's it
<bigjools> you guys must have other changes
<jtv> Did you try the pserv.yaml segment I pasted?
<bigjools> I used rvba's
<bigjools> who said his was working
<rvba> Output looks sensible but I don't see the label in the images' path http://paste.ubuntu.com/7129368/
<bigjools> it was the same as mine
<jtv> I have similar results, basically what I expected.
<jtv> Now to work the label in there, and make sure it's not "daily".
<rvba> Well, it should be whatever is in simplestreams' data.
<bigjools> eventually yes but it's broken ATM
<jtv> Actually, in the simplestreams data I'm seeing paths like precise/amd64/di/20101020ubuntu136.15/raring/generic/di-initrd
<jtv> ...which are nothing at all like what we have.
<jtv> bigjools: I remember the weird thing when I got that error was that the JSON was not empty.
<rvba> jtv: the new list_boot_images() in int-fix-boot-imgs seems to work.  Of course, right now it returns the empty list because the label is not yet part of the path.  But I did  manual test (adding the label as part of the images' path manually) and list_boot_images returned something sensible.
<jtv> That's good.  I'm having some more trouble getting mine to work.  :(
<jtv> Looks like I'm missing an update somewhere...  simplestreams looks for <url>/index.json/streams/v1/index.sjson
<jtv>  â so it's not doing the "URL to the index plesae" yet.
<jtv> Merging update from latest integration branch.
<jtv> Success!
<rvba> With that diff (it includes a couple of changes from the int-fix-boot-imgs branch) I get the layout we want: http://paste.ubuntu.com/7129439/
<jtv> "this"
<jtv> Do you get "release" and "alpha-2" as the labels?  Or always "daily"?
 * rvba checks
<rvba> I downloaded only trusty/amd64/generic and for that image the label is daily.
<jtv> Yay!
 * rvba includes saucy, re-runs the script.
<jtv> We'll need to hard-code that to "release"
<jtv> But that's fine â the important thing is that the label is in the dir structure.
<rvba> I don't understandâ¦ shouldn't we just expect Scott to fix that?
 * jtv invites rvba to ponder that option for a bit
<rvba> saucyâdaily
<jtv> Yeah.
<jtv> If it gets fixed before release, then yes, we can just pretend "daily" is a workable label.  But otherwise...
<jtv> For some reason memory usage seems to have jumped.  My little server is getting really slow.
<jtv> Review needed: supporting both the old and the new config items, to avoid upgrade breakage.  https://code.launchpad.net/~jtv/maas/support-new-pserv-config-items/+merge/212110
<rvba> jtv: why do you want to make that part of trunk MAAS now?  Shouldn't we land this with the rest of the int. branchâ¦ if and when we do so?
<jtv> It can complicate testing.  I want to land it in both.
<rvba> New diff with the tgt_entry() method fixed http://paste.ubuntu.com/7129525/
<rvba> err: http://paste.ubuntu.com/7129527/
<jtv> rvba: does that include my int-fix-boot-imgs branch by the way?
<jtv> My version adds "label" in one more place.
<rvba> Weird, this should include the changes you made in your int-fix-boot-imgs branch.
<rvba> You say you see something missing?
<rvba> jtv: btw, subarches should really be a list.  It works with '*' only because a string happens to be an iterable.
<jtv> Christ.
<jtv> But then why does "generic" work?
<rvba> It should work (as in, not crash) but not download anything.
 * rvba tries
<rvba> Hum, looks like the config does something funky: if I set 'subarches: "generic"' in pserv.yaml, I get 'filter['subarches']=['generic']'
<rvba> If I use a list in the config, I get the same list in filter['subarches'].
<rvba> I guess that's a feature.
<jtv> Heaven protect us from features.
<bigjools> help, jtv, rvba.  What are you two doing differently with your branches to mine such that I get that json error?
<rvba> bigjools: I don't know reallyâ¦ can I get access to your canonistack instance?
<bigjools> rvba: one sec
<rvba> jtv: when you're done with testing the diff I sent you, would you mind also getting the most recent changes from the int. branch into your int-fix-boot-imgs branch?  This way, we will be able to build a package from it and test the package.
<rvba> jtv: oh, looks like you did that already :)
<jtv> :-P
<allenap> Merging trunk has resolved the ### INVALID STRING ### stuff, but the region-worker Celery keeps spawning.
<rvba> jtv: Are you integrating my diff or should I create another branch on top of yours?
<jtv> rvba: I'd make it a separate branch.
<rvba> jtv: all right, I'll do it.
<jtv> Now, why does that diff not apply?
<jtv> (I was briefly distracted by travel stuff)
<rvba> jtv: this one will probably do: http://paste.ubuntu.com/7129865/
<rvba> jtv: https://code.launchpad.net/~rvb/maas/use-labels-in-import-script/+merge/212125
<jtv> looking...
<jtv> "patch" is taking forever on my test machine.
<jtv> The performance really dropped quite dramatically.
<allenap> Arg, itâs python-librabbitmq. It causes a seqfault when starting region-worker.
<allenap> segfault even.
<jtv> Ouch.
<bigjools> allenap: didn;t we replace that package with another one?>
<bigjools> we did
<bigjools> it's not installed here
<bigjools> allenap: uninstall it and see what happens
<allenap> Everything works :)
<allenap> I have a branch to forbid that package: https://code.launchpad.net/~allenap/maas/forbidden-deps/+merge/212128
<bigjools> reviewing
 * bigjools AFK for 10m
<rvba> jtv: +1 on https://code.launchpad.net/~jtv/maas/int-fix-boot-imgs/+merge/212082
<jtv> Thanks.
<jtv> I'm already trying from a package, by the way.
<rvba> jtv: https://code.launchpad.net/~rvb/maas/use-labels-in-import-script/+merge/21 is officially up for review
<rvba> jtv: Same here :)
<jtv> Not having much luck pxe-booting though.
<rvba> I'm just getting the lab ready.
<jtv> By the way, when landing into the integration branch, don't forget to mark the branches (as opposed to the MPs) as merged.
<jtv> I'll review your branch.
<rvba> Ta.
<jtv> I have high hopes for the simplestreams cache...
<jtv> I'm re-running the import script after wiping all of my boot-resources directory â *except* the cache.
<jtv> Yup.  Nice & fast!
<bigjools> jtv: where and what is caching?
<jtv> bigjools: images get dowloaded into /var/lib/boot-resources/cache
<jtv> ...and the rest is extracted from there.
<jtv> rvba: are you getting the following error?
<jtv> [2014-03-21 18:06:20,750: ERROR/MainProcess] Task provisioningserver.tasks.report_boot_images[27842890-96bb-4543-8263-1a8ef4dfdff4] raised unexpected: TypeError('<itertools.chain object at 0x7f65809c5b10> is not JSON serializable',)
<jtv> I thought I'd fixed one of those, but...
<jtv> Anyway, I'll write up a fix.
<strikov> Guys, i just built maas packages with 'make package' and cluster-controller depends on 'shim-signed' package which is provided only for amd64.
<bigjools> fuck
<rvba> uh-oh
<rvba> jtv: ta, branch is landed.
<jtv> I hope that merely means that a build failed..?
<rvba> strikov: make sure you pull the latest version of the integration branch, we just landed 2 branches.
<jtv> allenap: thank you once more for fixing the pserv tests.  Unless you were the one who broke them, in which case, I hate you.  :)
<allenap> jtv: Hehe, no I didnât break them :)
<rvba> jtv: didn't see that errorâ¦ but I didn't get that far yet.  I know where the problem isâ¦ but so do you :)
<jtv> Yup.  This is what happens when you play with itertools!
<rvba> heh
<bigjools> allenap: your opinion required.  Blake's branch seems amd64 only.
<bigjools> it uses shim-signed which is only on amd64
<allenap> bigjools: The UEFI one? It only works for amd64, indeed.
<bigjools> allenap: yeah, does it check for amd64 before using it?
<bigjools> it's in m-i-p-f
<allenap> bigjools: Ah, I hope so.
 * allenap checks
<bigjools> allenap: it doesn't
<allenap> Dammit.
<bigjools> yup
<bigjools> allenap: I don;t know how to do an arch-specific dependency in packaging but I am going to learn quickly :)
<allenap> bigjools: Iâm losing you now. Why does this impact packaging?
<bigjools> allenap: we (where we is probably you at this point) should change mipf to check even though we're going to get rid of that script.
<bigjools> allenap: I added a dependency on shim-signed but that makes the package unbuildable on i386
<bigjools> and it's an arch-indep package which only builds on i386
<allenap> s/i386/amd64/ ?
<bigjools> so the packaging should only depend on it if installing on amd64
<bigjools> no i386 intentional
<rvba> jtv: I'm landing a change to pserv.yaml to make subarches a list.
<rvba> (that's a feature we shouldn't hide)
<jtv> Very well.
<allenap> Huh? This makes no sense to me.
<bigjools> allenap: the arch indep builders are all i386
<bigjools> but the package now needs amd64
<bigjools> even though it's technically arch indep
<allenap> Why does the package need amd64?
<bigjools> because shim-signed is a binary package that only exists on amd64
<allenap> Can we change that?
<bigjools> I added it as a cluster controller dependency
<allenap> Itâs just a blob.
<allenap> Afaik.
<bigjools> yeah I need to make it arch dependent
<bigjools> it is
<jtv> rvba: pushed a fix to the json bug.
<allenap> bigjools: Do you mean arch *in*depedent? Or arch dependent for building, so that binaries can be prepared for each arch?
<rvba> jtv: ta. I see you've removed the call to chain()â¦  without removing the import.
<jtv> Ah.  So I forgot to check for lint.  :-)
<rvba> jtv: I'll do it in the branch I'm working on now.
<jtv> Ta.
<jtv> Now, where is this boot images UI?
<jtv> I want my list of boot images!
<bigjools> allenap: I mean to make it so that it only depends on shim-signed if you are installing on amd64
<bigjools> otherwise the dependency cannot be fulfilled
<strikov> allenap, bigjools: I see this issue while trying to install package on armhf: https://pastebin.canonical.com/106925/
<bigjools> strikov: can you use public paste
<bigjools> allenap: that paste is the result of this problem
<bigjools> thank you strikov
<strikov> bigjools, allenap: sorry, here it is: http://pastebin.ubuntu.com/7130103/
<allenap> bigjools: Thatâs fixing the wrong thing, though I grant itâs probably the path of least resistance right now. Thereâs no reason why MAAS installed on i386 canât netboot an amd64 system using UEFI.
<bigjools> allenap: very true
<rvba> allenap: the path of least resistance would be to include that blob in MAAS' tree and remove the dependency, wouldn't it?
<allenap> rvba: Ah, yes, though we may find that our sticky-out bits are at risk from the scythes of the security team.
<rvba> Hum, good point.
<allenap> blake_râs original approach was to download from the archive. Perhaps we need to reconsider that?
<bigjools> he was downloading the source package
<bigjools> which is problematic, not everyone has sources enabled
<jtv> Or if downloading directly, we'd lose built-in signature verification.
<bigjools> allenap: I think we need to revert blake's branch then
<allenap> bigjools: Or fix it.
<bigjools> and fold its changes, with the shim-signed stuff, into the new script
<bigjools> well the new script is nearly done
<bigjools> let's not do the work twice
<allenap> bigjools: There was a lot more work in Blakeâs branch than just m-i-p-f. Do we want to revert all of it?
<bigjools> no not at all
<bigjools> just the bits that are going to break without shim-signed :)
<allenap> bigjools: The rationale for reverting versus ploughing through is because itâs blocking QA?
<bigjools> allenap: it'll block everything, I think mipf will crash
<bigjools> we could comment out that one line in it
<allenap> bigjools: Yeah, letâs hack round it to unblock things.
<bigjools> can't tell if you're serious or being sarcy...
<allenap> bigjools: Serious :) Agreeing with you.
<bigjools> allenap: oh good :)
<bigjools> allenap: are you ok to do that while I unfcuk the packaging?
<allenap> bigjools: I need to work around all references to the shim, right?
<bigjools> allenap: I think it's just one call you can comment out to the new func
<bigjools> see the diff to mipf
<allenap> bigjools: So, donât call update_uefi_boot_loader at all?
<bigjools> allenap: just don't call it at all for now to unblock and then fix later
<bigjools> so yes :)
<bigjools> allenap: also remove shim-signed from required-packages
<allenap> Okeydoke.
<allenap> bigjools: Is there a bug about this?
<bigjools> allenap: no
 * allenap files one
<bigjools> ok packaging fix just went in
<allenap> I have lots of tests to disable.
<bigjools> oh well :/
<allenap> bigjools: https://bugs.launchpad.net/maas/+bug/1295644
<ubot5> Ubuntu bug 1295644 in MAAS "MAAS cannot be installed on non-amd64 system" [Critical,In progress]
<bigjools> thanks allenap
 * bigjools sleeps
<allenap> bigjools: Fwiw, by reusing your packaging branch every time, each revision gets tagged with the same bugs. See https://code.launchpad.net/~maas-maintainers/maas/packaging.
<allenap> It also means I canât link that branch to the bug.
<allenap> rvba: Do you have time for a quick (critical) review fix? https://code.launchpad.net/~allenap/maas/disable-uefi-temporarily/+merge/212150
<rvba> allenap: looking now
<strikov> Could someone review my patch to allow us to use different keyrings for different sources: http://bazaar.launchpad.net/~strikov/maas/new-import-script-integration.keyring-per-each-source/revision/2155 Thanks
<rvba> strikov: I'll have a look
<rvba> strikov: looks good, but you need to fix the test_config.py tests (yes, we have unit-tests for this): ./bin/test.maas ./src/provisioningserver/tests/test_config.py
<strikov> rvba: thanks for the review, does it look better: http://bazaar.launchpad.net/~strikov/maas/new-import-script-integration.keyring-per-each-source.2/revision/2155
<strikov> rvba: Ran 25 tests in 0.719s
<strikov> OK
<rvba> strikov: cool.  Looks good.  If testing is okay, land it.
<rvba> strikov: maybe also update pserv.yaml (I know the value is the default, but it's a good example)
<strikov> rvba: will do
<strikov> rvba: Pushed with pserv.yaml change. Thanks.
<rvba> allenap: time for a tiny review? https://code.launchpad.net/~rvb/maas/build-depe/+merge/212173
<allenap> rvba: Sure!
<allenap> rvba: Oh man, the deps are not sorted.
<rvba> allenap: ahhhhh!
<rvba> allenap: fixed
<allenap> rvba: If you have a few minutes, can you look at my rpc-ident-redux branch, https://code.launchpad.net/~allenap/maas/rpc-ident-redux/+merge/212070? You only actually need to review the interdiff, http://paste.ubuntu.com/7129526/, which is a lot shorter.
<rvba> allenap: k
<allenap> rvba: Have you noticed shells taking a long time to exit when closing? I hit Ctrl-d in a screen âtabâ and it can take 20-30 seconds for bash to exit. At least, I assume itâs bash taking its time.
<allenap> Itâs been doing it for a couple of weeks, maybe more.
<rvba> allenap: no, it clearly doesn't do that for me.
<tych0> hi allenap, any idea what this is? http://paste.ubuntu.com/7131290/
<tych0> i'm getting lots of them
<tych0> and a clue is that my dhcp server seems to not be working
<allenap> tych0: Mmm, was there a request path anywhere near that?
<tych0> not in maas.log, might be in apache's logs, though, let me look
<tych0> yeah, access.log is totally empty
<tych0> error.log doesn't have any timestamps close to that one
<allenap> tych0: Is the DHCP server down, not giving out addresses? Or is it that leases are not getting into MAAS? (Not sure what outward indication there would be of thatâ¦)
<tych0> allenap: it appears to not even be giving out addresses, although i restarted maas-dhcp-server
<tych0> allenap: is there a log for it somewhere?
<allenap> tych0: The leases file in /var/lib/dhcp might have something useful. Otherwise look in /var/log/syslog.
<tych0> yeah, /var/lib/dhcp/dhcpd.leases is empty
<allenap> tych0: Are you happy to dig around, try to find out why itâs not running, or not populating the leases file at least?
<tych0> allenap: yeah, that's what i'm doing now
<tych0> this might be an lxc, thing, actually
<tych0> ah, nope
<tych0> lxc is asking for one
<tych0> it just isn't getting anything back
<tych0> ah
<tych0> i had dnsmasq running
<allenap> tych0: Phew, itâs not another MAAS bug :)
<Fishy_> hi!
<Fishy_> i am trying to follow the newbie install tutorial and getting stuck.. any pointers?  http://paste.ubuntu.com/7131844/
<Fishy_> i guess sudo maas-import-pxe-files   works
<Fishy_> but document says thats only for sub 1.3
<tcollins> Ive just setup my first MAAS server and now I have an issue with PXE booting.  I can successfuly get an IP, but nodes cannot find a pxelinux.cfg
<tcollins> does maas create this or do I have to do it manually?
<tcollins> seem tobe an access problem.  in maas.log getting "SuspiciousOperation: Invalid HTTP_HOST header (you may need to set ALLOWED_HOSTS):"
<Fishy_> I am trying to do the same thing ;)
<Fishy_> running maas server on a bridge, trying to expose the dhcp and dns from my maas server without trashing my entire network
<Fishy_> and feed into a pxe boot
<Fishy> humm what is "Router Ip"
<Fishy> the upstream gateway of mine?
<tcollins> I set mine the same as the maas server
<tcollins> im trying to bridge as well
<tcollins> ok I got it to PXE boot, had to reinstall and start from scratch
<tcollins> followed these: http://frugnul.blogspot.com/2013/04/maas-not-tutorial.html
<Fishy> hum
<Fishy> by default, the little lxcbr0 bridge that juju added to my local machine, is not exposed to the world
<Fishy> i think I need to add my eth0 to be behind it
<Fishy> so that it can be exposed
<Fishy> but beyond what I have done before
<tcollins> do you have physical machines, who are they just on the same machine?
<Fishy> right now I have 2 phical machines
<Fishy> 1) desktop I am on now.  want it to keep connected to current network (192.168.78) as a client..  but also want it to host a new maas network (as 192.168.4.1)
<Fishy> 2) a laptop I want to boot off PXE, and grab the 192.168.4.1 broadcast
<Fishy> and get added to maas
<Fishy> have a maas server up
<Fishy> his IP is set to 192.168.4.1
<Fishy> laptop cant even ping that though
<Fishy> so that network is local to my box
<Fishy> so its like a need a bridge in front of my bridge
<Fishy> to tie my real eth0 to both networks
<Fishy> argh, networking hard
#maas 2015-03-16
<mup> Bug #1408980 changed: MAAS 1.5.4 started failing to register machines after deployment <MAAS:Expired> <https://launchpad.net/bugs/1408980>
<mup> Bug #1408980 was opened: MAAS 1.5.4 started failing to register machines after deployment <MAAS:Expired> <https://launchpad.net/bugs/1408980>
<mup> Bug #1408980 changed: MAAS 1.5.4 started failing to register machines after deployment <MAAS:Expired> <https://launchpad.net/bugs/1408980>
<AskUbuntu_> setup pXE boot server and PXE booting for ubuntu server | http://askubuntu.com/q/597421
<arnaud_orange> hi guys
<arnaud_orange> i am just trying MAAS 1.7.1 and wondering where is the the "check power state" button? Is it removed on 1.7.1?
<dimitern> arnaud_orange, hey, it should be in the node details page - the one you get when you edit a node
<dimitern> arnaud_orange, no sorry - not when you edit, but when you view a node
<arnaud_orange> you're right, this is where it was before the upgrade
<arnaud_orange> but It disappeared
<arnaud_orange> i found that bug: https://bugs.launchpad.net/maas/+bug/1400849
<arnaud_orange> I check the javascript file, and my install is missing the fix
<arnaud_orange> the package installed on my server is : 1.7.1+bzr3341-0ubuntu1~utopic1
<arnaud_orange> from http://ppa.launchpad.net/maas-maintainers/stable/ubuntu/
<dimitern> arnaud_orange, oh, I didn't know about this issue
<arnaud_orange> maybe I am not using the correct ppa
<dimitern> arnaud_orange, it's not released as a stable version yet - try the staging or experimental ppa (the latter only as last resort)
<arnaud_orange> dimitern: do you mean the Testing one?
<dimitern> arnaud_orange, no, sorry - I meant "dailybuilds"
<arnaud_orange> ok, will try
<mup> Bug #1432666 was opened: [FFe] New upstream release 1.8.0 <maas (Ubuntu):New> <https://launchpad.net/bugs/1432666>
<AskUbuntu_> Adding network to machine deployed by Juju | http://askubuntu.com/q/597514
<roaksoax> /win 17
<mup> Bug #1432828 was opened: MAAS needs to write power off jobs to to systemd units instead of upstart <MAAS:New> <https://launchpad.net/bugs/1432828>
#maas 2015-03-17
<mup> Bug #1433012 was opened: TestAcquireNodeForm.test_storage_with_named_constraints is flaky <tech-debt> <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1433012>
<voidspace> I'm getting the following maas-django.log (along with an internal server error)
<voidspace> ImproperlyConfigured: Error importing module maasserver.context_processors.py: "Nomodule named apt_pkg"
<voidspace> in maasserver/utils/version.py
<voidspace> running from the dev ppa I believe
<voidspace> utopic
<voidspace> ah, I needed to install python-apt
<dimitern> rvba, ping
<AskUbuntu_> Landscape openstack juju management | http://askubuntu.com/q/597979
<mup> Bug #1433244 was opened: MAAS should handle RAM upgrades without decommissioning / recommissioning existing nodes <openstack> <uosci> <MAAS:New> <https://launchpad.net/bugs/1433244>
<mup> Bug #1433275 was opened: Connection Errors after "Too many open files" <juju> <MAAS:New> <https://launchpad.net/bugs/1433275>
<mup> Bug #1433275 changed: Connection Errors after "Too many open files" <juju> <MAAS:New> <https://launchpad.net/bugs/1433275>
<mup> Bug #1433244 changed: MAAS should handle RAM upgrades without decommissioning / recommissioning existing nodes <openstack> <uosci> <juju-core:New> <MAAS:Won't Fix> <https://launchpad.net/bugs/1433244>
<mup> Bug #1433275 was opened: Connection Errors after "Too many open files" <juju> <MAAS:New> <https://launchpad.net/bugs/1433275>
<mup> Bug #1433244 was opened: MAAS should handle RAM upgrades without decommissioning / recommissioning existing nodes <openstack> <uosci> <juju-core:New> <MAAS:Won't Fix> <https://launchpad.net/bugs/1433244>
<arges> roaksoax: fwiw fixed bug 1422457 for you. review whenever you have time, no hurry
<mup> Bug #1433244 changed: MAAS should handle RAM upgrades without decommissioning / recommissioning existing nodes <openstack> <uosci> <juju-core:New> <MAAS:Won't Fix> <https://launchpad.net/bugs/1433244>
<roaksoax> bug #1422457
<roaksoax> arges: does make format or make lint pass?
<arges> roaksoax: running it now
<arges> roaksoax: no errors
<roaksoax> arges: then land it (change the Needs Review to Approve) and the lander will take care of it
<arges> roaksoax: ok
<arges> roaksoax: i can't change it to Approve ( I dont think I have the permissions)
<arges> for the merge proposal
<roaksoax> arges: done
<arges> roaksoax: thanks again
<bdx> Hows it going everyone? I have a issue concerning booting a node with multiple interfaces....is there a was to have maas provision(commission) a node whos only connected interface is not eth0???
<bdx> way(SP)
<bdx> ANY insight on this issue would be greatly appreciated........ jamesbeedy@gmail.com ...let me know whats up!!!!
<bdx> Hows it going everyone? I have a issue concerning booting a node with multiple interfaces....is there a way to have maas provision(commission) a node whos only connected interface is not eth0???
#maas 2015-03-18
<bdx> How's it going everyone?? Can anyone provide any insight on this?
<bdx> http://askubuntu.com/questions/598139/maas-cannot-provision-node-with-interface-other-than-eth0
<AskUbuntu_> MAAS - Cannot provision node with interface other than eth0 | http://askubuntu.com/q/598139
<AskUbuntu_> Juju - Openstack service charm networking configurations and limitations | http://askubuntu.com/q/598156
<mup> Bug #1433622 was opened: maas cluster name should not / can not have trailing '.' <MAAS:Triaged> <https://launchpad.net/bugs/1433622>
<mup> Bug #1433625 was opened: 'APIErrorsMiddleware' object has no attribute 'RETRY_AFTER_SERVICE_UNAVAILABLE' <MAAS:Triaged> <https://launchpad.net/bugs/1433625>
<mup> Bug #1433627 was opened: maas cli admin cannot get api creds for another user (must use maas-region-admin) <MAAS:New> <https://launchpad.net/bugs/1433627>
<murphyslawbbs> Hi, I've made some changes to my preseed files but they are ignored by maas. Is there anything I have to do to force maas to use the changed files? They are in /etc/maas/preseeds
<mup> Bug #1433697 was opened: maas depends on syslinux-dev, removed upstream <maas (Ubuntu):New> <https://launchpad.net/bugs/1433697>
<Noice> Hey, I just tried installing MaaS using the ubuntu server install, but I can't get the images to download. Where is the log file for that at so I can see what is going on?
<mup> Bug #1433702 was opened: DEFAULT_MAAS_URL missing port number <MAAS:New> <https://launchpad.net/bugs/1433702>
<roaksoax> Noice: /var/log/maas/*.log
<Noice> thanks
<mup> Bug #1433697 was opened: maas depends on syslinux-dev, removed upstream <MAAS:In Progress by andreserl> <maas (Ubuntu):Fix Committed> <https://launchpad.net/bugs/1433697>
<mup> Bug #1433742 was opened: acquiring a node in specific zone doesnt work <MAAS:Triaged> <https://launchpad.net/bugs/1433742>
<mup> Bug #1433697 changed: maas depends on syslinux-dev, removed upstream <MAAS:In Progress by andreserl> <maas (Ubuntu):Fix Released> <https://launchpad.net/bugs/1433697>
<mup> Bug #1433786 was opened: MAAS Image page no longer has check boxes <MAAS:Confirmed for ricgard> <https://launchpad.net/bugs/1433786>
<j^2> 433808
#maas 2015-03-19
<AskUbuntu_> which openstack version will be installed with juju? | http://askubuntu.com/q/598768
<maasquerad> Hi, short question: how can i update Ubuntu provided MAAS images? E.g. the 14.04 image seems to be quite outdated
<mup> Bug #1434257 was opened: MAAS should set dnssec-validation to no in /etc/bind/named.conf.options <maas (Ubuntu):New> <https://launchpad.net/bugs/1434257>
<mup> Bug #1434271 was opened: If Add Chassis fails for whatever reason (i.e. failed to log into chassis), no errors displayed in the WebUI. <ui> <MAAS:Triaged by blake-rouse> <https://launchpad.net/bugs/1434271>
#maas 2015-03-20
<mup> Bug #1434559 was opened: If node fails to access the image stream, a nasty error log is shown as a notification on teh webui <MAAS:Triaged by blake-rouse> <https://launchpad.net/bugs/1434559>
<jrwren> http://askubuntu.com/questions/599157/using-juju-with-maas-worked-at-first-but-is-now-giving-503-error-gomaasapi
<kiko> jrwren, we'll need to see what's happening in the maas logs, and also, what the maas version is
<kiko> jrwren, so look for tracebacks in /var/log/maas/*.log
<kiko> and include the dpkg -l | grep maas output
<jrwren> kiko: I think I found the issue. I'll answer my own question in a bit :)
<kiko> heh
<AskUbuntu_> Using juju with maas worked at first but is now giving 503 error gomaasapi | http://askubuntu.com/q/599157
<mup> Bug #1434602 was opened: race condition in maas-region-controller postinst <MAAS:New> <https://launchpad.net/bugs/1434602>
<mup> Bug #1434602 changed: race condition in maas-region-controller postinst <MAAS:New> <https://launchpad.net/bugs/1434602>
<mup> Bug #1434602 was opened: race condition in maas-region-controller postinst <MAAS:New> <https://launchpad.net/bugs/1434602>
<ali8> Does MaaS 1.7.1 support booting from UEFI?
<ali8> I'm trying to get it to work at the moment and the node stops at grub
<ali8> I'm assuming it's looking for grub.cfg-default-amd64 since grub.cfg includes it, but I don't see that file anywhere on the maas server
<kiko> ali8, yes, it definitely does
<kiko> blake_r, ^^
<kiko> ali8, if you don't get an answer could you ask the question on askubuntu and I'll get somebody to answer?
<blake_r> ali8: that file is not on the server
<blake_r> ali8: that file is dyanmically generated by the maas tftp server
<blake_r> ali8: that alerts MAAS that the machine trying to boot is amd64
<blake_r> ali8: at what point in the grub boot does it get?
<mup> Bug #1433742 changed: [API] acquiring a node in specific zone doesnt work <MAAS:Invalid> <https://launchpad.net/bugs/1433742>
<ali8> hi blake_r, it just shows a grub screen without any options
<ali8> thanks kiko, I will
<blake_r> ali8: is it the grub command prompt?
<ali8> so should I see a request is pserv.log for a grub.cfg-default-amd64? I see a request for bootx64.efi followed by grubx64.efi but nothing else (actually including just grub.cfg)
<ali8> yes, it's the grub command prompt
<ali8> I also experienced the same issues as described in https://bugs.launchpad.net/maas/+bug/1317705 and patched python-tx-tfp to get around it
<blake_r> ali8: what version of ubuntu is your MAAS server?
<blake_r> ali8: you should see a request for grub.cfg, then another request for grub.cfg-default-amd64
<mup> Bug #1433742 was opened: [API] acquiring a node in specific zone doesnt work <MAAS:Invalid> <https://launchpad.net/bugs/1433742>
<ali8> the server is running 14.04, the version of maas installed is  1.7.1+bzr3341-0ubuntu1~trusty1
<ali8> maas is from the ppa:maas-maintainers/stable repository
<blake_r> do you see those request in clusterd.log
<ali8> blake_r: nope... there is almost nothing is cluster.log
<ali8> maas-clustured.log
<blake_r> ali8: are you seeing any TFTP requests?
<kiko> weird
<mup> Bug #1433742 changed: [API] acquiring a node in specific zone doesnt work <MAAS:Invalid> <https://launchpad.net/bugs/1433742>
<ali8> blake_r: is maas-clustered.log? nope. they are in pserv.log (bootx64.efi, grubx64.efi)
<blake_r> ali8: this was an upgrade?
<blake_r> ali8: from 1.5?
<ali8> blake_r: I ended up purging the old packages and then installing 1.7.1
<blake_r> ali8: is the timestamp from pserv.log recent?
<ali8> blake_r: yes, it's an hour old, but that is when I ran into this issue. let me just reboot the system again and watch the log
<ali8> blake_r:  yes, the pserv.log again shows an access for bootx64 and grubx64 and no other ones
<mup> Bug #1431984 changed: [API] acquire does not allow for name= <MAAS:Invalid> <https://launchpad.net/bugs/1431984>
<mup> Bug #1434664 was opened: A bulk change of 1000 node statuses will result in 1000 updates to DNS <dns> <scaling> <MAAS:Triaged> <https://launchpad.net/bugs/1434664>
<mup> Bug #1434679 was opened: maas does not know about vivid <amd64> <apport-bug> <third-party-packages> <trusty> <maas (Ubuntu):Confirmed> <https://launchpad.net/bugs/1434679>
<mup> Bug #1434709 was opened: Node failed to successfully commission <MAAS:New> <https://launchpad.net/bugs/1434709>
<mup> Bug #1434709 changed: Node failed to successfully commission <MAAS:New> <https://launchpad.net/bugs/1434709>
<mup> Bug #1434709 was opened: Node failed to successfully commission <MAAS:New> <https://launchpad.net/bugs/1434709>
<mup> Bug #1434736 was opened: Bulk actions fail altogether (nothing happens) if too many machines are selected <MAAS:Confirmed> <https://launchpad.net/bugs/1434736>
#maas 2016-03-21
<mup> Bug #1531272 changed: 1.9 rc4: servers stuck in deploying - no power parameters in nodes view <oil> <MAAS:Expired> <https://launchpad.net/bugs/1531272>
<mup> Bug #1559894 opened: Fail to power on server via wakeonlan <wol> <MAAS:New> <https://launchpad.net/bugs/1559894>
<mup> Bug #1559699 changed: [1.9.1] Commissioning doesn't detect partitioning of secondary hard disk <maas (Ubuntu):Won't Fix> <https://launchpad.net/bugs/1559699>
<voidspace> I get a "weak digest" warning from apt on next-proposed
<roaksoax-afk> voidspace: https://bugs.launchpad.net/launchpad/+bug/1556666
<voidspace> roaksoax-afk: thanks
<voidspace> heh
<mup> Bug #1491474 changed: MAAS WoL power control broken <MAAS:Won't Fix by newell-jensen> <https://launchpad.net/bugs/1491474>
<mup> Bug #1037659 changed: Blanking out the mac_address power parameter for a node using WoL breaks the power parameters used to boot. <power> <wol> <MAAS:Invalid> <https://launchpad.net/bugs/1037659>
<timello> folks, any good resource/recommended way to backup MaaS, specially nodes definition. Anything that can help rebuild the environment quickly
<voidspace> roaksoax: ping
<voidspace> what's the corresponding 2.0 api for /api/1.0/nodegroups/{uuid}/boot-images/
<roaksoax> voidspace: that doesn't exist anymore IIRC, there's boot-resource(s)
<roaksoax> voidspace: http://maas.ubuntu.com/docs2.0/api.html
<voidspace> roaksoax: right, I see boot-resources
<voidspace> the output is a different format to boot images
<voidspace> roaksoax: thanks
<voidspace> roaksoax: in "i386/hwe-w" architecture, what does the "hwe-w" mean?
<voidspace> is it the kernel?
<roaksoax> voidspace: yes
<voidspace> roaksoax: thanks
<mup> Bug #1349857 changed: maas-common fails to set up symbolic link to etc/rsyslog/99-maas.conf <ci> <maas (Ubuntu):Fix Released by julian-edwards> <https://launchpad.net/bugs/1349857>
<kiko> kirkland, ping?
<mup> Bug #1560233 opened: [2.0a3] maas-regiond not available right after install. <MAAS:Confirmed> <https://launchpad.net/bugs/1560233>
#maas 2016-03-22
<mup> Bug #1560292 opened: maas cli to set storage type no longer works <hwcert-server> <MAAS:New> <https://launchpad.net/bugs/1560292>
<satyam_> hey please help me
<satyam_> I am installing MAAS on ubuntu 14.04
<satyam_> But I am getting this error:
<satyam_> ImportError: Could not import settings 'maas.settings' (Is it on sys.path? Is there an import error in the settings file?): No module named maasserver.config dpkg: error processing package maas-region-controller-min (--configure):  subprocess installed post-installation script returned error exit status 1
<satyam_> Errors were encountered while processing:  maas-region-controller-min  maas-dns  maas-region-controller  maas E: Sub-process /usr/bin/dpkg returned an error code (1)
<satyam_> Please suggest the solution
<voidspace> is it correct that in the maas 2.0 api there is no direct equivalent of /nodes/?op=deployment_status
<mup> Bug #1560492 opened: [2.0a3 UI] table contents is misaligned <MAAS:New> <https://launchpad.net/bugs/1560492>
<mup> Bug #1560495 opened: [UI 2.0a3] Bad table spacing between columns <MAAS:New> <https://launchpad.net/bugs/1560495>
<mup> Bug #1560693 opened: dist-upgrade update failure <MAAS:New> <https://launchpad.net/bugs/1560693>
#maas 2016-03-23
<John_Kang> hey, is it possible to test MASS on a virtualbox ?
<mup> Bug #1560789 opened: [1.9.1]failed deployments because of accidental boot device selection possible and can't deselect <oil> <MAAS:New> <https://launchpad.net/bugs/1560789>
<satyam> I am installing MAAS on ubuntu 14.04, but getting an error like this:
<satyam> ImportError: Could not import settings 'maas.settings' (Is it on sys.path? Is there an import error in the settings file?): No module named maasserver.config dpkg: error processing package maas-region-controller-min (--configure):  subprocess installed post-installation script returned error exit status 1
<satyam> dpkg: error processing package maas (--configure):  dependency problems - leaving unconfigured Errors were encountered while processing:  maas-region-controller-min  maas-dns  maas-region-controller  maas E: Sub-process /usr/bin/dpkg returned an error code (1)
<satyam> Please help with this issue
<mup> Bug #1560815 opened: [2.0a3] apt-get install maas fails due to postgresql connection <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1560815>
<mup> Bug #1560815 changed: [2.0a3] apt-get install maas fails due to postgresql connection <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1560815>
<mup> Bug #1560815 opened: [2.0a3] apt-get install maas fails due to postgresql connection <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1560815>
<mup> Bug #1560830 opened: maas power check won't work with ipmi hosts with the string 'on' in them <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1560830>
<voidspace> roaksoax: ping, are you around yet?
<simonh> Hi! Is it possible to configure a node, so that I can manually startup a machine?
<mup> Bug #1560901 opened: install maas (2.0 alpha3) from image (ubuntu 16.04) does not include power-types <maas (Ubuntu):New> <https://launchpad.net/bugs/1560901>
<roaksoax> voidspace: here
<mup> Bug #1560901 changed: install maas (2.0 alpha3) from image (ubuntu 16.04) does not include power-types <maas (Ubuntu):Invalid> <https://launchpad.net/bugs/1560901>
<voidspace> roaksoax: morning
<mup> Bug #1560971 opened: after default installation of maas the rack and region controller are not connected <maas (Ubuntu):New> <https://launchpad.net/bugs/1560971>
<Simon> Hi, can MAAS deploy CentOS servers? and do I need DHCP for it to work?
<Simon> Hi, can MAAS deploy CentOS servers? and do I need DHCP for it to work?
<Simon> Hi, can MAAS deploy CentOS servers? and do I need DHCP for it to work?
<Simon> Hi, can MAAS deploy CentOS servers? and do I need DHCP for it to work?
<Simon> Hi, can MAAS deploy CentOS servers? and do I need DHCP for it to work?
<Simon> Hi, can MAAS deploy CentOS servers? and do I need DHCP for it to work?
<Simon> Hi, can MAAS deploy CentOS servers? and do I need DHCP for it to work?
<stormmore> yes and no
<LiftedKilt> in MAAS 2.0, is there a method to  reconfigure the DHCP scope for a vlan once it's enabled? The options disappear once you initially add them
<LiftedKilt> I had pointed the gateway at the network gateway, but the nodes are attempting to query a url on that address during initial commissioning, so I am assuming I was supposed to point it at the MAAS server itself
<LiftedKilt> I fixed it from the CLI - maas admin subnet update 10.101.0.0/16 gateway_ip=10.101.0.X, where X is not the network gateway but is the address of the PXE interface on the MAAS server
<roaksoax> LiftedKilt: the gateway shouldn't really impact in any way where the nodes should be communicating the the rack/region controller
<roaksoax> LiftedKilt: if that's the case, there might be a bug
<LiftedKilt> roaksoax: It doesn't seem like it should, but it was attempting to query http://<gateway-ip>/meta-data/instance-id or something like that
<roaksoax> LiftedKilt: make sure that /etc/maas/rackd.conf is pointing to a correct IP other than localhost
<LiftedKilt> I changed the gateway to be the ip of the maas controller, and rebooted and the nodes started enlisting no problem
<roaksoax> LiftedKilt: that may be the reason
<roaksoax> LiftedKilt: strange indeed. That seems like a bug to me
<mpontillo> LiftedKilt: when you say "DHCP scope" are you talking about the IP ranges, gateway IP, or both? both are intended to be editable on the subnet details page, but that functionality hasn't been finished yet for the 2.0 alpha release
<mpontillo> LiftedKilt: the "Provide DHCP" option on the VLAN details page is intended mainly to specify the rack controllers, but we added initial IP range and gateway specification as a convenience feature as well
<LiftedKilt> roaksoax: the rackd.conf file is pointing at the right ip
<mpontillo> LiftedKilt: if those items already exist the 2nd time you "Provide DHCP", the mechanics of allowing the user to edit them in that tiny drop-down form are a bit problematic
<mpontillo> (also, when the rack registers it attempts to discover the default gateway and assign it to the subnet, FYI.)
<LiftedKilt> mpontillo: yeah that's the issue I was seeing
<LiftedKilt> mpontillo, roaksoax: it's odd that changing the network gateway to the IP of the maas server was necessary for enlisting though
<roaksoax> LiftedKilt: that shouldn't be necessary. The rack / region controller communication should determine what IP address to give the node for the metadata server
<mpontillo> LiftedKilt: I'm a bit confused about that part. is your region controller on a different subnet; one that would require the gateway to access? (the metadata server is on the region controller...)
<LiftedKilt> So I did a clean install of maas 2.0 alpha3, added the 16.04 image for commissioning/deployment, and tried to pxe boot a node
<LiftedKilt> mpontillo: everything pxe is on a single subnet, I have a separate subnet for access to the maas controller
<LiftedKilt> on maas 1.9 I had the webui listening on the 192.168.4.0/24 network, and the api access for pxe on the 10.101.0.0/16 network
<roaksoax> LiftedKilt: so? regiond (ethX on 10.101.0.0/16) <---> (10.101.0.0/16 on ethX) cluster (ethY 192.168.4.0/24) -->  nodes
<roaksoax> LiftedKilt: and the machines would PXE boot off 192.168.* , and told that the API( metadata server) was on 10.101.* ?
<mpontillo> LiftedKilt, do I understand correctly that there is no routing between the PXE subnet and the management network?
<LiftedKilt> machines would pxe off of the 10 network, and would stay on the 10 network post deployment. The 192.168 network was simply for ssh access to the box and access to the webui
<mpontillo> LiftedKilt: I just checked the code; it looks like we just pull maas_url out of /etc/maas/regiond.conf and tell newly enlisted nodes to use that to report back to MAAS
<roaksoax> mpontillo: that's the case if we cannot detect from what rack controller we pxe booted from
<mpontillo> that's get_preseed_context() in maasserver/preseed.py;         'metadata_enlist_url': absolute_reverse('enlist', base_url=base_url), --> absolute_reverse() just grabs the URL from the config and appends the desired enlistment URL
<roaksoax> mpontillo: but if we do, we tell it the IP from which the rack controller was able to connect through
<roaksoax> mpontillo:     if rack_controller is None:
<roaksoax>         base_url = None
<roaksoax>     else:
<roaksoax>         base_url = rack_controller.url
<roaksoax> mpontillo: is not maas_url straight out of regiond.conf
<mpontillo> roaksoax: well, the mechanism looks slightly different depending on which URL you're talking about; I see that the node has a chance to override some properties, but it isn't clear to me which ones
<mpontillo> roaksoax: but I see what you're talking about
<roaksoax> mpontillo: yeah, so if we can't determine the url, because say rackd.conf points to localhost/MAAS , then we give maas_url of regiond.conf
<ReSam> good morning!
<ReSam> I'm getting erros during commissioning - is there any way to debug it or get the logs from the screen?
<ReSam> I guess the cloud-init stuff fails somewhere
<roaksoax> ReSam: you may be able to see what's failing on the event log under the machine details
<roaksoax> ReSam: if not, you'll have to connect to a serial console and see what's going on
<ReSam> roaksoax: nope - it just says "Failed commissioning"
<ReSam> I can see the screen of the machine via VNC - but the text scrolls past quickly
<ReSam> or is there any way to ssh into the commissioning ubuntu 14.04
<roaksoax> ReSam: you can, but only if you are using maas 1.9+
<ReSam> yes - please tell me!
<ReSam> I can connect via SSH, but my key (which I entered in maas for my user) is not accepted
<ReSam> roaksoax: or is there a default password I don't know yet?
<roaksoax> ReSam: on commissioning, there's an option there to import your ssh key
<roaksoax> ReSam: so just ssh ubuntu@<ip-of-machine-while-commissioning>
<ReSam> I imported my key - doesn't work.
<ReSam> I can ssh - but it rejects my key - and doesn't allow me to enter a password
<roaksoax> ReSam: then it might be failing before getting to the point, because the option should prevent the machine from turning off after commissioning
<ReSam> yes - it stays on. I can see it via VNC from my management system
<roaksoax> ReSam: so, you are clicking on " Allow SSH access and prevent machine from powering off" ?
<ReSam> roaksoax: yes
<roaksoax> ReSam: strange... since after running the commissioning image it should have imported your key
<roaksoax> ReSam: and prevented the machine ffrom powering off
<ReSam> but it doesn't accept my key. it just tries all 5 keys - and then says "Permission denied (publickey)."
<roaksoax> ReSam: right, which means it may have not been imported
<roaksoax> ReSam: if you go to the machine details -> Latest machine events -> view full history
<roaksoax> ReSam: hwat does it show ?
<ReSam> roaksoax: Node changed status - From 'Commissioning' to 'Failed commissioning'
<roaksoax> ReSam: how quickly ?\\
<roaksoax> what's the timestamp since it started ?
<ReSam> 3min or so. I can watch it doing stuff. but it's to fast to actually read stuff
<ReSam> It looks like apt-get install fails or so...
<roaksoax> ReSam: if apt-get fails, are you runing a proxy ?
<roaksoax> ReSam: is maas-proxy running ?
<ReSam> yes - should all be working
<ReSam> roaksoax: I was hoping I could find logs in: /var/log/maas/rsyslog
<ReSam> but it is empty...
<roaksoax> ReSam: no, cloud-init is not configured, there's an open bug for that
<ReSam> mhm - but it prints some message that it passes "log_host=<my-maas-host-ip>" as parameter during commission...
<roaksoax> ReSam: yeah, but cloud-init doesn't take the kernel parameters for that
<mup> Bug #1561222 opened: [UI 2.0a3] Event's table spacing is incorrect <MAAS:Triaged> <https://launchpad.net/bugs/1561222>
<roaksoax> ReSam: in : /etc/maas/templates/commissioning-user-data/user_data_config.template do:
<roaksoax> ReSam: add at the bottom: http://pastebin.ubuntu.com/15483272/
<roaksoax> ReSam: that should give you rsyslog
<ReSam> roaksoax: thanks, I will try it.
<LiftedKilt> how do you delete ip ranges in maas 2.0?
<LiftedKilt> I can create reserved and dynamic ranges, and I can read them, but there's no cli option for deletion
<mpontillo> LiftedKilt: maas <profile> iprange delete <iprange-id>
<LiftedKilt> mpontillo: I'm just seeing that now - why the difference between the iprange and the ipranges commands?
<mpontillo> LiftedKilt: it's consistent with the other APIs; there is a plural endpoint for creation and listing, and a singular endpoint for doing something with an individual object
<LiftedKilt> mpontillo: ok cool. Good to know - thanks!
<mpontillo> LiftedKilt: do "maas <profile> --help" to see what I mean - there are basically two endpoints for each object
<mpontillo> np
<roaksoax> ReSam: did that work ?
<ReSam> roaksoax: sry - other things need to be fixed first... I will report back tomorrow. thx.
#maas 2016-03-24
<mup> Bug #1561259 opened: test_xinstallable_returns_false_when_missing_filetypes fails 33% of the time <MAAS:New> <https://launchpad.net/bugs/1561259>
<ReSam> how can I overwrite the MAAS url during commissioning? I can see that it tries to send the results to the wrong IP (looks like the default gateway), but my MAAS runs on a different machine
<mup> Bug #1561494 opened: [Xenial] a4 -  ARM64 nodes fail to restart during deployment causing them to fail <acpi> <arm64> <uefi> <MAAS:New> <https://launchpad.net/bugs/1561494>
<mup> Bug #1561494 changed: [Xenial] a4 -  ARM64 nodes fail to restart during deployment causing them to fail <acpi> <arm64> <uefi> <MAAS:New> <https://launchpad.net/bugs/1561494>
<mup> Bug #1561494 opened: [Xenial] a4 -  ARM64 nodes fail to restart during deployment causing them to fail <acpi> <arm64> <uefi> <MAAS:New> <https://launchpad.net/bugs/1561494>
<mup> Bug #1561597 opened: Clicking on multiple "Filter by" items should not make accumulative filters <ux> <MAAS:New> <https://launchpad.net/bugs/1561597>
<mup> Bug #1561597 changed: Clicking on multiple "Filter by" items should not make accumulative filters <ux> <MAAS:New> <https://launchpad.net/bugs/1561597>
<mup> Bug #1561597 opened: Clicking on multiple "Filter by" items should not make accumulative filters <ux> <MAAS:New> <https://launchpad.net/bugs/1561597>
<mup> Bug #1561659 opened: MAAS fails to deploy on a system with 4Kn (4096-byte native sector size) disk <MAAS:New> <MAAS 1.9:New> <https://launchpad.net/bugs/1561659>
<mup> Bug #1561688 opened: [2.0a3] adding DNS and Zones to settings subnav <design> <ui> <MAAS:New for blake-rouse> <https://launchpad.net/bugs/1561688>
<mup> Bug #1561733 opened: [2.0a3] MAAS no longer detects external DHCP servers <MAAS:Triaged> <https://launchpad.net/bugs/1561733>
<mup> Bug #1561733 changed: [2.0a3] MAAS no longer detects external DHCP servers <MAAS:Triaged> <https://launchpad.net/bugs/1561733>
<mup> Bug #1561733 opened: [2.0a3] MAAS no longer detects external DHCP servers <MAAS:Triaged> <https://launchpad.net/bugs/1561733>
<mup> Bug #1561780 opened: [2.0a3] UI subnet page displays '<' char in upper left <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1561780>
#maas 2016-03-25
<mup> Bug #1561816 opened: 2016-03-25 10:52:55 [RegionServer,6,127.0.0.1] Rack controller 'None' disconnected. <MAAS:New> <https://launchpad.net/bugs/1561816>
<mup> Bug #1561818 opened: Rack controller registered multiple times? <MAAS:New> <https://launchpad.net/bugs/1561818>
<mup> Bug #1561991 opened: [2.0a4] Doesn't use modify over the OMAPI <dhcp> <MAAS:Triaged> <https://launchpad.net/bugs/1561991>
<mup> Bug #1561954 opened: Ubuntu Server install menu needs a 16.04 refresh <MAAS:New> <Ubuntu CD Images:New> <gfxboot-theme-ubuntu (Ubuntu):New> <https://launchpad.net/bugs/1561954>
<mup> Bug #1562013 opened: "Install MAAS region controller" should be available in 16.04  <MAAS:New> <https://launchpad.net/bugs/1562013>
<mup> Bug #1562034 opened: MAAS packaging summary and description needs to be updated for 16.04 <MAAS:New> <https://launchpad.net/bugs/1562034>
<mup> Bug #1562036 opened: maas-cli package needs an updated homepage <MAAS:New> <https://launchpad.net/bugs/1562036>
<mup> Bug #1562062 opened: maas-rack-controller package needs updated description <MAAS:New> <https://launchpad.net/bugs/1562062>
<mup> Bug #1562069 opened: maas-region-controller-min package should be renamed to maas-region-api <MAAS:New> <https://launchpad.net/bugs/1562069>
<mup> Bug #1562106 opened: [2.0a4]  Can't assign a 'Static IP' Address <MAAS:Triaged> <https://launchpad.net/bugs/1562106>
<mup> Bug #1562107 opened: [2.0a4] No feedback when failing to assign static IP address on the Node Details Page <MAAS:Confirmed> <MAAS 1.9:Confirmed> <https://launchpad.net/bugs/1562107>
<mup> Bug #1561818 changed: Rack controller registered multiple times? <MAAS:New> <https://launchpad.net/bugs/1561818>
<mup> Bug #1562126 opened: maas-enlist should be part of the maas-cli package if needed <MAAS:New> <https://launchpad.net/bugs/1562126>
<mup> Bug #1562142 opened: maas assigns wrong address if node is deleted and then re-deployed <MAAS:New> <https://launchpad.net/bugs/1562142>
<mup> Bug #1499934 changed: Power State could not be queried (vmware) <MAAS:Fix Released> <MAAS 1.10:Fix Released by mpontillo> <MAAS 1.9:Incomplete by mpontillo> <https://launchpad.net/bugs/1499934>
<mup> Bug #1562198 opened: [2.0a4] When providng DHCP a smarter default dynamic range is needed <MAAS:Triaged> <https://launchpad.net/bugs/1562198>
<mup> Bug #1562202 opened: [2.0a4] page-header__feedback should not impose width: 100% <ui> <MAAS:Triaged by ricgard> <https://launchpad.net/bugs/1562202>
#maas 2016-03-26
<mup> Bug #1562214 opened: [2.0a4] When a service is not running, rack controller shows as disconnected <MAAS:Confirmed> <https://launchpad.net/bugs/1562214>
<mup> Bug #1562226 opened: MAAS assigns the same IP address to multiple servers <MAAS:New> <https://launchpad.net/bugs/1562226>
<mup> Bug #1439831 changed: Missing lshw breaks cloudinit <MAAS:Expired> <https://launchpad.net/bugs/1439831>
<mup> Bug #1483303 changed: releasing failed <MAAS:Expired> <https://launchpad.net/bugs/1483303>
#maas 2017-03-20
<jianghuaw_> it looks like MAAS can't support VMs on XenServer: Enlistment failed due to cloud-init can find data source;
<jianghuaw_> And with manually adding machines, it failed at commissioning.
<ybaumy> jianghuaw_: i had that too with the datasource. it was a problem that it couldnt logon to the iscsi source. the reason for me was network problems. once they were solved it worked
<jianghuaw_> ybaumy, that's useful input. I've not checked further. Will look into if it's the same issue. Thanks.
<jianghuaw_> ybaumy, could you share more about the issue you met? It looks there is no way to login the failed VM.
<ybaumy> jianghuaw_: somehow it was working when i installed another rack controller for that network i was trying to install the node in
<jianghuaw_> But the cloud-config-url is really referred to the IP belong to another network.
<jianghuaw_> e.g. the VM got IP from MAAS DHCP as 10.14.0.3; maas has two interfaces: eth0: 10.14.0.1; an the other is connected to public network.
<jianghuaw_> From the VM's console, it has iscsi_target_ip=10.14.0.1 but the cloud-config-usl=http://<the MAAS' ip belong to the public network>.
<jianghuaw_> Is it the problem? as the VM is impossible to add the public network @ybaumy
<jianghuaw_> s/cloud-config-usl/cloud-config-url/
<ybaumy> jianghuaw_: make sure that the network has internet access or access to a apt proxy
<ybaumy> jianghuaw_: if 10.14.0.0/24 has no internet access then you must use a apt proxy
<jianghuaw_> yes, 10.14.0.0/24 has no internet access.
<ybaumy> jianghuaw_: i didnt setup a apt proxy .. i enabled access on the firewall for my networks i use for ports 80/443
<jianghuaw_> ok. So iptables may help at here.
<ybaumy> jianghuaw_: if your firewall is iptables yes. im using a cisco asa
<jianghuaw_> I caught an issue that: disk/by-patch/ip-10.14.0.1:xxxxx-lun-1": Invalid path for Logical Volume.
<ybaumy> jianghuaw_: dont know about that
<jianghuaw_> Does MAAS support to download squashfs via tftp?
<jianghuaw_> ybaumy, I created multiple VMs. Now I shutdown all of the other VMs and only kept one VM. The cloud-init finished successfully. Commissioning passed also:-)
<mup> Bug #1674127 changed: delete_authorisation_token is a POST <MAAS:Invalid> <https://launchpad.net/bugs/1674127>
<mup> Bug #1674127 opened: delete_authorisation_token is a POST <MAAS:Invalid> <https://launchpad.net/bugs/1674127>
<jianghuaw_> ybaumy, actually it should be fixed due the router setup change.
<ybaumy> jianghuaw_: thats what i thought
<jianghuaw_> yes, thanks for the hint.
<ybaumy> jianghuaw_: glad that i could help
<mup> Bug #1674127 changed: delete_authorisation_token is a POST <MAAS:Invalid> <https://launchpad.net/bugs/1674127>
<BlackDex> Hello there
<BlackDex> When i deploy a system, after it is done i get the message "Booting local disk...." "WARN: No MBR magic, treating disk as raw"
<BlackDex> And then it hangs
<cnf> morning!
<pmatulis> morning
<cnf> anyone have the MAAS cli only installed on a system?
<cnf> so it seems maas doesn't bring up my interfaces properly... sometimes?
<cnf> hmm, yeah
<cnf> maas randomly doesn't bring up some interfaces o,O
<cnf> roaksoax: where you helping with that last week?
<cnf> i don't recall exactly
<cnf> or maybe it was jamespage ?
<pmatulis> cnf, specific symptoms?
<cnf> pmatulis: it's vlan's, if i ssh to it, and do an ifdown enp3s0f0 and then ifup enp3s0f0 all the vlans come uo
<cnf> they are in /etc/network/interfaces
<cnf> but sometimes, they don't come up
<pmatulis> cnf, maybe there is something non-optimal about the existing config (/e/n/i). do you know if that's the case? trying to isolate ubuntu-specific problem from a maas problem
<pmatulis> pastebin an example config maybe
<cnf> pmatulis: it looks sane
<cnf> pmatulis: https://bpaste.net/show/4ff14160e0d0
<mup> Bug #1674407 opened: [2.2] Spurious error in UI after installing power management dependencies <MAAS:New> <https://launchpad.net/bugs/1674407>
<pmatulis> cnf, i don't have anything to add. hopefully someone else does
<pmatulis> but at least we have better info to provide them now
<cnf> k, thanks anyway
<pmatulis> cnf, did you check logs? seem the node logs should contain something
<cnf> pmatulis: yeah, nothing that i can see that would explain this
#maas 2017-03-21
<mup> Bug #1671407 opened: Creation of kvm machine with large root-disk fails <4010> <juju:Incomplete> <juju 2.1:Won't Fix> <MAAS:New> <https://launchpad.net/bugs/1671407>
<mup> Bug #1674148 opened: hook for storage: storage already attached - Juju using already mounted disk <juju:Incomplete> <MAAS:New> <https://launchpad.net/bugs/1674148>
<mup> Bug #1674148 changed: hook for storage: storage already attached - Juju using already mounted disk <juju:Incomplete> <MAAS:New> <https://launchpad.net/bugs/1674148>
<mup> Bug #1674148 opened: hook for storage: storage already attached - Juju using already mounted disk <juju:Incomplete> <MAAS:New> <https://launchpad.net/bugs/1674148>
<lalit> join
<lalit> hello experts
<lalit> I have conbfigured maas server . when nodes boot up with maas pxe i am getting exception "raise DataSourceNotFoundException"
<lalit> above exception is from cloudinit script
<mup> Bug #1657375 changed: RFE: DNS and DHCP <MAAS:Expired> <https://launchpad.net/bugs/1657375>
<Guest9012> Did anyone had luck with installing CentOS 7 on a node using MAAS 2.1.3 version?
<Guest9012> I am running into issue https://bugs.launchpad.net/maas/+bug/1658718?comments=all
<cnf> morning
<cnf> also, wow...
<cnf> https://bugs.launchpad.net/maas/+bug/1631908 2016-10-10
<cnf> i'm screwd
<Guest84817> did anyone run into issues listed in bug https://bugs.launchpad.net/maas/+bug/1658718?comments=all?
<Guest84817> it is related to CentOS installation via MAAS 2.1.3
<cnf> hmm
<cnf> hmm...
<cnf> jamespage, roaksoax i think i might have found why my vlans are not coming up
<cnf> jamespage: ah, and it seems you already know about it :P
<jamespage> cnf: ?
<cnf> https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1565804
<cnf> and https://bugs.launchpad.net/maas/+bug/1543195
<cnf> jamespage: i had large MTU set on vlan interfaces
<cnf> and MAAS isn't setting the corresponding MTU on the base interface
<jamespage> cnf: that rings a bell somewhere - reading the bug I do seem to remember something about that
<jamespage> cnf: I thought MAAS would not let you do the wrong thing these days.
<cnf> :P
<cnf> it seems it does
<cnf> do you remember the fix?
<jamespage> cnf: reading the bug reports I though this was fixed in the vlan package
<jamespage> "If VLAN is configured with higher MTU than raw device MTU, which can
<jamespage>     happen if VLAN is ifup'ed before raw device, then increase raw device
<jamespage>     MTU first so the VLAN ifup does not fail."
<cnf> hmm
<jamespage> cnf: how did you set the mtu's up in MAAS?
<cnf> on the vlan
<cnf> is there a different place?
<cnf> hmm
<cnf> jamespage: so if i ifdown / ifup the base interface, my vlans do come up
<jamespage> cnf: digging
<jamespage> https://bugs.launchpad.net/maas/+bug/1543195
<jianghuaw_> Hi, anyone know how to customize the maas images? I want to pre-install guest tools in the image. Thanks.
<cnf> jianghuaw_: use commissioning scripts?
<cnf> jamespage: i just linked you that one :P
<jamespage> cnf: so you did (only noted the first)
<jianghuaw_> cnf, thanks. Will try.
<jamespage> cnf: have you set the mtu on the 'default' vlan as described in that bug report?
<cnf> jamespage: thing is, i have no default vlan
<cnf> hmm, i guess i can set the untagged one...
<cnf> because maas is weird that way
<cnf> jamespage: let me try that
<jamespage> cnf: well every port has untagged traffic  - try that
<cnf> well, our switches don't allow untagged on trunks
<cnf> but yeah, i made a vlan 0 (untagged) vlan, which has no subnets
<cnf> i'm setting MTU on that
<jamespage> cnf: +1
<cnf> jamespage: now to wait 20 minuted for redeploy :P
<cnf> jamespage: stuff like this should be documented ^^;
<cnf> if it is this, i just spend 2 days finding why things where not working >,<
<jamespage> roaksoax, mpontillo: what is the maas story for MTU management these days - I've not used it since 1.9 where the above but was reported originally
<jamespage> roaksoax, mpontillo: I thought that was going to be managed at the fabric level, and automatically propagated to network interfaces connected to a fabric
<jamespage> rather than being set on a individual VLAN level
<mpontillo> jamespage: agree that it would be good to have a default MTU on a fabric and/or vlan that would automatically propagate to interfaces configured on said fabric/vlan
<mpontillo> jamespage: there may have been some discussion about that but I think only interface-level MTU made it so far
<cnf> that would make more sense :P
<cnf> or at least set the base device MTU high enough automatically
<cnf> you should not deploy configs that do not work :P
<mpontillo> cnf: jamespage: so to be clear, for this specific issue.. it sounds like there is a bug/wishlist item for MAAS in which we should, upon creating a VLAN, automatically adjust the MTU of the VLAN's parent to be +4 to account for the 802.1q tag. do I understand correctly?
 * mpontillo hasn't had coffee yet, sorry ;-)
<cnf> sounds good
<mpontillo> cnf: would you do me a favor and file this as a bug in MAAS, and include why the current behavior breaks you? https://bugs.launchpad.net/maas/+filebug
<jamespage> do switches define global mtu's or per port mtu's
<jamespage> or is the answer there 'it depends'
<jianghuaw_> cnf, may i ask another question?
<jianghuaw_> I'm deploying applications on 4 machines; but the last machine got stuck at allocating status. From MAAS, it's kept in deploying status. As I don't think it will proceed. So marked this machine as broken. the problem is it didn't allocate new machine. How can I proceed under this situation?
<mpontillo> lamont: ^ FYI and see also bug #1543195; I guess you already wrote some code for fabric-level MTU that I forgot about =)
<cnf> jianghuaw_: idno, release it?
<cnf> jamespage: it depends :P
<mpontillo> cnf: jianghuaw_: it's appropriate to mark broken if you don't think the machine will ever work again, but then I think you'd want to retry the deployment (I assume this is with juju?)
<cnf> jamespage: but maas seems to assume every port is configured the same, anyway
<jianghuaw_> cnf, anyway to make it allocate new machine and continue the application deployment?
<cnf> jamespage: can't chose the "default untagged" vlan per device, anyway
<jianghuaw_> mpontillo, yes, it's with juju.
<cnf> jianghuaw_: ah, i have no idea how to make juju recover from broken machines...
<cnf> if you figure that out, please please do let me know :P
<jianghuaw_> cnf, sure I will if I can:-)
<mpontillo> jamespage: I think MTU is a source of bugs for switch vendors too ;-) on the switches I've worked with I think it's per-VLAN
<jamespage> oh for a fully software defined datacenter
<cnf> mpontillo: https://bugs.launchpad.net/maas/+bug/1674658
<jamespage> thankyou cnf
<mpontillo> cnf: thanks much
<mpontillo> jianghuaw_: sounds like this may be a better question for #juju
<cnf> the "VLAN with ID 0 (not tag 0) is the default "untagged" traffic confused me as well
<mpontillo> jianghuaw_: once you mark the machine broken in MAAS you should be able to cancel and retry in juju; I just don't know the commands from the top of my mind
<mup> Bug #1674658 opened: setting larger MTU on vlan does not set MTU on base device <MAAS:Triaged> <https://launchpad.net/bugs/1674658>
<jianghuaw_> mpontillo, Thanks very much. Will ask in #juju.
<mpontillo> cnf: when we say "VID" that is an 802.1q tag, it should be the same.
<cnf> mpontillo: right, but you don't get to choose
<cnf> if you add an interface, the VLAN field is grayed out, and the original vlan in the fabric is selected
<cnf> only way to change that is rename them, because the 1st one is _always_ the default one
<cnf> (from what I can tell, anyway)
<Guest84817> looks like no one has tried with CentOS7 installation through MAAS :(
<mpontillo> cnf: ah, 0 is just the "default untagged", though arguably that is not very useful since the default tag can vary per-port. MAAS likes it better if the default VLAN is consistent throughout the fabric.
<brendand> Guest84817, we do test that
<Guest84817> anyone has any update for  https://bugs.launchpad.net/maas/+bug/1658718 ?
<cnf> mpontillo: 0 not as in the VLAN, but as in the ID to maas :P
<cnf> mpontillo: we don't use untagged traffic on trunk ports
<Guest84817> @brendand - I see issues reported in  https://bugs.launchpad.net/maas/+bug/1658718
<roaksoax> Guest84817: no there's no update for that. We are working on other issues at the moment
<mpontillo> cnf: to be honest I would like to move away from this concept entirely; I don't like the idea that there is a "dumping ground" object that may get polluted with things in which we don't know where they would otherwise go =)
<cnf> yeah
<Guest84817> roaksoax: I had tried with MAAS 2.0, 2.1.2 and 2.1.3
<Guest84817> all gave same errors
<brendand> Guest84817, what hardware are you using?
<mpontillo> cnf: the "we don't use untagged traffic on trunk ports" issue may deserve a bug, too, then; is a MAAS region/rack interface managing your network via a trunk port?
<Guest84817> brendand: Wiwynn servers
<cnf> mpontillo: so our machines are connected on 10G LAGs
<Guest84817> but I am sure it is not h/w related
<cnf> mpontillo: as I could not figure out how to PXE boot on LAG interfaces, i added a copper link just for MAAS / PXE
<Guest84817> seems to be something to do with curtin hooks configuration
<cnf> the LAGs only do tagged traffic
<Guest84817> within images
<mpontillo> cnf: yeah, that's a terrible workaround; I'd like to see this fixed
<cnf> yeah, i'd like to see that fixed as well :P
<mpontillo> cnf: what was the issue there? if you wouldn't mind filing another bug that would be nice
<cnf> no idea how to get PXE booting on LAG interfaces, though
<cnf> because there is no LACP link at boot time, obviously
<roaksoax> Guest84817: this is not a bug in MAAS, this is a bug in the image
<Guest84817> I believe I am using images officially supported by MAAS ... is this the right assumption?
<cnf> doesn't mean they can't contain bugs :P
<roaksoax> cmagina: are you sure it is not a firmware/grub issue ? we just recently got confirmation that PXE booting on 10gig interfaces isn't related to MAAS itself, but rather grub & firmware
<roaksoax> err
<roaksoax> cmagina: sorry
<roaksoax> cnf: ^^\
<cnf> roaksoax: i can PXE on 10G
<cnf> roaksoax: i can't PXE on LACP links
<roaksoax> Guest84817: they are officially supported. But that doesn't necessarily mean we have all the hardware available out there ot test this image against. We only CI against the hardware we currently have available
<mpontillo> cnf: yeah you might be stuck with copper then, probably more reliable anyway
<cmagina> np
<cnf> roaksoax: this might also be a problem with the juniper qfabrics, i don't know
<roaksoax> cnf: gotcha!
<cnf> not even sure if this should / could work, tbh
<Guest84817> roaksoax: Looking at the error, it doesn't look like a h/w issue
<cnf> mpontillo: it is quite annoying, we are not really set up for copper :P
<Guest84817> or related to drivers
<cnf> mpontillo: iLo links are on a separate network, and most of those are on 100mbps :P
<cnf> the rest is all fiber
<mpontillo> cnf: I was just talking to someone yesterday who was doing something similar; their management interface for IPMI was able to be used also as the PXE interface; seemed like a clean solution. (but 100mbps is sad; it's the new millennium!) ;-)
<cnf> well, it's just IPMI
<cnf> it's all old copper switched
<cnf> we really don't have a lot of copper around
<cnf> my 6 copper links filled up the switch
<cnf> for the PXE booting
<roaksoax> Guest84817: it is not a hardware issue. it is a EFI issue
<mpontillo> cnf: right, I guess some newer servers will let you use an internal switch connected to the BMC to do PXE booting /and/ IPMI, the PXE-boot-over-LAG issue being somewhat known in the industry I suspect
<cnf> fiber, i can ask as many as i want
<cnf> mpontillo: you can also put IPMI on your "normal" nic
<cnf> HP and dell let you do that
<cnf> i'm sure others do as well
<mpontillo> cnf: that might boost you up from 100 megabits too =)
<Guest84817> roaksoax: if you have detailed insight, can you please elaborate on what exactly is the issue?
<cnf> mpontillo: no, because the IPMI network is only 100mbps :P
<cnf> mpontillo: strange, i know, but ipmi here is 100mpbs everywhere
<cnf> mpontillo: everything else is  2 x 10G fiber LACP
<cnf> or 2 x 40G LACP if need be
<cnf> hardly any 1G copper around
<mpontillo> cnf: right. okay, thanks for the discussion and for the bug reports - I've got to step out for a bit
 * mpontillo -> {coffee, breakfast}
<cnf> \o thanks for the help
<roaksoax> Guest84817: i dont have detailed insight, but there's a bug installing centos on machines with EFI. Machines in Legacy mode will work just fine
<roaksoax> Guest84817: unfortauntely, we have not had the time to fix it
<Guest84817> roaksoax: so is there a workaround of how I can instruct MAAS to install via legacy mode for a specific host?
<brendand> Guest84817, ask ipmi to tell it to
<brendand> oh but you mean via maas
<roaksoax> Guest84817: no, MAAS is currently agnostic as to what you boot (whether EFI/Legacy). You can change the BIOS settings and recommission the machine
<roaksoax> and you should be able to deploy
<Guest84817> brendand: yes, I believe MAAS is trying to go with EFI mode, so I will need to configure in MAAS for legacy mode
<roaksoax> Guest84817: you can reconfigure the BIOS via IPMI as well
<cnf> btw
<cnf> is there a way to install the MAAS cli stand alone?
<cnf> preferably not on ubuntu :P
<Guest84817> roaksoax: brendand: thanks for the details. Will give it a try
<Guest84817> in case if you have any updates on the bug that would be great
<Guest84817> do you have a roadmap for the bug resolution?
<roaksoax> Guest84817: it is on the bug list atm
<roaksoax> cnf: only uspport in ubuntu atm
<roaksoax> cnf: sudo apt-get install maas-cli
<cnf> hmm, bummer
<cnf> roaksoax: what is it written in?
<roaksoax> cnf: python
<cnf> hmm, and no pip package?
<roaksoax> cnf: no the cli
<roaksoax> cnf: libmaas is, but libmaas is alpha at the moment
<roaksoax> and does not cover everything
<roaksoax> nor all releases
<cnf> hmm
<cnf> i'd really like the maas cli available on my mac
<brendand> cnf, container?
<cnf> brendand: yeah, but that's still a bit of a pain
<cnf> brendand: it's probably what i'll do for now, though
<cnf> but a brew install maas-cli would be awesome :P
<brendand> cnf, that will probably never happen - libmaas in python is the priority
<roaksoax> cnf: the new cli will probbaly be
<cnf> roaksoax: nice
<cnf> juju is in homebrew
<roaksoax> the new cli is being built on top of libmaas
<cnf> ah, nice
<roaksoax> cnf: http://maas.github.io/python-libmaas/
<cnf> running pip install python-libmaas :P
<roaksoax> its on baby steps bte
<roaksoax> btw
<roaksoax> :)
<cnf> sure, i saw the ALPHA disclaimer :P
<brendand> cnf, you're welcome to contribute and add what you need :)
<cnf> <3 virtualenvwrapper
<brendand> cnf, hint: http://paste.ubuntu.com/24221349/
<cnf> $ maas list --all
<cnf> works :P
<brendand> cnf, just bear in mind that the api is very limited atm
<cnf> roaksoax: so add a "most seems to work, so far, for libmaas cli, on OSX sierra
<cnf> yeah
<mup> Bug #1671407 changed: Creation of kvm machine with large root-disk fails <4010> <juju:Incomplete> <juju 2.1:Won't Fix> <MAAS:Invalid> <https://launchpad.net/bugs/1671407>
<roaksoax> cnf: cool
<cnf> ok, i think maas is up, for now
<cnf> back to juju :P
<cnf> sheesh!
<cnf> back here :(
<cnf> https://bpaste.net/show/1c001024308b is what maas made of my network config this time
<cnf> o,O
<roaksoax> cnf: yeah juju creates the bridges
<roaksoax> cnf: to put containers/kvms
<cnf> hmm, and then it tells me it doesn't have the right ip's
<cnf> this shit is really frustrsting
<zeestrat> Hey, was there CLI command to skip the whole "Intro" thing on a fresh MAAS install?
<pmatulis> zeestrat, yup
<pmatulis> but iirc, it only suppresses the first stage (there are two). someone should file a bug on it
<pmatulis> maas $PROFILE maas set-config name=completed_intro=true
<pmatulis> ^^^ this means it is completed
<zeestrat> pmatulis: Thanks. I'll see how that works out and perhaps file a bug.
<pmatulis> zeestrat, thanks a lot. i usually track the maas bugs but if you can remember to ping me that would be great
<pmatulis> https://github.com/CanonicalLtd/maas-docs/issues/364
<pmatulis> zeestrat, ^^^
<zeestrat> pmatulis: cheers
<zeestrat> pmatulis: Just to make sure I'm not screwing up, are you sure the command is "maas $profile maas set-config name=completed_intro=true" and not "maas $profile maas set-config name=completed_intro value=true"?
<pmatulis> zeestrat, you can try it
<zeestrat> pmatulis: The latter is the only one that works for me on MAAS 2.1.4
<pmatulis> then verify with
<pmatulis> maas $PROFILE maas get-config name=completed_intro
<zeestrat> "maas $profile maas set-config name=completed_intro=true" just returns "No provided value!" and does not set it.
<pmatulis> zeestrat, your syntax is good then and makes sense according to
<pmatulis> maas $PROFILE maas set-config -h
<pmatulis> :param name: The name of the config item to be set.
<pmatulis> :param value: The value of the config item to be set.
<pmatulis> lemme change my doc bug
<mup> Bug #1674714 opened: [CLI] create subnet with space does not work when referring to space by name <MAAS:New> <https://launchpad.net/bugs/1674714>
<mup> Bug #1674720 opened: metadataserver: NodeKey matching query does not exist <MAAS:New> <https://launchpad.net/bugs/1674720>
<mup> Bug #1674714 changed: [CLI] create subnet with space does not work when referring to space by name <MAAS:New> <https://launchpad.net/bugs/1674714>
<mup> Bug #1674720 changed: metadataserver: NodeKey matching query does not exist <MAAS:New> <https://launchpad.net/bugs/1674720>
<mup> Bug #1673987 changed: [2.2 beta3]  Servers are failing to deploy - Times out after PXE installation - cloud-init[1563]: Can not apply stage final, no datasource found! Likely bad things to come! <cdo-qa-blocker> <oil> <curtin:New> <MAAS:Triaged> <https://launchpad.net/bugs/1673987>
<mup> Bug #1674030 changed: [2.2] AttributeError: 'tuple' object has no attribute 'subnet_id' <MAAS:Triaged> <https://launchpad.net/bugs/1674030>
<mup> Bug #1674714 opened: [CLI] create subnet with space does not work when referring to space by name <MAAS:New> <https://launchpad.net/bugs/1674714>
<mup> Bug #1674720 opened: metadataserver: NodeKey matching query does not exist <MAAS:New> <https://launchpad.net/bugs/1674720>
<ThiagoCMC> Hey guys, I'm playing with "maas-2.2.0~beta3+bzr5815-0ubuntu1~16.04.1" and I'm seeing a problem here... If I change the DNS for a PXE subnet, and reboot the bare-metal server, it doesn't see the new DNS server.
<ThiagoCMC> Any tips?
<ThiagoCMC> Under "Subnet summary", both "DNS" and "Gateway IP" changes have no effect.
<ThiagoCMC> Since the gateway ip was wrong, instead, I changed it on /etc/network/interfaces instead, so now at least, the gateway ip matches what it shows on subnet summary, however, things are a bit different for DNS...
<brendand> ThiagoCMC, just rebooting the machine would not reflect any changes in maas
<brendand> ThiagoCMC, you would have to recommission/deploy
<ThiagoCMC> Ouch!
<ThiagoCMC> I'll try that...
<BlackDex> Hello there, I have a big issue with maas atm
<BlackDex> when i deploy a system it doesn't seem to get out of the deploying state
<BlackDex> it seems the system starts correctly, but in the end it keeps running the deployment status, and after a while it will go to failed
<BlackDex> It looks like it starts oke, it even gets the correct network settings
<BlackDex> what could be the issue?
<BlackDex> i do not see anything in the maas logs
<BlackDex> or what ever
<brendand> BlackDex, did you check the syslog under /var/log/maas/rsyslog?
<BlackDex> brendand: Yes
<BlackDex> it all seems oke
<BlackDex> after the deployment it reboots
<BlackDex> and that seems to go fine
<BlackDex> but it never reports back
<BlackDex> i also can ping the IP('s)
<BlackDex> but can't connect to it via ssh
<BlackDex> while during comission mode, i can connect with ssh
<pmatulis> BlackDex, what is the nature of the node's underlying machine?
<mup> Bug #1673987 opened: [2.2 beta3]  Servers are failing to deploy - Times out after PXE installation - cloud-init[1563]: Can not apply stage final, no datasource found! Likely bad things to come! <cdo-qa-blocker> <oil> <curtin:New> <MAAS:Triaged> <https://launchpad.net/bugs/1673987>
<mup> Bug #1674030 opened: [2.2] AttributeError: 'tuple' object has no attribute 'subnet_id' <MAAS:Triaged> <https://launchpad.net/bugs/1674030>
<BlackDex> the nature? of the underluing machine?
<BlackDex> i don't really understand that question
<pmatulis> is it a bare metal HP machine? a KVM guest? a vmware system?
<BlackDex> ah
<BlackDex> bare-metal :)
<BlackDex> Dell R630
<pmatulis> what BMC did you choose for that?
<pmatulis> (power type)
<BlackDex> using IPMI LAN_@
<BlackDex> LAN_2
<BlackDex> But i have the same with all systems in the setup
<BlackDex> except for a KVM instance
<pmatulis> oh, and the others work fine?
<BlackDex> which is on the same machine as maas is installed on
<BlackDex> all systems fail
<BlackDex> i use maas a lot
<BlackDex> but i never have seen this
<pmatulis> i'm wondering if there's a more suitable power type for these Dell machines
<pmatulis> did you try any other?
<BlackDex> it does boot
<BlackDex> it powers the systems on
<BlackDex> and off
<BlackDex> so that seems to work
<BlackDex> only the last part of telling maas it is finished doesn't work, and it seems that ssh isn't running etc..
<mup> Bug #1673987 changed: [2.2 beta3]  Servers are failing to deploy - Times out after PXE installation - cloud-init[1563]: Can not apply stage final, no datasource found! Likely bad things to come! <cdo-qa-blocker> <oil> <curtin:New> <MAAS:Triaged> <https://launchpad.net/bugs/1673987>
<mup> Bug #1674030 changed: [2.2] AttributeError: 'tuple' object has no attribute 'subnet_id' <MAAS:Triaged> <https://launchpad.net/bugs/1674030>
<brendand> BlackDex, if it's got that far there should be a syslog, and it should have enough detail to tell why it's going wrong
<brendand> BlackDex, get the hostname of the machine and look in /var/log/rsyslog/<hostname>/<date>/messages
<BlackDex> i know
<BlackDex> and all there is that the installation went fine
<BlackDex> and it is going to reboot for the last time
<BlackDex> after that, there is no syslog
<BlackDex> because it isn't pxe booted
<BlackDex> and the system doesn't report syslog after deployment
<BlackDex> Mar 21 15:44:17 openstack7 cloud-init[3769]: curtin: Installation finished.
<BlackDex> there are no errors except for lvm not found etc..
<BlackDex> also, the network the systems are one is a private one, nothing in between but a single switch
<BlackDex> i'm going to try 14.04, see if that helps
<pmatulis> 14.04?
<BlackDex> Ubuntu 14.0
<BlackDex> 14.04 LTS as a deployment image
<BlackDex> but that failed also
<mup> Bug #1606999 changed: reporting messages can slow down operations greatly <MAAS:Confirmed> <https://launchpad.net/bugs/1606999>
<BlackDex> lets see if a normal iso install will work
<mup> Bug #1674747 opened: [2.1] Cannot sync with an upstream NTP server with stratum=9 or larger <MAAS:New> <https://launchpad.net/bugs/1674747>
<BlackDex> brendand pmatulis, you never guess the problem. Apperently the MTU size was giving problems
<BlackDex> that is something probably set only at the final stage, so that causes no problems during the deployment
<BlackDex> it also figures why the kvm-instance worked, as that is on the same server, and no switch in between
<BlackDex> thx for the help :)
<kklimonda> are there plans for MAAS to provide CA?
<pmatulis> BlackDex, wow ok! welcome
<roaksoax> kklimonda: CA ?
<kklimonda> roaksoax: certificate authority
<stokachu> kklimonda: why would it?
<roaksoax> kklimonda: not in the short term
<roaksoax> if you want https, you'll need to put say, haproxy in fron
<kklimonda> stokachu: for example to configure your local CA on all nodes, or perhaps to have per-node client certificate.
<kklimonda> stokachu: I hit it when I was trying to make lxd deploy in an environment where internet connection was spotty
<kklimonda> with juju, it was trying to connect to https://streams.canonical.com/ and this is hardcoded
<kklimonda> I needed a certificate trusted by lxd/juju for that mirror, and I've ended up installing it with late_commands
<kklimonda> but for example kubernetes cluster requires a CA too
<fabi> hi @ll
<fabi> quick question: I followed all the steps here: https://docs.ubuntu.com/maas/2.1/en/manage-backup but for some reason I can't restore my backup on another machine failing with some kind of django error message "django.core.exceptions.ImproperlyConfigured: settings.DATABASES is improperly configured. Please supply the ENGINE value. Check settings documentation for more details."
<pmatulis> fabi, i suggest opening a bug
<pmatulis> https://bugs.launchpad.net/maas/+filebug
<mup> Bug #1674788 opened: machine allocation on a (virsh) pod fails: frozenset does not support indexing <MAAS:New> <https://launchpad.net/bugs/1674788>
<pmatulis> roaksoax, can we get the topic to point to the mailman list?
<fabi> pmautils, thanks will investigate and do!
<mup> Bug #1674807 opened: View the default-gateway set for a node <MAAS:New> <https://launchpad.net/bugs/1674807>
<mup> Bug # changed: 1588350, 1623751, 1669567, 1673377
<mup> Bug #1674818 opened: [2.2] on the device details page, add interface and edit interface forms are inconsistent <MAAS:Triaged> <https://launchpad.net/bugs/1674818>
<mup> Bug #1214172 changed: juju/MAAS Tag constraints do not work in Precise <maas (Ubuntu):Won't Fix> <https://launchpad.net/bugs/1214172>
<maticue_> Hi everyone! We're implementing MAAS region controller + MAAS rack controller. First question is: Is there any limit on the how many MAAS rack controller can be managed by a MAAS region controller?
<maticue_> My second question is. I'd like to manage the DNS service using mass-cli. I could create domains, and registers.. everything goes well. However I see a really limited set of option when I create a new DNS domain. For example, they always are "master" and I can't declare using mass-cli a DNS slave. Is there any workaround for this?
<roaksoax> maticue_: no limit, but we have not tested against hundreds of then. Maximum we've tested is about 15
<maticue_> roaksoax: thanks!! and, do you know who I could resolve dns custom configuration? or at least who can answer that question?
<roaksoax> lamont: ^^
<lamont> ah, this #maas.
 * lamont was quite confused
<lamont> maticue_: the maas region will always be the master (in its own mind at least) of any dns domain/zone for which it is told to be authoritative.
<lamont> adding a secondary that slaves from the region controller is trivial: just add the NS RR via dnsresource-records
<lamont> maas SESSION dnsresource-records create name=@ domain=$DOMAIN rrtype=ns rrdata=${NSHOST}.
<lamont> maticue_: what exactly are you trying to do with the DNS?  (most of what you might want to do with delegation is very doable)
<maticue_> lamont: great! Now I can see it. However, my idea is to have an authoritative DNS server different than MAAS DNS server, near rack controller. However, I want my MAAS DNS server contains all domains and registers and manage them using the maas-cli . Not sure if I'm clear
<lamont> the part that we don't let you have control over: every domain/zone for which maas is authoritative _will_ have the region controller listed as an NS RR.  (See also launchpad.net/bugs/1672220 -- oops).  You can certainly deploy (via maas or "oldschool") an additional NS closer to the rack, add that NS RR to the RRset (for each and every domain you care about...) and thne configure named.conf on
<lamont> the slave to pull from (at least) the maas region
<lamont> n.b. to simplify things, maas DNS zones are (cough, pay no attention to SRV, cough) limited to labels that contain no dots.  That is, each DNS zone is exactly one domain deep.
<lamont> maticue_: there isn't a way for the maas regiond to get told to edit a DNS zone other than those for which it is the master.  (the update changes the maas db, and then the zone file is generated from the db.)
<lamont> what I generally do is give the maas server a real honest to goodness domain (maas.example.com), and then add NS RRs for maas.example.com. to the example.com. zone upstream.  I also tell maas to use an upstream resolver.
<lamont> at that point, since maas has nothing to do with the upstream resolver config, I just make BIND do what it needs to do to make everything happy
<lamont> and I suppose that could be done with split-dns, or even in isolation.
<lamont> does that help?
<lamont> where I was a bit fuzzy there is that "authoritative" does not clearly indicate master/slave status for the zone
<lamont> host other than maas-region as authoritative secondary? trivial.  host other tham maas-region as authoritative-master? only if the maas-region isn't authoritative for the DNS zone.
 * lamont forsees a blog post in his near future
<maticue_> lamont: that is an excellent information. You give me a lot of reasons to think about. I'm pointing to "host other than maas-region as authoritative secondary"
<lamont> that's the dnsresource-records create above, and configure the secondary to grab from the regiond
 * lamont has been maintaining bind for way too long
<maticue_> great, I'll test in that way. thank you so much!
<maticue_> lamont++
<lamont> happy to help
<lamont> maticue_: http://voices.canonical.com/lamont.jones/2017/03/21/adding-a-secondary-name-server-for-a-domain-in-maas/
#maas 2017-03-22
<mup> Bug #1674864 opened: MAAS deployment failed due to data source user-data 500 Internal Server Error, after using set default gateway <MAAS:New> <https://launchpad.net/bugs/1674864>
<mup> Bug #1674864 changed: MAAS deployment failed due to data source user-data 500 Internal Server Error, after using set default gateway <MAAS:New> <https://launchpad.net/bugs/1674864>
<mup> Bug #1674866 opened: Default gateway (per-subnet) should have a metric value <MAAS:New> <https://launchpad.net/bugs/1674866>
<Tim_> Hello
<bryanb229> is there anyone active in this channel?
<bryanb229> ive logged in multiple time and see people online but no one ever types any messages
<brendand> bryanb229, it's active
<brendand> some times are quieter than others
<mup> Bug #1674959 opened: [UI] Close Add Pod button is redundant on pods page <MAAS:New> <https://launchpad.net/bugs/1674959>
<mup> Bug #1674959 changed: [UI] Close Add Pod button is redundant on pods page <ui> <ux> <MAAS:Opinion> <https://launchpad.net/bugs/1674959>
<mup> Bug #1674959 opened: [UI] Close Add Pod button is redundant on pods page <ui> <ux> <MAAS:Opinion> <https://launchpad.net/bugs/1674959>
<mup> Bug #1674959 changed: [UI] Close Add Pod button is redundant on pods page <ui> <ux> <MAAS:Opinion> <https://launchpad.net/bugs/1674959>
<mup> Bug #1674991 opened: [2.1] Cannot skip 2nd stage of intro config journey <MAAS:Incomplete> <https://launchpad.net/bugs/1674991>
<mup> Bug #1674991 changed: [2.1] Cannot skip 2nd stage of intro config journey <MAAS:Incomplete> <https://launchpad.net/bugs/1674991>
<mup> Bug #1675017 opened: [CLI] interface link-subnet command cannot refer to interface by device name <MAAS:New> <https://launchpad.net/bugs/1675017>
<mup> Bug #1675017 changed: [CLI] interface link-subnet command cannot refer to interface by device name <MAAS:New> <https://launchpad.net/bugs/1675017>
<mup> Bug #1675017 opened: [CLI] interface link-subnet command cannot refer to interface by device name <MAAS:New> <https://launchpad.net/bugs/1675017>
<mup> Bug #1670499 changed: maas 2.1.3 nodes do not deploy, Juju reports 'started but not deployed' <cdo-qa> <cdo-qa-blocker> <juju:Invalid> <MAAS:Incomplete> <https://launchpad.net/bugs/1670499>
<mup> Bug #1671605 changed: Unbootable system after installation <cdo-qa-blocker> <curtin:Invalid> <MAAS:Incomplete> <https://launchpad.net/bugs/1671605>
<mup> Bug #1673726 changed: scsi ids with vmware are not correctly used <MAAS:Incomplete> <https://launchpad.net/bugs/1673726>
<dfin> Hello all, is there a way to debug the commissioning process in 2.1? I've been stuck for a couple days and about to call it quits :/
<pmatulis> dfin, logs are a good place to start
<dfin> Right, but I can't log in to the commissioned machine and I couldn't get the backdoor hack to work
<dfin> Specifcially, I can see in the MAAS logs that the initial PXE is going well, but the node  I'm trying to provision just sits there at a login prompt
<pmatulis> dfin, and the web UI says 'Commissioning failed'?
<dfin> yes, after it hits the 20 min timout
<pmatulis> dfin, what kind of machine is powering the node? bare-metal, virtual
<dfin> BM - Dell 6730xd
<dfin> *r730
<dfin> MAAS itself is in a VMware cluster on the same vlan
<pmatulis> dfin, what power type was chosen?
<dfin> IPMI 2, which is working
<dfin> At least, it powers on the machine
<dfin> and I can make it power the machine off via the web ui
<ybaumy> when will the maas patch released into beta release for the disk boot order
<ybaumy> there is a patch available and i need it
<ybaumy> https://bugs.launchpad.net/maas/+bug/1673724
<pmatulis> dfin, any firmware updates available for the BMC?
<dfin> pmatulis: I don't think so - let me check
<dfin> pmatulis: I am on the latest firmware version
<dfin> I _suspect_ that something is up with the scripts run on squashfs, but I can't get in there to check. Just a suspicion though...
<pmatulis> dfin, i'm sorry i don't know what else i can add. hopefully someone else here can chime in. i wouldn't give up just yet though. there's a good reason why it's not working
<pmatulis> dfin, do you have other machines that work?
<dfin> pmatulis: no, this is the pilot machine
<pmatulis> dfin, maybe try a quick KVM-backed or VMware-backed node
<pmatulis> to see if there's a wider problem
<dfin> I'll do that
<dfin> pmatulis: whatever the case, thanks for your help
<dfin> yeah, same thing with a VMware node. I'll see if it times out
<pmatulis> is DNS working? pretty sure commissioning requires it
<dfin> DNS is what way. Like the MAAS DNS?
<dfin> I have a working DNS server for our internal domains
<pmatulis> nodes should be able to contact the internet and have DNS working. network-wise. i'll be back later
<dfin> sure
<pmatulis> check the proxy logs during commissioning. you should see requests go out
<pmatulis> i'm pretty sure
<ybaumy> is someone from the devs here?
<zeestrat> ybaumy: Yes, though they might be out due to different TZ.
<ybaumy> zeestrat: i need a patch for maas beta applied
<ybaumy> https://bugs.launchpad.net/maas/+bug/1673724
<ybaumy> when can i expect a release for this
<brendand> ybaumy, that's going to be in the next release, out soon
<ybaumy> brendand: thats great to hear because its really important. would i get that earlier if i had a support aggreement with canonical?
<brendand> ybaumy, if you're willing to use a ppa you can get it now but would have to accept that it hasn't been tested fully yet
<ybaumy> brendand: im using devel
<brendand> ybaumy, which ppa?
<ybaumy> brendand: http://ppa.launchpad.net/maas/next/ubuntu xenial main
<mup> Bug #1675095 opened: [2.2] MAAS selecting the incorrect NTP server for deployed machines <MAAS:Triaged> <https://launchpad.net/bugs/1675095>
<cnf> jamespage: ii'll ask here, if i delete NICs in maas, can i get them back later without knowing the MAC addresses?
<mup> Bug #1675123 opened: [2.2, UI] Interfaces UI shows two items for the subnet <MAAS:Triaged> <https://launchpad.net/bugs/1675123>
<mup> Bug #1675123 changed: [2.2, UI] Interfaces UI shows two items for the subnet <MAAS:Triaged> <https://launchpad.net/bugs/1675123>
<mup> Bug #1675123 opened: [2.2, UI] Interfaces UI shows two items for the subnet <MAAS:Triaged> <https://launchpad.net/bugs/1675123>
<smgoller> Does anyone have any experience deploying coreos with maas?
<mup> Bug #1675123 changed: [2.2, UI] Interfaces UI shows two items for the subnet <MAAS:Triaged> <https://launchpad.net/bugs/1675123>
<roaksoax> smgoller: maas doesn't support coreos
<smgoller> roaksoax: thanks
<smgoller> so I notice when juju creates containers on machines it allocates via maas, the containers show up on the maas node details page. Is there a way to manage that outside of juju?
<smgoller> I guess the simple question is, if I create lxd containers on maas-deployed machines, will they show up?
<roaksoax> smgoller: if you register them in MAAS they would
<roaksoax> smgoller: what juju does is basically "
<roaksoax> "hey maas, register this container that I've just created and give it an static IP address"
<roaksoax> smgoller: and maas adds a container, and using the mac it provides it an "static" IP address that's delivered by DHCP (or juju configures it statically)
<roaksoax> if that makes sense
<smgoller> so maas is doing the actual container creation
<smgoller> er
<smgoller> sorry
 * smgoller goes to look at the juju maas drivers
<roaksoax> smgoller: juju is doing the container creation and telling MAAS about the existance of the container
<smgoller> right
<smgoller> any info on how juju tells maas about the container?
<roaksoax> smgoller: it just makes a API call. I'd think it adds a device with a parent
<roaksoax> smgoller: and then asks for an IP with link-subnet
<xygnal> I have two subbnets on the same untagged fabric.  Although deploying works fine giving it the right auto-assigned address,  comission fails because it picks an dynamic IP in the opposite subnet than its in
<xygnal> the result is that it gets its DHCP response and address during comission, but it cannot connect, because its the wrong address for that subnet
<xygnal> I am I running into limitations, or bugs?
<xygnal> looks like it might have worked when I seperated that second subnet into its own fabric
<Fl1nt> Good evening everyone!
<Fl1nt> Quick question, what kind of "scripts" the commissioning scripts can be? As they seems to be launched by cloud-init, I would say nearly anyone but I need to be sure as I want to use it to manage the Hardware RAID configuration.
<Fl1nt> anyone?
#maas 2017-03-23
<zeestrat> Hey, what's the recommended upgrade path/strategy when both the region and rack controllers are in HA?
<Fl1nt> Hi everybody
<mup> Bug #1675427 opened: [2.2] Failure: twisted.protocols.amp.UnhandledCommand: (b'UNHANDLED', 'Unknown Error [maas22:pid=442:cmd=GetBootConfig:ask=a]') <MAAS:New> <https://launchpad.net/bugs/1675427>
<mup> Bug #1675432 opened: [2.2, RSD] RSDPodDriver doesn't use the 201 location to determine the result of the allocated machine <rsd> <MAAS:Triaged> <MAAS RSD :Triaged> <https://launchpad.net/bugs/1675432>
<mup> Bug #1675468 opened: [2.2] If the region URL has an ipv4_mapped IP, maas refuses to deploy ipv4-only nodes <MAAS:New> <https://launchpad.net/bugs/1675468>
<mup> Bug #1675468 opened: [2.2] If the region URL has an ipv4_mapped IP, maas refuses to deploy ipv4-only nodes <MAAS:New> <https://launchpad.net/bugs/1675468>
<mup> Bug #1595633 changed: [2.0b8] Commissioing/deploying OS doesn't configure the default domain to search <MAAS:Won't Fix> <https://launchpad.net/bugs/1595633>
#maas 2017-03-24
<kklimonda> my maas 2.0 throws "A physical interface can only belong to an untagged VLAN" when I try to assign a physical... interface.. to a tagged VLAN
<kklimonda> I mean, I understand the error, just not the reasoning behind it
<kklimonda> it seems like LP#1572070 was actually supposed to fix it, so I'm wondering if there is a bug, or I'm doing it wrong.
<kklimonda> ok, I guess it makes sense.. need more coffee
<kklimonda> to use a tagged VLAN, I need a vlan interface on the node - that part is actually fine. But what I need is a way to assign different untagged vlans to different nics and spaces - as I understand that will fail with MAAS 2.2
<BlackDex> is there a quick script to change the bond-mode on all the maas nodes?
<BlackDex> or per maas node?
<BlackDex> i mean per node
<BlackDex> i have a lot of systems with the wrong bond-type
<BlackDex> and it seems i can't change the type without destroying the bond-interface via the gui
<cnf> any reason why maas would stop logging?
<cnf> i no longer have a maas.log
<netore> hello, i got this error     [  failed to detect a valid IP address from -1 ] i looked it up and it looks like an old bug but i never seen an explanation of a solution
<netore> hello
<netore> anyone have a tutorial for phpvirtualbox on ubuntu maas? it seems the ubuntu maas installas a bunch of things that the tutorials i have been following dont accomidate for
<zeestrat> BlackDex: Check out the MAAS CLI command "maas $profile interfaces create-bond --help"
<zeestrat> BlackDex: You'll need to loop through your nodes to get their system ID and then get the correct interface ID but should be OK
<zeestrat> BlackDex: If you're into Ansible, I have a short playbook for that.
<netore> im lost already
<netore> oh
<netore> nm
<netore> who wants a beer.
<netore> i gotta have this runnin by 1 today.
<zeestrat> BlackDex: Apologies, make that command "maas $profile interface update --help". The first one is for creating bonds, not updating their settings.
<zeestrat> netore: Would love some beer, but am out of the door. Might be able to take a look in a hour. What's your TZ?
<netore> mountain im not sleeping
<netore> just before you leave because this could solve my whole isssue... is ubuntu 16 ready for maas, or should i run 14.4
<zeestrat> Ubuntu 16.04 (Xenial) is preferred if you want to run an up to date MAAS (2.1.x).
<netore> aiight thats what im runnin and im already having issues that i wanst prepaired for.
<netore> if your on in an hr i got you a beer.
<zeestrat> Gotcha. I've got a HA cluster running on bare metal and have a test setup with KVM so if you're doing something similiar I might be able to help a bit along the way
<netore> aiight... im runnin 16 on a laptop as my controller
<netore> and just trying to add a test vbox as a node and
<netore> getting ready to present this and im not happy
<netore> i can send loot thru fb
<brendand> netore, can you elaborate on what's going wrong?
<zeestrat> Aha. I tried using virtualbox in the beginning but ran into some issues as well. KVM made it a lot easier at least for me.
<zeestrat> Back in a bit.
<netore> aiight.
<netore> brendand
<brendand> netore, if it has to be virtualbox, that might make it a bit harder. kvm is easy
<netore> what is kvm
<brendand> netore, just another hypervisor
<netore> im not planning on runnin any vbox nodes
<netore> i was just testing i can throw another laptop up
<brendand> netore, https://help.ubuntu.com/community/KVM/Installation
<netore> failed to detect a valid IP address from -1
<netore> thats on the controller on a laptop
<netore> my end goal is to run phpvirtualbox on the maas
<netore> i have about 10 virtual box;s i need to span across a few machines.
<brendand> netore, i'm afraid i don't quite understand what you want to do. do you have physical hardware that you want to add to maas?
<netore> yeah
<brendand> netore, i was thinking you wanted the virtualbox vm's to be the machines in maas...
<netore> nah that was just testing adding nodes.
<netore> i will grab another laptop for a node.
<brendand> netore, i'd go straight on to that, it should work out of the box as long as the laptop is set to pxe boot
<netore> my end goal is to be able to run 10 vbox's across 3 machines, and manage them with phpvirtualbox.
<netore> so whats this error failed to detect a valid IP address from -1
<brendand> netore, when does it happen and where do you see it?
<netore> http://IP/MAAS/#/dashboard
<brendand> just there, on the dashboard?
<netore> yup
<netore> too early for errors, its a fresh install.
<brendand> strange. does it look like some kind of notification?
<netore> nah, says error occurred.
<netore> was i supposed to install as a rackcontroller or just regular controller.
<brendand> netore, how did you install?
<netore> i ran the setup as regional controller
<netore> from usb... :|
<brendand> netore, oh right
<brendand> can you do dpkg -l | grep maas-rack-controller?
<netore> yeah
<netore> -> % dpkg -l | grep maas-rack-controller
<netore> ii  maas-rack-controller               2.1.3+bzr5573-0ubuntu1~16.04.1     all          Rack Controller for MAAS
<brendand> ah that should be ok then
<brendand> i've not seen this error before though
<brendand> it should be harmless i think..
<brendand> if you can send a screenshot, just to make sure
<netore> http://imgur.com/a/QpOqr
<netore> that gray over nodes is misleading... my mouse was just over nodes
<netore> http://imgur.com/rGDiZpo
<brendand> cat /etc/maas/regiond.conf
<netore> database_host: localhost
<netore> database_name: maasdb
<netore> database_pass: x1hfpl9sQLR8
<netore> database_user: maas
<netore> maas_url: http://192.168.0.24:5240/MAAS
<netore> you think its just laptop hardware being laptop hardware?
<netore> its a toshiba satellite
<brendand> netore, can you 'database_port: 5432' to that file and run 'sudo systemctl restart maas-regiond'
<netore> how do i do that first part? database prot
<netore> just see if it is accepting connections
<brendand> netore, word missing 'can you *add* database_port: 5432 to that file' i meant to say
<netore> what file
<netore> oh ok
<netore> region...
<brendand> to /etc/maas/regiond.conf
<netore> aiight i got that... then it did device discovery... and errored...
<netore> maybe i just need to throw another node up and then try the device discovery?
<netore> but all i am doing is hitting the MAAS buttin on the page... and it returns an error... maybe its erroring because its a controller without any nodes? maybe its just harmless like you said.
<netore> im gonna throw up a pxe boot lappy n see if it still trips.
<netore> fml who only has one enet chord in the house. aiight one sec... i still need to run phpvbox on maas and im too drunk and got too much riding on this. if it works i still got you 5 $ for the bit of info you already provided.
<netore> if you get me running phpvbox i got you some more $, i can send the 5 as soon as i get a node attatched or this error gone.
<netore> but if you get me runnin phpvbox which i dont understand why i cant run... half a case maybe but either way i appreciate the help n i got some loot on my fb
<netore> fuhk i just tried to pxe boot another machine and nothing
<zeestrat> netore: I'm back. You still alive?
<netore> hell yeah
<netore> bit drunker
<zeestrat> sounds like a great idea. quick question, what is your host os? Did I understand correctly that you have a laptop with some vbox guests and one of them is running ubuntu as your MAAS controller?
<netore> nah
<netore> im running a toshiba satelliete, with ubuntu 16 on it... thats it.
<netore> i also have another laptop ready to go with no os
<netore> i want to run about 10 vboxes across the 2 maas laptops. and manage them from phpvbox
<zeestrat> gotcha. do you have a hard requirement to use phpvbox and other laptops? as you're under a deadline and I have no experience with MAAS controller vbox nodes, I was going to recommend a tutorial that uses KVM (pretty much the same as virtualbox, but MAAS has support for controlling KVM guests out of the box) on a single node.
<netore> i dont need maas in a virtualbox.
<netore> i am creating maas to host vbox.
<netore> there will never be a node that is a virtualbox.
<netore> i am creating the cluster so that i can host 10 vbox's across 2 machines.
<netore> lets just forget the whole virtualbox thing completely.
<netore> i just need to make maas work on two laptops.
<netore> Error occurred                        failed to detect a valid IP address from -1
<zeestrat> I haven't seen that error message before either.
<netore> yeah im starting to think its because its a laptop.
<netore> i tried pxe booting another machine.. so its not harmless because it just wont boot
<zeestrat> I've used this tutorial (https://www.youtube.com/watch?v=ojTTgrtl-RU&index=2&list=PLvn2jxYHUxFlxNmc1dAbw524aoPmHxNpC) to setup a MAAS environment (MAAS controller and some nodes to deploy) with KVM which worked really well.
<netore> basically that is running a few maas across kvm, so like if i had amazon aws, i could make a few kvm and have them all work together.
<netore> i am using real hardware.
<netore> i want to dedicate the whole machines to maas not just a kvm virtual enviornment... once i get maas with some nodes, i plan to INSTALL vbox on the cluster.
<zeestrat> You can also have the laptop be your KVM host. It makes it a bit easier to control/experiment with an isolated network that MAAS runs DHCP on.
<netore> i cant, i am going to be scaling this to racks. each rack will be in the cluster, all real hardware.
<netore> so lets say i have 3 laptops... each one will be completly dedicated to maas.
<zeestrat> gotcha. just a recommendation if you needed to get a proof of concept out of the door under a deadline instead of troubleshooting network issues.
<netore> i have 2 laptops and a dell server, no point in running tests at this point, i need at least 1 node and one controller.
<netore> then im hoping to get more machines and just pxe boot them into the cluster and keep scaling.
<netore> if i understand right, maas will let me use all of the hardware for one process.
<netore> so if i run... /usr/bin/minetest all of the computers will lend ram and proccessor to that process.
<netore> thats what this is really for so i can play minetest with the rescources of 3 computers lololol nah its not lololololol
<zeestrat> Not sure if I'm following you on the process part. MAAS lets you manage and deploy operating systems such as ubuntu to machines (most often bare metal).
<netore> hold on.
<netore> a cluster means that all of the computers share rescources
<netore> 3 computers = 1 combined hd, 1 combined ram, 1 combined processor.
<zeestrat> I'd say that depends quite on the type of cluster. Anyway, MAAS just spins up individual machines for you. The rest you have to do yourself.
<netore> so wait, if i have a maas controller, its just going to allow me to auto pxe boot n install machines on each comp i set to pxe boot?
<brendand> netore, not quite that automatically
<netore> i want a cluster, a sharing of rescources
<netore> fml
<netore> MAAS delivers the fastest OS installation times in the industry thanks to its optimised image-based installer. Setup the RAID and Network configuration you want through the MAAS web UI or CLI, then press a button and come back in minutes to a fully-deployed OS.
<brendand> netore, ?
<netore> astrix?
<netore> i was wanting a cluster.
<netore> fml
<andrew-ii> I think maas will happily manage the metal in your cluster, but you'll need to put cluster software on it
<netore> cluster software.
<netore> ?
<andrew-ii> Like, it'll let you manage the machines, but you'll need to use it to deploy a cluster onto that metal (like, it'll let you manage the network for the cluster and the OS the cluster will run on, but you still need software)
<netore> HA cluster
<andrew-ii> For example, I'm fiddling around with Juju and Openstack
<netore> yes
<netore> maybe thats why i am getting confused is openstack what lets you cluster.
<andrew-ii> I use MAAS to manage the machine configurations like network cards, hard drive designations, and what the subnets and VLANs and such are
<andrew-ii> Then Juju asks MAAS for a machine to be a controller, and that controller asks MAAS for more machines
<andrew-ii> Then I ask Juju to put Openstack bits on the machines it requested
<andrew-ii> And then Openstack lets me do the cool cloud shenanigans
<brendand> netore, sort of. You'd use something like juju to deploy the openstack components on a MAAS (MAAS locates and manages the bare metal systems for you)
<netore> ok so i am in the right area... but i just cant stop at maas, i need to have juju and openstack...
<netore> here is my end goal.
<andrew-ii> For cluster compute? Probably. I think there's some bundles set up for that...
<netore> i want to be able to run 3 computers, and have 10 vbox's share the rescources across those 3 computers.
<andrew-ii> I haven't tried virtualizing across a maas before. Sounds neat. Openstack sorta breaks the problem up a bit more than that I think
<andrew-ii> Part of the issue is that Openstack kinda needs a pile of machines to really get set up easily
<andrew-ii> You can do three though... one sec
<andrew-ii> See if this is at all informative: http://marcoceppi.com/2014/06/deploying-openstack-with-just-two-machines/
<netore> aiight i got three machines to throw at this
<tychicus> netore: do you need to virtualize any windows machines?
<netore> possibly.
<andrew-ii> Also I was wrong - the Juju charm in the charmstore is Minecraft, not minetest, sorry
<netore> lololol
<tychicus> ok, if you did not, you could deploy nova-lxd
<netore> i dont want to not be able to run any vbox i want...
<netore> my end game is just to take all of these laptops and comps i got laying around, and make one machine out of them
<netore> even if i go buy a brand new server, im still going to want to add another brand new server and have them share rescources
<tychicus> may be a little tricky, as maas has specific hardware requirements that it needs for provisioning
<andrew-ii> I think you're still going to end up with stuff running on one machine, but if that machine dies, it'll likely be able to spin up elsewhere
<tychicus> I am guessing that your laptops don't have out of band management, intel AMT or impi
<netore> i have run a process on freebsd and had two computers have at it... but it was limited... i was sure ubuntu openstack and juju solved this...
<netore> i dunno but i can get machines specific for this.
<netore> i thought maas was the cluster, and juju was for deploying apps like wordpress and openstack was the management
<tychicus> people have done really well with intel nuc, http://blog.dustinkirkland.com/2013/11/review-ubuntu-and-intel-nuc.html
<tychicus> or any of the xeon D based server's should work
<netore> let me chek the specs on that machine i just got
<brendand> tychicus, you have to be careful in choosing your nuc
<netore> thats fine... as long as when i run 1 new vbox it shares the ram and cpu of all the nodes
<tychicus> netore: it doesn't quite work that way
<netore> int3l zeon e3-1270 v5
<netore> fml
<zeestrat> netore: Pooling resources does not really work that way outside of supercomputers. Most clusters are based on the smallest common denominator (i.e. your individual servers)
<tychicus> :brendand, I think the only one that supports AMT is the DC53427HYE
<netore> daym.
<zeestrat> I'd look at your workload and see how you can split it up as smaller individual hosts/jobs and then run them in a kubernetes cluster or openstack (though note that you really need to be sure that is something you want as it requires a bunch of resources and knowledge)
<netore> kubernetes cluster let me look that up rq
<netore> beowulf
<netore> is what i ran in freebsd.
<netore> but it was limited to only a few programs
<tychicus> netore: MaaS does not solve that particular problem for you.  MaaS (Metal as a Service) used for provisioning an OS onto bare metal, juju service orchestration, allows you to quickly install complex applications across multiple machines, whether physical or virtual
<netore> aiight fellas, sorry for wasting your time... i thought maas was the new equivilent to beowulf.
<netore> fml
<netore> i just dont understand why maas wouldnt solve this.
<netore> especially when i seen how juju works, i thought it was a no brainer.
<tychicus> you could write a juju charm, that installs beowulf on all of the machines that have been commissioned by MaaS
<netore> really lolol
<netore> your grabbing me bak in... lolol
<tychicus> but nothing in maas or juju will automagically aggregate the compute resources for all of the machines
<tychicus> they just provide a platform that makes managing machines easier
<netore> and as far as i know beowulf is limited to gcc  processes
<netore> yeah, i gotta figure out something before 1, i fuhken had this in the bag i thought.
<netore> The cluster is now complete. To take advantage of the clustering, open a terminal and type "mpirun -np # PROGRAM" where "#" is the number of processes/threads to create and "PROGRAM" is the program or script to run on the cluster.
<netore> with mpi i could run the command mpirun....# virtualbox.
<zeestrat> Hey, what's an easy way to list out the system id of all nodes that are ready or new (not including the rack/region controllers) via the CLI?
<BlackDex> zeestrat: Thanks for your answer btw.. I resolved it by using some jq magic ;)
<BlackDex> i only needed to give the correct machine-id and it changed all bond interfaces to an other mode-mode
<zeestrat> BlackDex: np :) Glad to hear you got something working
<BlackDex> would have been a pain in the a** using the gui
<BlackDex> you first need to remove the interface and re-create the bond again if you want to change the bond-mode
<roaksoax> zeestrat: try maas admin machines read status=<status>
<BlackDex> doing that at 9 machines, with 4 bonded interfaces.
<zeestrat> yeah, I created a bug on the gui stuff for editing bonds. We're mostly using playbooks with CLI to configure everything anyway
<zeestrat> roaksoax: thanks, I'll give it a go
<roaksoax> zeestrat: new=0, ready=4
<roaksoax> zeestrat: so maas admin machines read status=0
<roaksoax> zeestrat: so maas admin machines read status=4
<BlackDex> you have a playbook for me to look at?
<zeestrat> BlackDex: EOD here, but pm me and I can get back to you :) They are not optimal, but get the job done.
<BlackDex> sure
<BlackDex> :)
<BlackDex> done :) have a nice weekend :)
<zeestrat> Cheers, same to you!
<mup> Bug #1675823 opened: [2.2] ProcessGroupLeaderMixin races with spawnProcess <MAAS:In Progress by allenap> <https://launchpad.net/bugs/1675823>
<mup> Bug #1675838 opened: [2.2 ui] OS/Release section of Filter By panel doesn't show text for the different options <MAAS:New> <https://launchpad.net/bugs/1675838>
<mup> Bug #1675844 opened: MAAS takes ipv6 ULA address as a primary one <MAAS:Triaged> <https://launchpad.net/bugs/1675844>
<mup> Bug #1675844 changed: MAAS takes ipv6 ULA address as a primary one <MAAS:Triaged> <https://launchpad.net/bugs/1675844>
<mup> Bug #1675844 opened: [2.1] MAAS takes ipv6 ULA address as a primary one <MAAS:Triaged> <https://launchpad.net/bugs/1675844>
<mup> Bug #1675887 opened: [2.1] Commissioning fails to detect drives. <MAAS:Incomplete> <https://launchpad.net/bugs/1675887>
<ybaumy> https://bugs.launchpad.net/maas/+bug/1673724
<ybaumy> guys i need that patch in devel/next
<ybaumy> that would be cool
<ybaumy> it would be more than cool because i need to show a working maas environment. and everything works for me except this and this is really important
<ybaumy> so. could someone release the patch into next
<ybaumy> is andres rodriguez here?
<pmatulis> ybaumy, as a hack, i believe you can make a one-line change to a single Python script
<ybaumy> pmatulis: which script?
<pmatulis> /usr/lib/python3/dist-packages/provisioningserver/refresh/node_info_scripts.py
<pmatulis> line 9 here:
<pmatulis> http://paste.ubuntu.com/24237785/
<pmatulis> you will need to re-add the node
<pmatulis> afterwards
<ybaumy> gonna try it. give me a few minutes
<pmatulis> last minute friday hack job!
<ybaumy> ok commission is running.
<ybaumy> that will take just a few minutes
<ybaumy> pmatulis: do i have to restart daemons for that to work because i didnt restart anything and it didnt work .. its still /dev/sdb as boot device
<pmatulis> ybaumy, i didn't hear about such a requirement
<ybaumy> pmatulis: then it doesnt work
<pmatulis> ybaumy, this is for failed Deployments right?
<ybaumy> no its for commissioning
<pmatulis> damn, sorry
<ybaumy> i get /dev/sdb as boot or the last of the disks
<pmatulis> possible to go with just single disk machines for your demo?
<ybaumy> pmatulis: nope there are ceph-osd machines i want to show
<pmatulis> darn
<ybaumy> yep this sucks
<pmatulis> what PPA are you using? maybe there is something bleeding edge that works
<ybaumy> next ppa
<pmatulis> not sure where next-proposed is at
<ybaumy> bleeding edge sounds like it would break something else. and currently else is working you undestand that i dont want to mess with it if i could
<pmatulis> fwiw, https://launchpad.net/~maas/+archive/ubuntu/next-proposed
<pmatulis> yes, i understand
<ybaumy> is it fixed in proposed?
<pmatulis> i'm looking at the dates, march 13
<pmatulis> roaksoax, any comment? ^^^
<pmatulis> next and next-proposed look identical to me
<pmatulis> https://launchpad.net/~maas/+archive/ubuntu/next
<ybaumy> then i dont have to change the ppa
<mup> Bug #1675915 opened: [2.2] Script selection doesn't show scroll bar <hardware-testing> <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1675915>
<pmatulis> right
<mup> Bug #1675919 opened: [2.2] Commissioning and Testing tabs should show spinner while running <hardware-testing> <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1675919>
<pmatulis> i gotta run. be back later tonight
<pmatulis> good luck ybaumy
<ybaumy> pmatulis: thanks dude
<ybaumy> later
<ybaumy> what is the nick of andres rodriguez
<brendand> ybaumy, roaksoax
<ybaumy> ok
<ybaumy> in which timezone is he in
<brendand> ybaumy, if you want it now you can use https://launchpad.net/~maas-maintainers/+archive/ubuntu/experimental3 but that's a testing ppa and i would *not* recommend using that for any setup you want to be reasonably stable
<brendand> ybaumy, the release is not going to be expedited because you need one patch
<ybaumy> brendand: no i wont. because i dont want to break other things now that its working for me
<brendand> ybaumy, well atm that's what's going into /next anyway
<brendand> ybaumy, early next week after a little more testing
<ybaumy> brendand: hmm that would be cool early next week. on wednesday i would need it
<brendand> ybaumy, fyi releases are done in a cadence, not ad-hoc/on-demand
<ybaumy> brendand: i fully understand this.
<roaksoax> ybaumy: 2.2beta4 is cut
<roaksoax> should help fix a few issues
<ybaumy> brendand: i dont like to pressure too. but i want to show management that we have something here we can use .. you must understand
<roaksoax> ybaumy: you can use either ppa:maas/proposed -> 2.1.5
<roaksoax> ybaumy: or 2.2b4 will soon land in ppa:maas/next-proposed
<roaksoax> just doing a final round of testing
<ybaumy> roaksoax: ok
<ybaumy> roaksoax: thanks for the information
<roaksoax> ybaumy: 2.1.5 is ready to be released, just prioritizing 2.2b4 atm
<ybaumy> roaksoax: can i downgrade from 2.2.0~beta3+bzr5815
<roaksoax> ybaumy: uhmmm i can't remember but i think there has been migrations from 2.2b2 to 2.2b3, which means you probably cant
<roaksoax> we dont do backward migrations
<ybaumy> roaksoax: then i have to wait
<roaksoax> ybaumy: what are your issues with 2.2b3 ?
<ybaumy> roaksoax: /dev/sdb or the last disk is the boot disk
<roaksoax> ybaumy: you can easily change that
<ybaumy> roaksoax: not /dev/sda
<roaksoax> ybaumy: maas <user> block-device set-boot-disk <system-id> <block-id>
<roaksoax> maas <user> machine set-storage-layout <system-id> storage_layout=flat
<roaksoax> where block-id is the id of /dev/sda
<ybaumy> roaksoax: that what im doing right now already. you have to see that i need a management ready presentation where i just add the nodes and click commission and then show them how to deploy cloud with juju
<ybaumy> roaksoax: if i do workarounds they will say that its not working
<ybaumy> roaksoax: i know them
<roaksoax> ybaumy: this is not a workaound tough. This is valid user configuration
<roaksoax> there's no way to know which one is the boot disk
<roaksoax> set by the bios
<roaksoax> maas just makes an assumption
<ybaumy> roaksoax: hmm thats not good at all
<roaksoax> and this assumption is now the last disk because of lsblk
<ybaumy> im using vmware
<ybaumy> and you have the scsi ids or not?
<roaksoax> ybaumy: yup, that's lsblk listing sdb before sda
<roaksoax> ybaumy: while MAAS knows that it is poewr managing vmware VM's, it uses them as regular machines
<ybaumy> roaksoax: hmm so there is not way to change that behaviour?
<roaksoax> lsblk's ? yeah we are investigating on it
<ybaumy> ybaumy: i have to write an own website for that .. triggering the correct commands then
<roaksoax> either way, what we did in maas is try to ensure that we always return the first discovered disk, so thta it gets set as the book device
<ybaumy> hmm i dont know what to do right now
<ybaumy> will have to think this over
<roaksoax> ybaumy: you can patch maas yourself directly if you want
<ybaumy> roaksoax: im not a programmer
<ybaumy> roaksoax: i dont want to mess with things i cant understand or dont understand fully
<roaksoax> ack!
<roaksoax> ybaumy: either way, I just pushed b4 to next-proposed
<ybaumy> roaksoax: i have to ask a colleague from work .. he knows python and maybe he can do something
<roaksoax> ybaumy: it should be available in the next 30 mins
<ybaumy> roaksoax: thanks
<roaksoax> ybaumy: you will need to re-add the machine and re-commission it, and do please let me know if that made any idfferent
<roaksoax> we've tested against hardware and VM's here, and tests were successful
<ybaumy> roaksoax: will try as soon as i have the new relsase
<roaksoax> ybaumy: sudo lsblk --exclude 1,2,7 -d -P -o NAME,RO,RM,MODEL,ROTA,MAJ:MIn -x MAJ:MIN -> if you can try that on the VM to see how it lists the disk
<roaksoax> then i'll know if it works for you or not
<ybaumy> roaksoax: i ran the command on already deployed VM's and sda is always first
<roaksoax> ybaumy: ok cool, so that will work
<roaksoax> ybaumy: what if you run: sudo lsblk --exclude 1,2,7 -d -P -o NAME,RO,RM,MODEL,ROTA
<ybaumy> roaksoax: then same
<roaksoax> uhm maybe this is not an lsblk issue after all and a kernel thing
<ybaumy> roaksoax: we will see when i got the patch applied .. readded the VM's and commissioned them. i have 10 VM's so it should be enough to see whats going on
<zeestrat> roaksoax: Dumb question, but does that bug show up only during commissioning? We've hit something like this in https://bugs.launchpad.net/maas/+bug/1644856 in 2.0.0, but there MAAS correctly commissioned them, but upon switched it up on deployment and chose the last device device as boot device.
<roaksoax> ybaumy: ok, i just tested this against a kvm machine where sdb would be the root disk, now it is making sda as the root disk
<roaksoax> ybaumy: so you should be good to go too
<ybaumy> roaksoax: lets see. im waiting
<roaksoax> zeestrat: without looking at it, I'd say that thiscould be hardware related. For example, during commissioning the OS finds hd0 as sda, but in a subsequent boot, hdx becomes sda but MAAS depends on the serials and such
<roaksoax> zeestrat: but would be indeed interesting to investigate
<roaksoax> zeestrat: so maas , at deployment time knows that what it know as sda, is no longer sda and it i something else
<roaksoax> zeestrat: but that's just a wild guess
<roaksoax> zeestrat: if you could also attach this, it would be great:
<roaksoax>  maas <user> machine get-curtin-config <system_id_of_machine>
<roaksoax>  - maas <user> node-results read system_id=<system_id> name=00-maas-07-block-devices.out | grep "\"data\"" | cut -d"\"" -f4 | base64 --decode
<roaksoax>  - maas <user> node-results read system_id=<your_system> result_type=1 | grep "\"data\"" | cut -d"\"" -f4 | base64 --decode
<zeestrat> roaksoax: Thanks I'll note that down and try to replicate it. Only happens some times which is annoying.
<zeestrat> roaksoax: Anyways, thanks for all the help. Have a good weekend!
<ybaumy> roaksoax: patch is here. commissioning is running ..
<ybaumy> roaksoax: :D it works .. yes sir
<ybaumy> roaksoax: all ten are /dev/sda
<ybaumy> roaksoax: im so happy right now
<ybaumy> roaksoax: there are machine with 2 4 8 disks and all are correctly set
<ybaumy> running juju deploy ceph-osd right now
<ybaumy> roaksoax: i have to call it quit right now. deploy works now too. will double check tomorow. will drop you a PM if i have problems but really looks good right now. thanks for the quick help. i really appreciate this
<ybaumy> will be here around 0800 tomorow
<mup> Bug #1675953 opened: [2.2] Space constraint matching should allow matching the undefined space <MAAS:In Progress by mpontillo> <https://launchpad.net/bugs/1675953>
#maas 2017-03-25
<mup> Bug #1675981 opened: Rackd HA doesn't work, DHCP unavailable <docteam> <MAAS:New> <https://launchpad.net/bugs/1675981>
<mup> Bug #1675981 changed: Rackd HA doesn't work, DHCP unavailable <docteam> <MAAS:New> <https://launchpad.net/bugs/1675981>
<mup> Bug #1675981 opened: Rackd HA doesn't work, DHCP unavailable <docteam> <MAAS:New> <https://launchpad.net/bugs/1675981>
<ybaumy> could there be a option for
<ybaumy> maas user machines .. tags add ...
<ybaumy> to assign tags to a bunch of machines
<ybaumy> it would also be nice if using the hostname or fqdn of a machine would be possible
<pmatulis> ybaumy, https://docs.ubuntu.com/maas/2.1/en/manage-cli-tags
#maas 2017-03-26
<Chaitanya> hi
<Chaitanya> Anyone tried to integrate MAAS REST API with AngularJS ?
<mup> Bug #1676167 opened: [2.2b1] Device BMC passwords seem to have been lost in upgrade <MAAS:New> <https://launchpad.net/bugs/1676167>
<sarah__> hello ! I'm a newbie in using maas and all and I want to know how can I import a raw image that I have on my pc to maas ?
<sarah__> I know its boot-resources cli command related, but how exactly ?
#maas 2018-03-19
<mup> Bug #1756766 opened: [2.4a2] crash in observ-mdns <MAAS:New> <https://launchpad.net/bugs/1756766>
<mup> Bug #1756781 opened: Unable to see IP leases in MAAS UI <MAAS:New> <https://launchpad.net/bugs/1756781>
<mup> Bug #1741179 changed: package maas-region-api 2.2.0+bzr6054-0ubuntu2~16.10.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 <amd64> <apport-package> <yakkety> <maas (Ubuntu):Expired> <https://launchpad.net/bugs/1741179>
<mup> Bug #1756821 opened: tag autocompletion dropdown broken <MAAS:New> <https://launchpad.net/bugs/1756821>
<mup> Bug #1756766 changed: [2.4a2] crash in observ-mdns <MAAS:New> <https://launchpad.net/bugs/1756766>
<mup> Bug #1756766 opened: [2.4a2] crash in observ-mdns <MAAS:New> <https://launchpad.net/bugs/1756766>
<mup> Bug #1756766 changed: [2.4a2] crash in observ-mdns <MAAS:New> <https://launchpad.net/bugs/1756766>
<Barak> PXE boot not working the device recognize the pxe boot option but can't establish the link
<mup> Bug #1756956 opened: 2.4: pods 'create' fails without a zone specified <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1756956>
<vogelc> @roaksoax Is there any way to add a node in to maas and allocate it to a user without having to commission and deploy it?
<vogelc> roaksoax: see ^^^
<roaksoax> vogelc: nope
<mup> Bug #1756956 changed: 2.4: pods 'create' fails without a zone specified <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1756956>
<mup> Bug #1756956 opened: 2.4: pods 'create' fails without a zone specified <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1756956>
<_bladernr_> roaksoax, just curious, is boot from SAN supported by MAAS?  in other words, if I have a SAN LUN configured for a HBA on my node, and I commission, if that SAN LUN appears as a block device during commissioning, can I completely install to the SAN, and then boot from it when MAAS completes deployment?
<_bladernr_> and if so, does that require at least some local storage for grub, or can it be completely diskless (SAN only)?
<_bladernr_> roaksoax, ^^ that's assuming, of course, that the HBA is supported in the MAAS ephemeral environment.
<mup> Bug #1756956 changed: 2.4: pods 'create' fails without a zone specified <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1756956>
<roaksoax> _bladernr_: we dont support diskless boot
<roaksoax> _bladernr_: if, however, the machine sees that as locally attached storage and everything would be done via firwamre as is deisplayed as locally attached, it may work
<Hey_> I have 150 physical servers, I may image 5 machines a week.  What should the specs of my physical server be?
<Hey_> MAAS Server I mean.
<_bladernr_> roaksoax, thanks!
<mup> Bug #1756985 opened: [2.4, UI] Can't add a machine over the UI <MAAS:Triaged by newell-jensen> <https://launchpad.net/bugs/1756985>
#maas 2018-03-20
<mup> Bug #1757067 opened: Intermittent failure: test_estimated_runtime_sets_start_time_when_unavailable <intermittent-failure> <MAAS:Triaged> <https://launchpad.net/bugs/1757067>
<mup> Bug #1757153 opened: [2.4, UI, regression] Run time for commissioning/testing scripts is incorrect <MAAS:Triaged> <https://launchpad.net/bugs/1757153>
<mup> Bug #1757155 opened: [2.4, UI] Storage firmware version is mispelled & should be part of Name | Model | Serial switcher <MAAS:Triaged by ltrager> <https://launchpad.net/bugs/1757155>
<mup> Bug #1757210 opened: [2.4, regression] Cannot compose a machine inside <MAAS:In Progress by newell-jensen> <https://launchpad.net/bugs/1757210>
<wdennis> hi all - looking at https://docs.maas.io/2.3/en/installconfig-network-dhcp and trying to configure MAAS to use my external DHCP server; does not look like the dos correlate to my MAAS UI (running v2.3.0)
<wdennis> *docs not dos
<wdennis> I was able to configure my external DHCP server to next boot IP of the MAAS server, and used BIOS filename 'pxelinux.0', and was successfully able to netboot a machine from MAAS
<wdennis> However, got a cloud-init message that the node "failed to enlist system maas server" and powers off
<wdennis> And (unsurprisingly) no node shows up in the MAAS UI
<roaksoax> wdennis: /etc/maas/rackd.conf make sure it is pointing to an ip instead of localhost
<mup> Bug #1757242 opened: [2.4, UI] Need some space between green "Compose machine" button and the pod details table. <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1757242>
<wdennis> roaksoax: It was indeed pointing to 'localhost' - corrected to put in IP. Do I need to restart any service etc?
<roaksoax> wdennis: yes, rackd
<roaksoax> sudo service maas-rackd restart
<mup> Bug #1757210 changed: libvirt drops connection when attaching a disk (breaks MAAS pods) <MAAS:Invalid by newell-jensen> <libvirt (Ubuntu):New> <https://launchpad.net/bugs/1757210>
<mup> Bug #1757262 opened: [2.4, pod] KVM pod doesn't fail if it fails to attach disk <pod> <MAAS:Triaged> <https://launchpad.net/bugs/1757262>
<mup> Bug #1757210 opened: libvirt drops connection when attaching a disk (breaks MAAS pods) <MAAS:Incomplete by newell-jensen> <libvirt (Ubuntu):New> <https://launchpad.net/bugs/1757210>
<wdennis> roaksoax: Thx for the info... restarted the maas-rackd service, then retried the PXE on the host, but still not registering... Can you point me to logs (either on PXE client OS or server) that I can look at?
<wdennis> Found server-side logs in /var/log/mass/*, looking at rackd.log, seeing these errors periodically: https://bpaste.net/show/1de12b924a25
<wdennis> Region controller and rack controller are on same node (default MAAS install via Ubuntu ISO...)
<roaksoax> wdennis: /var/log/maas/rsyslog/*
<roaksoax> wdennis: if it is a non-known maas machine, check the logs under maas-enlisting-node/<date>/<ip>
<wdennis> roaksoax: No files in /var/log/maas/rsyslog/ on server
<roaksoax> wdennis: do yo ahppen to have a console log ?
<wdennis> roaksoax: On the client? Unfortunately no
<wdennis> roaksoax: Aha - looking at 'cloud-init' messages captured in syslog on the client, I see that the server url as used by maas-enlist has the wrong IP address in it...
<wdennis> Is that se somewhere on the server?
<wdennis> *set
<roaksoax> wdennis: ok, see if it is the same IP as /etc/maas/regiond.conf:maas_url ?
<wdennis> roaksoax: Yup, it was the wrong IP there - corrected. Restart a service needed?
<wdennis> And, any other places I should look for incorrect IPs?
<wdennis> A grep for my IP block in /etc/maas/* shows the correct IPs now: https://bpaste.net/show/65ba3791ed38
<wdennis> OK, looks like that was it - the node successfully registered now :)
<wdennis> Lesson learned - don't install a new MAAS server on a temp DHCP address, then re-IP it later...
<wdennis> How may I customize the Ubuntu install that the "Deploy" action lays down on disk? (partitioning, add'l pkgs to install. etc?)
#maas 2018-03-21
<gunix> hello
<gunix> i am trying to boot ubuntu16.04 on hp dl380 gen9 servers and the problem is the servers are PXE booting and are shutting down right after that
<gunix> and they don't appear in machines or innodes
<gunix> i tried to manually add the machines and they are failing testing
<gunix> proc and mem are detected but disks not
<mup> Bug #1757312 opened: UI - Network Discovery - Cannot use browser search <MAAS:New> <https://launchpad.net/bugs/1757312>
<mup> Bug #1757210 changed: libvirt drops connection when attaching a disk (breaks MAAS pods) <MAAS:Incomplete by newell-jensen> <libvirt (Ubuntu):In Progress by paelzer> <https://launchpad.net/bugs/1757210>
<wdennis_> is there a log available of this channel?
<wdennis_> Also, the "Docs" link in the channel header message 404's... Shouldn't it be "http://docs.maas.io" ??
<roaksoax> gunix: that could mean you have problems with memory and proc on your systems ? what version of MAAS you using ?
<roaksoax> wdennis: MAAS can do partitioning for you
<roaksoax> wdennis: you can use the UI or api to do
<roaksoax> wdennis: as far as additional packages and such, you can user cloud init. The deploy api has user_data which allows you to send cloud-init user data
<wdennis_> roaksoax: didn't see how in docs, any links?
<roaksoax> wdennis_: to be fari, you have to ways:
<wdennis_> I'm familiar with what d-i directives in need to put in a preseed; how to do that with cloud-init?
<roaksoax> 1. modifying the preseed: https://insights.ubuntu.com/2017/06/02/customising-maas-installs
<roaksoax> 2. using cloud-init, see the last comment: https://askubuntu.com/questions/636837/are-there-examples-of-custom-installation-scripts
<roaksoax> doing it in the preseeds (1) makes it permanent
<roaksoax> doing (2), per deployment
<roaksoax> more cloud-like
<wdennis_> roaksoax: Thx for links
<wdennis_> Any good docs on cloud-init?
<wdennis_> Ah, http://cloudinit.readthedocs.io/en/latest/index.html
<mup> Bug #1757475 opened: include favicon for easy tab identification  <ui> <MAAS:New> <https://launchpad.net/bugs/1757475>
<roaksoax> win 3
<wdennis_> roaksoax: So I figured out how to partition my test node in the UI, and it did so; how to set up a partition map that applies to all deployed nodes?
<gunix> roaksoax: are you still on here?
<gunix> i don't see the storage in the MAAS web GUI, but i SSHed into the physical servers and on lsblk i find: sda     8:0    0 894.3G  0 disk
<gunix> ...
<wdennis_> So I read moar docs, and saw the options for "Default storage layout" in settings... "LVM" is about what I want, but I'd like to customize it (create another LV for "/home")... any way to do that?
<roaksoax> wdennis_: there's no way to create a custom default storage layout today, unfortunately, it is, however, a wishlist
<wdennis_> roaksoax: on roadmap?
<roaksoax> wdennis_: it is on the long list of roadmap items yet, not scheduled though
<gunix> roaksoax: i figured it out. maas is awesome
<gunix> i just had to recommission and everything went fine. i deployed alled servers.
<gunix> thanks for the help!
#maas 2018-03-22
<mup> Bug #1757991 opened: [2.3.0] metadat URL is [::1] when no port is specified for ipv4 IP in rackd.conf <cpe-onsite> <MAAS:New> <https://launchpad.net/bugs/1757991>
<mup> Bug #1731956 changed: [2.3rc2, UI] Make all the font styles consistent in the summary cards <2.3qa> <ui> <MAAS:Invalid> <https://launchpad.net/bugs/1731956>
<roaksoax> jhi/win 4
<roaksoax> err
<wdennis> roaksoax: The nodes run cloud-init every time they boot, correct? I'm not able to get into a node with the SSH key that's set on the user who owns the node... Even tried power off/power on, still no go. Any local console login available?
<roaksoax> wdennis: is this on what state ?
<wdennis> "Deployed"
<roaksoax> wdennis: check /var/log/maas/rsyslog/<machine-name>/<date>/<messages> and see if there's any error ?
<wdennis> roaksoax: No errors from what I can see...
<roaksoax> wdennis: anything in the console ? it would be strange for it to not at all allow you to log in
<roaksoax> wdennis: on ubuntu@
<roaksoax> with your ssh key
<wdennis> roaksoax: Noting showing on the console, if that's what you meant...
<wdennis> Tried local (cos) login as "ubuntu" w/ passed "ubuntu", not allowing login
<wdennis> Here's last ~50 lines from /var/log/maas/rsyslog/<machine-name>/<date>/messages: https://bpaste.net/show/8eb6b0dc82d0
<wdennis> When I try to login:
<wdennis> itss-mac-mini:~ itsgroup$ ssh ubuntu@192.168.1.141 Permission denied (publickey).
<roaksoax> wdennis: maybe the key is malformed and fails to import it ?
<wdennis> It was working before... I rebooted the node, and it no longer worked.
<roaksoax> wdennis: ok, so you deployed the machine, ssh, it worked, rebooted, and all of the sudden you were unable to ssh in ?
<wdennis> That's correct
<roaksoax> wdennis: that seems veeeeeeeeeeery weird
<roaksoax> wdennis: what version of MAAs are you using ?
<roaksoax> wdennis: and what are you deploying ?
<wdennis> Running MAAS 2.3.0 (6434-gd354690-0ubuntu1~16.04.1)
<wdennis> Deploying U16.04
<wdennis> roaksoax: Here's a question: can you take a running machine (or a deployed machine that's powered off), and directly "commission" it?
<wdennis> Seems that I could from the main "Nodes" screen (checkbox-select the node, then choose "Commission" from the "Take action" menu)
<wdennis> However, when I'm in the specific node screen (by clicking on the node name from the Nodes screen), I do not see "Commission" in the list of available actions
<wdennis> The reason I ask is, this is a test setup I'm running, and I could just "reset" the node by commissioning it, then re-deploy it
<wdennis> Instead of the usual "Release" of the node, which runs a disk wipe, then re-commissioning it
<wdennis> Aha, the answer seems to be "no, you can't"... Tried to Commission it from the Nodes screen, and got "1 node cannot be commissioned. To proceed, update your selection."
<mup> Bug #1758193 opened: [2.4] Auto-assigned IP doesn't get written as a hostmap, causing 'deploying' machine to use a IP from dynamic range <MAAS:Triaged by blake-rouse> <https://launchpad.net/bugs/1758193>
<mup> Bug #1748052 changed: [2.4, devel] ] Unable to write to plugin cache /usr/lib/python3/dist-packages/twisted/plugins/dropin.cache: error number 13 <MAAS:Fix Released> <https://launchpad.net/bugs/1748052>
<mup> Bug #1749962 changed: [2.4] Cannot allocate memory when DescribePowerTypes happen <performance> <MAAS:Fix Released> <https://launchpad.net/bugs/1749962>
<mup> Bug #1748055 changed: [2.4, devel] INTERNAL_SERVER_ERROR While commissioning/testing <MAAS:Invalid> <https://launchpad.net/bugs/1748055>
<mup> Bug #1748929 changed: [2.4, CI]  [critical] Failure when cancelling hook <performance> <MAAS:Fix Released> <https://launchpad.net/bugs/1748929>
#maas 2018-03-23
<wdennis_> roaksoax: I think I know what's happened with SSH - I created a LV for home, formatted it, then mounted it - it's overlayed the /home that was there when the system was created. I'm assuming '/home/ubuntu' is not available now, which has the .ssh/authorized_users with the keys :(
<wdennis_> So I suppose "game over", need to re-install....
<mup> Bug #1733847 changed: same ip got assigned to two different container  <juju:Invalid> <MAAS:Expired> <https://launchpad.net/bugs/1733847>
<wdennis_> yup, that was it... reinstalled and I'm good again
<gunix> hey guys, any idea why deployment would fail if i deployed the 3rd time to the same host ?
<mup> Bug #1757475 changed: include favicon for easy tab identification  <ui> <MAAS:New> <https://launchpad.net/bugs/1757475>
<mup> Bug #1753721 changed: clicking on "logs" for a deploying machine shoud bring you automatically to the "installation output" section <MAAS:Invalid> <https://launchpad.net/bugs/1753721>
<mup> Bug #1753721 opened: clicking on "logs" for a deploying machine shoud bring you automatically to the "installation output" section <MAAS:Invalid> <https://launchpad.net/bugs/1753721>
<mup> Bug #1753721 changed: clicking on "logs" for a deploying machine shoud bring you automatically to the "installation output" section <MAAS:Invalid> <https://launchpad.net/bugs/1753721>
#maas 2018-03-24
<mup> Bug #1754697 changed: [FFe] Standing FFe for MAAS 2.4 <upgrade-software-version> <maas (Ubuntu):Fix Released> <https://launchpad.net/bugs/1754697>
<mup> Bug #1758476 opened: MAAS increments block device name on every commission <MAAS:Triaged> <MAAS 2.3:Triaged> <https://launchpad.net/bugs/1758476>
<mup> Bug #1513775 opened: MAAS didn't parse dnssec-validation automatically <MAAS:Confirmed> <https://launchpad.net/bugs/1513775>
#maas 2018-03-25
<mup> Bug #1758743 opened: Information in columns when searching nodes disappears when mousing over FQDN links <MAAS:New> <https://launchpad.net/bugs/1758743>
<mup> Bug #1758760 opened: BMC user account creation during enlistment fails on Lenovo SR550 <cpe-onsite> <MAAS:New> <https://launchpad.net/bugs/1758760>
#maas 2020-03-16
<mup> Bug #1867487 changed: maas snap 2.7, excessive load, ram consumption inside lxd container <MAAS:New> <https://launchpad.net/bugs/1867487>
<mup> Bug #1867487 opened: maas snap 2.7, excessive load, ram consumption inside lxd container <MAAS:New> <https://launchpad.net/bugs/1867487>
<mup> Bug #1867487 changed: maas snap 2.7, excessive load, ram consumption inside lxd container <MAAS:New> <https://launchpad.net/bugs/1867487>
<mup> Bug #1867571 opened: apparmor denied warning for /run/uuidd/request <MAAS:New> <https://launchpad.net/bugs/1867571>
<mup> Bug #1867571 changed: apparmor denied warning for /run/uuidd/request <MAAS:New> <https://launchpad.net/bugs/1867571>
<mup> Bug #1867571 opened: apparmor denied warning for /run/uuidd/request <MAAS:New> <https://launchpad.net/bugs/1867571>
<mup> Bug #1859177 changed: Maas deployment with weak ciphers in postgres <MAAS:Expired> <https://launchpad.net/bugs/1859177>
<mup> Bug #1859177 opened: Maas deployment with weak ciphers in postgres <MAAS:New> <https://launchpad.net/bugs/1859177>
<mup> Bug #1859177 changed: Maas deployment with weak ciphers in postgres <MAAS:New> <https://launchpad.net/bugs/1859177>
<mup> Bug #1859177 opened: Maas deployment with weak ciphers in postgres <MAAS:New> <https://launchpad.net/bugs/1859177>
<mup> Bug #1859177 changed: Maas deployment with weak ciphers in postgres <MAAS:New> <https://launchpad.net/bugs/1859177>
<mup> Bug #1859177 opened: Maas deployment with weak ciphers in postgres <MAAS:New> <https://launchpad.net/bugs/1859177>
<mup> Bug #1867571 changed: apparmor denied warning for /run/uuidd/request <snapd:In Progress by jdstrand> <https://launchpad.net/bugs/1867571>
<ivve> any good way to change default dns interface
<ivve> other than hacking the DB?
<mup> Bug #1860177 changed: access to boot-resources gone from 2.6.1 CLI <MAAS:Invalid> <https://launchpad.net/bugs/1860177>
<mup> Bug #1864385 changed: MAAS Backup Instructions Contain a Typo <MAAS:Fix Released> <https://launchpad.net/bugs/1864385>
<mup> Bug #1867350 changed: Race in packer build using vmware-esxi.json <MAAS:Fix Released> <https://launchpad.net/bugs/1867350>
#maas 2020-03-17
<mup> Bug #1867350 opened: Race in packer build using vmware-esxi.json <MAAS:Fix Committed> <https://launchpad.net/bugs/1867350>
<TiboldK> Hey all! Is there a way to disable DNS recursion in the snap install of MAAS?
<mup> Bug #1867812 opened: maas 2.7 creates partition when trying to use entire disk as bcache cache device <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1867812>
#maas 2020-03-18
<mup> Bug #1867935 opened: remove openwsman and rdep wsmancli <MAAS:New> <openwsman (Ubuntu):New> <wsmancli (Ubuntu):New> <https://launchpad.net/bugs/1867935>
<mup> Bug #1781241 opened: rack controller remained in degraded state <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1781241>
<mup> Bug #1781241 changed: rack controller remained in degraded state <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1781241>
<mup> Bug #1781241 opened: rack controller remained in degraded state <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1781241>
#maas 2020-03-19
<tosaraja> Should PXE booting with vlan tag work? Anything I should know? I managed to get one host doing it, but the second one boots to grub only
<tosaraja> I commented here what my problem is: https://discourse.maas.io/t/pxe-boot-over-trunk-port-at-the-switch/538/10
<tosaraja> seemed to be a semi-known case
<mup> Bug #1866234 changed: [Feature] Remote rackd <MAAS:Invalid> <https://launchpad.net/bugs/1866234>
