#maas 2012-09-17
<smoser> jtv, if/when you see this, you can ssh to ubuntu@10.55.60.130 (bounce through chinstrap). I've imported your launchpad ssh keys there.
<smoser> you can poke around and see the issue, but basically, the following "should work" to get enlist the kvm node:
<smoser>  xkvm --netdev maasbr0,macaddr=:01 --    -drive file=system-01.img,if=virtio -curses
<roaksoax> smoser: you should made that availoable on a wikipage :)
<smoser> ?
<roaksoax> smoser: how you got MAAS working on canonicastack for it to enlist, dpeloy, etc
<smoser> http://bazaar.launchpad.net/~smoser/maas/maas-pkg-test/view/head:/maas-ephemeral-test-quantal.txt
<smoser> that is clsoe.
<smoser> thats basically what i'm doing
<smoser> and that has the maas server on the instance not in any sort of container.
<smoser> i'd like to make it so that the maas server is in a lxc container.
<smoser> i'll improve on that a bit more tomorrow.
<roaksoax> awesome!
<smoser> its pretty close.
<smoser> and i hope to hvae some quantal images at least available that would work
<smoser> the biggest hting i'm waiting on now for quantal is bug 643289
<ubot5> Launchpad bug 643289 in nfs-utils (Ubuntu Precise) "idmapd does not starts to work after system reboot" [High,Triaged] https://launchpad.net/bugs/643289
<smoser> i have all the fixes i need collected at https://launchpad.net/~smoser/+archive/ephermal-fixes
<smoser> but the mountall i'm wwaiting on slangasek for
<smoser> and either getting that is required or i have to hack around it in cloud-init (i have that ready, but i'd rather have the moutnall fix)
<smoser> good night.
<roaksoax> ack
<roaksoax> night scoot
<jtv> smoser: got no access to 10.55.60.130.
<mgz> so, what I was doing before lunch,
<mgz> when testing out schema migrations, is there an easy way to either trigger a rollback, or blow away the db, to go from scratch again?
<mgz> the overhead of reverting a change, creating a new migration, applying that, then removing both is a bit pointless for test data
<rvba> mgz: you can always rm -rf db && make sampledata
<mgz> rvba: thanks, just what I was after
<rvba> np
<smoser> what daemon runs the tftp server?
<roaksoax> smoser: pserv
<roaksoax> maas-pserv
<smoser> do you know what interfaces it binds to?
<roaksoax> smoser: i think is the one with the address of MAAS_DEFAULT_URL
<roaksoax> allenap: ^^
<smoser> what is 'maas-dhcp/maas-dhcp-ip:' result in ?
<smoser> the debconf value (that i added) ?
 * allenap thinks
<roaksoax> smoser: you mean maas-dhcp-addr?
<roaksoax> smoser: tftp is different from dhcp
<jtv> Â¾ different in fact!
<allenap> smoser, roaksoax: It listens on all interfaces, afaict.
<roaksoax> smoser: thought maas-dhcp-addr should be the same as MAAS_DEFAULT_URL address IMHO since it is the same address that clients will contact, say for cloud-init meta-data server
<jtv> dhcp currently listens on all, but is being fixed not to; dns didn't, but is being or has been fixed to listen on all interfaces.
<roaksoax> jtv: the usage of series is because bigjools requested it instead of release, beside the fact of course that there's a release() function
<jtv> I see.  Wish I'd known!
<roaksoax> rvba: idk if you saw but I uploaded the branch that adds the distro_series support. So we can start adding tests :)
<smoser> jtv, https://bugs.launchpad.net/maas/+bug/1047061
<ubot5> Ubuntu bug 1047061 in MAAS "dhcpd.conf next-server set to 127.0.0.1" [Critical,Fix released]
<jtv> smoser: is that the one you were talking about?
<jtv> The configuration problem you ran into?
<smoser> see comment 1 there. that is what i was running into in https://bugs.launchpad.net/maas/+bug/1051626
<ubot5> Ubuntu bug 1051626 in MAAS "tftp import broken" [Critical,Confirmed]
<smoser> right.
<rvba> roaksoax: I've seen that indeed :).  As promised I'll give you a hand with the tests.
<smoser> i'm not sure what '--ip' is supposed to mean to 'maas config_master_dhcp', but a.) i had thought it meant next-server b.) one way or another next-server is wrong.
<jtv> roaksoax: Also, I was wondering: since recently, the master worker sends the list of downloaded installable images to the server.  Maybe that should ultimately become the source of the âchoicesâ list for OS releases.
<jtv> smoser: yeah, I thought that was a little unclear too.  The trick is to read it within the context of âdhcpâ: âthe IP address that serves DHCP.â
<smoser> roaksoax, shoot. i did mean addr, but i was preseeding ip.
<smoser> hm.. one way or another that is busted, but it should have done better.
<smoser> jtv, but who cares what serves dhcp?
<smoser> other than next server.
<smoser> it seems broken that you're requiring both interface to listen too and ip address.
<jtv> Good question.  I'm about as confused about this as you are.
<roaksoax> jtv: right makes sense
<jtv> roaksoax: not saying it has to be that way right now â in fact people might not even like it because it means you don't get offered any operating systems to install until you have some.  But something to keep in mind as an answer to one of my points.
<roaksoax> smoser: liston to would be basically on what interfaces to listen DHCP requests, and ip address is the "next-server" isn't it?
<jtv> No
<jtv> Ah
<smoser> roaksoax, i thought the same thing as you.
<jtv> I think maybe it should be, but isn't yet.
<rvba> next_server = get_maas_facing_server_address()
<roaksoax> jtv: yeah, bigjools mentioned that he would like that to become data driven, but something to do in the future as it would require lots of changes
<rvba> I don't see where that 'ip' is used in the code reallyâ¦ so I'm confused as well.
<jtv> Maybe the ip is just the nodes-facing IP address of the cluster â which will _also_ be the tftp download address once we have proxies set up.
<smoser> can i suggest that people actually try to use code they write?
<smoser> rather than just assuming that if tests pass it works?
<jtv> In which case, yes it would also be the next-server, but wouldn't actually function as one yet until we have tftp proxies.
<rvba> jtv: that's what Julian had in mind indeedâ¦ but where is this used?
<jtv> Scott knows the details.
<jtv> smoser: feel free to send hardware.  :)
<smoser> jtv, canonistack works fine.
<smoser> and a single system is all you need to test the vast majority of this.
<jtv> Then maybe I should try that.  The address you told me to ssh into this weekend didn't let me in for some reason.  :(
<smoser> you have to bounce thorugh chinstrap
<smoser> (i did say that)
<jtv> What a coincidence.
<jtv> Because when you said that I actually did that.
<jtv> Did I mention that it didn't work?
<smoser> i dont have the instance any more , but i assume that your credentials weren't geting through.
<smoser> i 'ssh-import-id jtv'
<jtv> Wellâ¦ maybe this was after you let the instance go.
<jtv> Or it was taken from you, or whatever happened.
<smoser> nah. that was this morning. maybe 30 minutes ago.
<smoser> https://wiki.canonical.com/InformationInfrastructure/IS/CanonicalOpenstack?action=show&redirect=CanoniStack
<jtv> Or evening, as we like to call it.  ;)
<smoser> that is an *extremely* useful resource.
<jtv> Thanks.  Maybe I'll play with it tomorrow.
<smoser> you should set it up.
<smoser> note, even EC2 or HP cloud can also test this tuff.
<smoser> the real value of canonistack is that you can get nested virtualization.
<jtv> That is nice, yes.
<smoser> there are no public clouds to my knowledge that have nested virt support.
<jtv> I dared not run the script you pointed to the other day â it did an apt-get dist-upgrade without confirmation, and if I lose this system, I have nothing.
<jtv> Good thing I spotted it!
<smoser> this is why we have instances.
<smoser> and virtualization
<smoser> ok. i re-purposed bug 1051626
<ubot5> Launchpad bug 1051626 in MAAS "next-server written wrong" [Critical,Confirmed] https://launchpad.net/bugs/1051626
<smoser> i did'nt follow all of what you all were saying above
<smoser> what do we need to do to make dhcp actually funciton.
<smoser> rvba, how can i ask maas what its server ip is?
<smoser> the one it is listening to
<smoser> (and is currently getting written aas 'next-server')
<rvba> smoser: get_maas_facing_server_address()
<smoser> anyway other htan python?
<rvba> smoser: get_maas_facing_server_address extracts it from settings.DEFAULT_MAAS_URL.
<smoser> $ echo 'from maasserver.server_address import get_maas_facing_server_address; print "\n%s" % get_maas_facing_server_address()' | sudo maas shell 2>/dev/null | grep -v "^>>>"
<smoser> 10.55.60.130
<roaksoax> Daviey: so you want me to ditch ipmitool in favor of freeipmi within MAAS right?
<roaksoax> allenap: can you point me to the package and upstream of the package you wanted me to upload?
<allenap> roaksoax: The delay has served you well: it looks like it's not suitable after all. It wasn't suitable for the kind of thing that Francis and Scott had in mind last week, so I've switched to argparse.
<roaksoax> cool
<Daviey> roaksoax: I think it should be considered
<Daviey> :)
<roaksoax> Daviey: i don't mind changing it if necessary
<roaksoax> Daviey: it will require a few changes but it is possible
<Daviey> roaksoax: ideally, we'd support both IMO
<roaksoax> Daviey: do we want to MIR ipmitool and freeipmi ?
<roaksoax> Daviey: not that is is simply to power on/off machines nothing else
<roaksoax> s/not/note
<Daviey> roaksoax: JUST MIR'ing freeipmi seems more sensible IMO.
<Daviey> It's a more active and safer project IMO.
<Daviey> roaksoax: Yeah, so we don't have to worry about kernel integration
<roaksoax> k
<roaksoax> Daviey: we don't need kernel integration when we use ipmitool either, since we are only using to send a command over the network
<Daviey> roaksoax: For the MIR?
<roaksoax> Daviey: worry about kernel integration --> we only need 1 binary
<roaksoax> Daviey: but either way, i'll look into it
<Daviey> roaksoax: right,i mean we are MIR'ing the whole shebang
<roaksoax> indeed
<roaksoax> Daviey: bug #1052056 could you please ack?
<ubot5> Launchpad bug 1052056 in freeipmi (Ubuntu) "[FFe] [MIR] freeipmi" [Undecided,New] https://launchpad.net/bugs/1052056
<guimaluf> I would like to make maas node more sofisticated default settings. the most convinient way is going through cobbler and kickstart files?:
<smoser> guimaluf, well, the going forward way is to basically allow cloud-init to handle that for you.
<smoser> but currently, you'd have to write your own api tool to launch an instance with user-data.
<guimaluf> smoser, is cloud-init a script?
<smoser> https://help.ubuntu.com/community/CloudInit
<guimaluf> smoser, exactly, i'm trying to cutomize via maas.pressed file and maybe puppet. but isn't enough
<smoser> why "isnt enough?"
<smoser> s/?"/"?/
<guimaluf> not isnt enough. but I'm having difficult to find what I want. like partitioning many disks on my nodes. the default partitioning made trought partman is OK, but I can do nothing with the other disks. i'm on this many days and nothing happens...
<smoser> ah. yeah. i remmber. the only way you can accomplish that is via customization of the preseed.
<guimaluf> I know puppet and preseed is enough. I just can find the way...
<guimaluf> smoser, I'm using a for-loop inside preseed file in the early-command, as you said, but this make the installation process freak out!
<guimaluf> and my maas set-up could never give the correct ssh-keys with the cloud-init. I'd to put a echo "ssh-key" >> /root/.ssh/auth_keys in the late command :/
<guimaluf> I dont know how can I use snnipets on the preseed file. On cobbler doc seems so easy. but when I put SNIPPET("asdf"); the installations get broken
<smoser> you're using maas on 12.04 ?
<guimaluf> I would like to know how maas deal with that...
<guimaluf> yep
<guimaluf> I thought the clock syncronization issue would be the only problem getting ssh-keys, but isnt the only one.
<smoser> well, the clock issue will most deifnitely block you
<smoser> b
<smoser> ut there are other issues potentially to
<smoser> for some reason your installed node is not able to reach the maas metadata service
<smoser> possibly routing
<guimaluf> hmmmm make sense... the metadata service is 169.254.169.254? may I should create a iptables rule for that...
<guimaluf> I'm also using openstack, and this is the metadata server and it points to IP:80. which route should maas metadata points to?
<smoser> maas has its own metadata service. 169.254.169.254 is the openstack metadata service.
<guimaluf> and how can I know wich is the address?
<guimaluf> I think this is happening cause my dhcp-server isnt the maas server
<guimaluf> so I need to put a rule on firewall to redirect metadata server to my maas server right?
<roaksoax> guimaluf: check that MAAS_DEFAULT_URL has the correct address in /etc/maas/maas_local_settings.py
<Daviey> roaksoax: Forwarded to jdstrand
<roaksoax> Daviey: k thanks!
<guimaluf> roaksoax, is correct
<smoser> guimaluf, and the nodes need to be able to get to the MAAS_DEFAULT_URL
<guimaluf> they are.
<guimaluf> they can do the PXE boot, ping, ssh, etc.
<smoser> well, then the next thing is to get into a node and run the cloud-init maas datasource
<smoser> there is a file in /etc/cloud/cloud.cfg.d/ with content in it for the acl.
<smoser> you can run that and it should show errors also.
<guimaluf> do you mean run this command? # cloud-init maas datasource
<guimaluf> root@node-782bcb77e1d4:~# cloud-init maas datasource
<guimaluf> bad command maas. use one of ('start', 'start-local')
<smoser> no. sorry.
<smoser> python /usr/share/pyshared/cloudinit/sources/DataSourceMAAS.py
<roaksoax> smoser: will you make quantal images available for commissioning/enlistment?
<smoser> working on that right now. they dont work
<smoser> :)
<smoser> biggest thing i'm waiting on is mountall
<roaksoax> smoser: hehe ok, I can make available a package that has quantal support for you to test if you dont want to manually apply the patches
<smoser> https://launchpad.net/~smoser/+archive/ephermal-fixes
<smoser> maas is actually ok.
<roaksoax> k ;)
<smoser> i'll upload openiscsi today
<roaksoax> Daviey: sill around?
<roaksoax> smoser: ok cool!
<Daviey> roaksoax: i am
<roaksoax> Daviey: where did you published the squashfs image? :)
<roaksoax> publish*
<Daviey> roaksoax: I haven't.. i manually exposed it via cp'ing it to a place on cdimage
<roaksoax> Daviey: is it still exposed? Are we going to keep exposing it?
<roaksoax> Daviey: or should I just use the mini.iso?
<Daviey> mini.iso doesn't ship the squashfs :)
<roaksoax> ah i thought it did
<roaksoax> Daviey: in that case, I think it would make sense to make the iamge available somewhere in cdimage
<roaksoax> Daviey: that way we wont have to download the whole ISO
<Daviey> hmm
<Daviey> http://cdimage.ubuntu.com/ubuntu-server/daily/current/quantal-server-amd64.squashfs
<Daviey> It's only 61M
<Daviey> roaksoax: That is temp' do not expect it to be there tomorrow
<roaksoax> Daviey: ok cool thanks
<roaksoax> smoser: do you think it would be a good idea to change wget on maas-import-pxe-files to rsync instead?
<smoser> roaksoax, no.
<smoser> for what, specifically?
<roaksoax> maas-import-pxe-files
<smoser> what files
<roaksoax> to donwload the required files
<roaksoax> initrd.gz
<roaksoax> linux
<roaksoax> etc
<roaksoax> etc
<smoser> url? example?
<smoser> why would that be superior to wget
<roaksoax> smoser: http://paste.ubuntu.com/1211666/
<roaksoax> smoser: not just superior, but if a download process is broken or if we already have the latests image, then it wont download from 0% or re-download
<smoser> is that stuff available via rsync ?
<smoser> i dont think its really that big of a deal.
<roaksoax> smoser: yeah
<smoser> you're looking at, what, 100M there?
<smoser> at max.
<smoser> actually.
<smoser> no.
<smoser> we do not want rsync
<smoser> due to it being less proxyable
<roaksoax> ok
<smoser> ie, you get the resume for all practicle purposes for free if you set http_proxy
<smoser> now, for the lcoud-images, we coudl/should make those resume better.
<roaksoax> right
<roaksoax> i'm also trying to avoid the fact of having to download those files each time
<smoser> use a proxy, silly.
<roaksoax> lol will have to
<roaksoax> smoser: did you make any change to the boot process to display the kernel parameters on enlistment/commissioning?
<smoser> yes.
<roaksoax> smoser: now, however, I don't see any ouput been displayed on the image itself whicle provisioning (as in I no longer see how it downloads maas-enlist, etc etc)
<roaksoax> nor during commissioning
<smoser> its going to ttyS0
<smoser> which i think is actually more correct in this environment.
<smoser> roaksoax, do you agree?
<roaksoax> smoser: i have no say on this, It doesn't really matter to me
<roaksoax> smoser: so yes, whichever you think is best, I agree
<smoser> well, console is almost certainly not being logged as text in any reasonable manner
<smoser> console as in 'tty1' (video console)
<smoser> ttyS0 might be.
<roaksoax> yeah i agree that's probably the best place
<smoser> roaksoax, i just built a quantal image
<smoser> using my ppa i pointed at
<smoser> and have enlisted 3 systems
<smoser> whoowhoo!
<smoser> using the daily ppa of maas from this morning.
<roaksoax> smoser: awesome!
 * roaksoax brb
<smoser> roaksoax, hm.
<smoser> can't i somehow deploy a node from the ui?
<roaksoax> smoser yes you can
<smoser> hm..
<roaksoax> smoser not quantal though
<smoser> oh. ok.
<smoser> wait
<roaksoax> smoser but you wont be able to release it nir delete it if you do so
<smoser> roaksoax: ssh -L 10080:localhost:80 10.55.63.64
<smoser> tell me if what you see on http://localhost:10080/MAAS for 'node-525400123403' is other than expected
<roaksoax>   smoser brb xhsnging locstiond
<smoser> k
<roaksoax> smoser: sorry about that
<smoser> no worries
<roaksoax> smoser: what is it that you wanted me to look at?
<smoser> well, one of those nodes is commissedon
<smoser> how would you push a button to install it?
<roaksoax> smoser: you can't start it? or it can't commission? or you need it to commission?
<roaksoax> smoser: or the button is there but it is greyed out?
<roaksoax> smoser: if you add a node from the WebUI there's no start button IIRC
<smoser> the start button is greyed out
<smoser> (you can look at the ui with the ssh above)
<roaksoax> smoser: did you add an SSH key?
<roaksoax> smoser: i think you need to add an ssh key in order for it to allow you to start the machine
<smoser> roaksoax, no i did not add ssh key
<nov503> hi, when i bootstrap juju, i forget to put the public key in maas. Now the system is installed but the key is not pushed to the system and I can't login into it.  Is there any way I can redo this?
<matsubara> smoser, hi there
<matsubara> smoser, I'm enlisting a node in the Lenovo lab but once it boots the image from the MAAS server it gets stuck waiting for eth1 to become ready. Did something change recently in the image that might cause that?
<roaksoax> smoser: so I guess you figured by now that you need to add an ssh key in order to start them
<smoser> matsubara, nothing should be waiting on eth1. and the image hasn't changed (unless you're using 'daily', which would have taken configuration).
<smoser> you could be hitting a bug i supposed could exist.
#maas 2012-09-18
<matsubara> smoser, how odd. is there anything I can do to debug this further?
<matsubara> smoser, I don't think it's using the daily image, MAAS images have been configured with maas-import-pxe-files
<smoser> matsubara, can you get console logs ?
<smoser> i'd like to see them.
<smoser> what version of maas are you using ?
<matsubara> smoser, I'm looking at the console through the Raritan java client but it doesn't seem to allow me to change the tty or boot into recovery mode
<matsubara> smoser, I'm using the latest package from the daily builds archive:  maas - 0.1+bzr1002+dfsg-0+1007+87~ppa0~quantal1
<smoser> matsubara, can you get ttyS0 logs ?
<smoser> (serial console)
<matsubara> smoser, how could I get those?
<smoser> what made you think yo uwere waiting on eth1 ?
<smoser> well, its possible there is serial over ethernet or some way to get at a serial console.
<matsubara> the console is halted at the eth0: link become ready
<matsubara> smoser, I can show you an screenshot, just a sec
<smoser> matsubara, ok. if the console is all you have to debug, and you can't get a serial console, then you'll want to edit one of the maas files and remove 'console=ttyS0'
<matsubara> smoser, https://dl.dropbox.com/u/551281/node-eth-ready.png
<smoser> easiest thing to do is just add 'console=tty1' to all of the APPEND lines in the template files in /usr/lib/python2.7/dist-packages/provisioningserver/pxe/
<smoser> that will make your graphical console the place where messages get written.
<smoser> i made the change to use serial console
<smoser> which, honestly, i think is right.
<smoser> no one will ever have text logs of a graphical console
<smoser> matsubara, i dont think anything there is unexpected.
<smoser> you're just not seeing output becausae its going to the serial console.
<smoser> did you follow the above ?
<smoser> how to change the console= ?
<smoser> matsubara, ^
<matsubara> smoser, yes, let me change those files
<smoser> matsubara, you gonna be around a while?
<smoser> i have got to step away for 20 minutes at least.
<matsubara> smoser, like this:  APPEND {{kernel_params(arch="amd64") | kernel_command | console=tty1}} ?
<smoser> but i can come back or we can pick up tomorrow.
<smoser> i'd just add it outside the }}
<matsubara> smoser, yes, I'll be around
<smoser> APPEND {{kernel_params(arch="amd64") | kernel_command}} console=tty1
<smoser> (basically just append that string to the end of those 'APPEND' lines)
<matsubara> smoser, cool. did that and am rebooting the node
<matsubara> smoser, https://dl.dropbox.com/u/551281/node-eth-ready%3Dconsol-tty1.png
<matsubara> so I guess what's failing is maas-enlist and not the network interface readyness
<smoser> matsubara, you should get mor output than that.
<smoser> hm..
<matsubara> smoser, that's all I got with that change
<smoser> i'm not sure what would be saying 'hostname' like that.
<smoser> hm..
<smoser> the hostname is 'maas-enlist' because that is what the kernel cmdline says to set it to.
<matsubara> smoser, I did notice that console=tty0 was still in the parameters for the kernel when the node booted
<smoser> hm..
<smoser> "no response after 2 seconds" giving up
<smoser> i didnt think i saw that bfore
<smoser> oh, wait, but it does retry, i'm almost certain of that.
<smoser> hm..
<smoser> roaksoax, is there anyway we can get ttyS0 output in that lab?
<smoser> ipmi or something?
<smoser> matsubara, is there any doc on that lab? i've not played in it.
<matsubara> smoser, https://wiki.canonical.com/Launchpad/QA/MAASLenovoLab
<smoser> matsubara, you added 'console=tty1' to each of those files ?
<smoser> you should see hte kernel cmdline printed to the console
<smoser> and you can verify that the last thing on it should be 'console=tty1'
<smoser> we can also add '--verbose' and 'debug=1
<smoser> and that will give you no shortage of data
<matsubara> smoser, I added to both APPEND lines. let me add those two other options
<smoser> which file ?
<matsubara> /usr/lib/python2.7/dist-packages/provisioningserver/pxe/
<smoser> /usr/lib/python2.7/dist-packages/provisioningserver/pxe/config.commissioning.template
<matsubara> sorry, yes
<smoser> is probably the rigth one for enlistment and commissioning
<matsubara> rebooting
<matsubara> smoser, https://dl.dropbox.com/u/551281/node.png
<smoser> matsubara, can you just let that sit there? it should get furhter eventually.
<smoser> something else shoudl happen. it might be 300+ seconds. but *something* should happen
<smoser> matsubara, well... good news and bad news.
<smoser> good news, i just successfully enlistsed a node following http://bazaar.launchpad.net/~smoser/maas/maas-pkg-test/view/head:/maas-ephemeral-test-quantal.txt
<smoser> without using the 'daily' ephemeral image (which is what you were doing).
<smoser> matsubara, ah. i wonder.
<smoser> did you knwo that you have to fix dhcp ?
<smoser> h..
<smoser> hm..
<smoser> i'll look more at this tomrrow with you if thats ok.
<smoser> but i'm not really sure what i could have regressed.
<matsubara> smoser, what fix to dhcp?
<matsubara> smoser, if I let it sit there it stays there, doesn't seem to time out
<roaksoax> smoser: yeah ipmi should be your best bet if those have ipmi
<roaksoax> her
<smoser> well, in my setup next-server got set incorrectly.
<smoser> matsubara,
<smoser> so i had to fix 'next-server' in /etc/dhcp/dhcpd.conf
<matsubara> smoser, right, I fixed that running dpkg-reconfigure maas-dhcp
<smoser> that wouldn't get fixed by that.
<smoser> i dont think
<smoser> or if it does, then i misunderstand the problem.
<matsubara> smoser, I ran dpkg-reconfigure maas and then dpkg-reconfigure maas-dhcp to get the proper dhcpd.conf written
<smoser> ah. ok. so then you have dhcpd running on the same interface as maas-server
<smoser> (ie, eth0 for you probably)
<jtv> (meanwhile, any new information on the âcpâ problems in maas-import-ephemerals?)
<matsubara> smoser, yes
<smoser> matsubara, how long did you let it sit at that ?  and did you do so with --verbose and debug=1?
<smoser> you may have to let it set for 5 minutes.
<smoser> but something should time out.
<matsubara> smoser, nope, I let it sit for awhile, I guess more than 5 min. I can try it again
<smoser> matsubara, the other thing we can do is take the 'console=ttyS0' out of /usr/share/pyshared/provisioningserver/kernel_opts.py and restart maas-pserv
<smoser> but i really dont think thats going to have an affect.
<smoser> the only other guess i have is that I changed 'ip=dhcp' to 'ip=::::<hostname>'
<smoser> but my test here verified that that generally works even on the precise image.
<smoser> to be clear, I changed kernel paramters, adding 'console=ttyS0'
<jtv> smoser: sorry to interrupt â maybe you thought my questions were rhetorical or something, but I really need to know.  Is it only for our own dhcpd instance that the leases file needs to be root-owned?  If so, how can we work around that?  If not, how does the regular dhcpd write to it?
<smoser> and 'console=tty1'
<smoser> its only the leases file.
<jtv> Stop.
<smoser> it opens it for wrigint before dropping permissions is what I suspect
<jtv> I am asking a question about the leases file.
<jtv> You answer with âit's only the leases file.â
<jtv> I think we're still talking at cross purposes.
<smoser> "regular dhcpd" writes that file as root (look at /etc/init/dhcp-isc-server.conf)
<jtv> !
<smoser> we need to do exactly the same thing.
<jtv> But the dhcpd doesn't run as root, does it?
<smoser> it opens it for wrigint before dropping permissions is what I suspect
<jtv> What is wrigint?
<smoser> writing
<jtv> Then don't type it wrong twice!
<jtv> If you repeat an obvious mistake, you reinforce the notion that you're doing it deliberately â leaving me with the puzzle of what you mean if not the obvious.
<smoser> sorry.
<smoser> but if you looked at /etc/init/dhcp-isc-server.conf or actually played with this, you'd see.
<jtv> I did look at dhcpd-isc-server.confâ¦ and in fact it's where I copied my own version from.
<smoser> http://paste.ubuntu.com/1212215/
<smoser> chown root:root /var/lib/dhcp /var/lib/dhcp/dhcpd.leases
<smoser> chown root:root /var/lib/dhcp/dhcpd.leases~
<smoser> where yours did:
<smoser> chown maas:dhcp $LFILE
<smoser> chmod g+w $LFILE
<jtv> Interesting â I wonder if I just missed that comment.
<jtv> Nope: the comment is not there in the version of isc-dhcp-server that I have installed!
<matsubara> smoser, not sure if it changes anything but I'm running this on quantal (I upgraded the QA lab to quantal last Friday)
<jtv> The version I get installed chowns the leases file to dhcpd:dhcpd.
<smoser> matsubara, well, it should not hcange anything.
<jtv> So this looks like a Quantal change.
<jtv> What I did was apparently right for Precise, and what you ran into was new to Quantal.  I wonder why they made that change.
<smoser> it would seem potentially a change in behavior from upstream 4.1.ESV-R4 -> 4.2.2
<roaksoax> jtv: cause it is usually better to run a daemon as a user and not as root
<matsubara> smoser, apparently it doesn't time out. it's been stuck there for more than 5 min
<matsubara> smoser, last message is eth1: no IPv6 routers present
<smoser> thats random.
<smoser> it seems to me like you're not getting a dhcp response.
<smoser> or you got one on the wrong interface.
<smoser> but i really think the former.
<smoser> roaksoax, it runs as non-root in precise also.
<smoser> it really seems like a bug (regression) to me that their code now opens the leases file before it drops its permissions.
<smoser> but, that is the way it is, and we'll just have to deal with that or come up with some solution that works both on precise and quantal.
<smoser> matsubara, see above.  again, i can poke at this some tomorrow.
<matsubara> smoser, ok. I'll ping you. thanks!
<matsubara> it's strange because it does get the IP adress and gets the image from the tftp server
<roaksoax> smoser: most likely, the changelog doesn't seem to provide any hint of the change on permission for the leases file though
<smoser> upstream changelog?
<smoser> the ubuntu bzr log is screwed up due to the importer sucking
<smoser> i already blamed mdlesuer for something that wasn't his fault as a result :)
<roaksoax> heh
<roaksoax> smoser: i'm checking on debian's changelog
<jtv> roaksoax: that's the funny thing â dhcpd was _already_ running as its own user.  The change I'm wondering about is that the leases file must now apparently be owned by root rather than by the one user that's supposed to read and write the file.
<roaksoax> jtv: right, so I'm wondering if this was due to a recent upload, and if so, have you identified which one is it?":
<roaksoax> jtv: this could also be related to the fact that we are running our own dhcp server too
<jtv> roaksoax: those are exactly the answers I've been trying to get out of Scott.  And now it finally turns out that he's been looking at a different version of the package than I got.
<roaksoax> lol
<jtv> It turns out that the leases file needs to be root-owned _in the regular Quantal isc-dhcp-server package_.
<jtv> Not funny â cost me days off this end of my life and probably a few years off the other end.  âWhy don't you just look at the file?  It's so simple.  I'm not going to answer direct questions.â
<jtv> Well in retrospect maybe it is a little funny.
<jtv> Anyway, the Quantal package's upstart script chowns the leases file to root, and has a comment saying that this is required.  The precise version didn't have any of that.
<jtv> So it's not related to the fact that we're running our own instance â it just complicates running our own instance.
<roaksoax> jtv: right, but if we are running our own version, it still meeans we assign permissions as maas:root or maas:dhcp
<jtv> Well that's the thing: _something_ in the package seems to be requiring root:root, so apparently it has to be root:root.
<jtv> In Quantal.
<jtv> But making it root-owned may actually break the Precise version.
<roaksoax> jtv: right, so it is simply different permissions for each verison of the package
<jtv> Can we do that easily?
<jtv> roaksoax: does that mean I should just propose separate (but similar) branches for the packaging and packaging-precise branches?
<roaksoax> jtv: the precise packaging branch has changes stacked on top of the quantal branch
<roaksoax> jtv: so the process should be propose to quantal
<roaksoax> then apply precise changes and commit to precise
<roaksoax> or propose to precise too
<jtv> OK I'll focus on getting it working on quantal then.
<roaksoax> jtv: ok, let me know if I can help with anything (of course i'd take care of it tomorrow_
<roaksoax> jtv: or just drop me an email with what's needed to get changed and I will take a look at it tomrorow
<roaksoax> now i'm off to bed
<jtv> Thanks and good night!
<rbasak> allenap: I have an issue with gen_pxe_template_filenames. I need an ARM-specific version of config.template, but this isn't currently possible. See http://bazaar.launchpad.net/~maas-maintainers/maas/trunk/view/head:/src/provisioningserver/pxe/config.py#L45
<rbasak> allenap: can we get rid of config.template altogether and require every template to have a purpose?
<rbasak> alexmoldovan: or alternatively have a config.template.{arch} fallback before config.template?
<rbasak> uh, allenap
<allenap> rbasak: First thing, the docstring lies; config.{purpose}.template will always be tried before config.template.
<allenap> rbasak: Ignore that.
<allenap> I am very tired right now :)
<allenap> rbasak: If you mean you want the same template for multiple purposes, then I suggest using symlinks.
<allenap> rbasak: These already exist for other templates.
<allenap> Where these equals symlinks.
<rbasak> I don't think that solves my problem
<rbasak> I need config.template to be different on ARM
<allenap> rbasak: config.arm.template with symlinks for each purpose?
<rbasak> So we either need to drop config.template and use specific purpose templates only (in which case I can use the existing override), or we need to add an extra override
<allenap> I don't really understand the problem.
<rbasak> We could do that, but then it wouldn't be parallel to x86
<rbasak> If we do that, then we want config.template with x86 symlinks for each purpose too
<rbasak> I want to do the same as what's there already with just the exception for arm present, rather than arranging everythign there differently for arm and thus confusing future work
<allenap> rbasak: I don't think that's a problem - not being symmetrical - but I think I still don't really see what the issue is. Another way to do it might be:
<allenap> get rid of the {purpose} lookup, and instead pass purpose in to the template's namespace. Then the template can choose what to render.
<allenap> rbasak: I think that actually makes more sense in terms of making these templates useful for multiple architectures.
<allenap> Enabling a new piece of hardware would mean providing templates for all purposes on its arch, not just a subset.
<rbasak> allenap: that's a fairly hefty change and I'm not sure what benefit it would give us given where we are right now. We don't know what'll happen to the boot purposes in the end either, right?
<rbasak> allenap: I think I'd prefer to add a fallback to config.<arch>.template which I know won't break anything
<rbasak> (and is a trivial change)
<allenap> rbasak: Yeah, I still don't see why it's needed. It complicates the lookup, which can already be hard to follow. Just use symlinks for now. There are three boot purposes to make links for : commissioning, install, and local.
<rbasak> allenap: so we already have a config.commissioning.template and a config.local.template
<rbasak> allenap: can I just rename the existing config.template to config.install.template then?
<rbasak> allenap: then I can have easy armhf overrides as necessary
<allenap> rbasak: Yeah, that makes sense. That was your original suggestion too. Sorry, I'm not in a fit state to field questions today!
<rbasak> allenap: no worries. I wasn't sure if there were other boot purposes too before. I'll test and get a merge proposal in.
<allenap> rbasak: get_boot_purpose can also return "poweroff", but this isn't handled anywhere. That's returned for nodes that really ought not to be booting.
<rbasak> allenap: is that just an fyi or will it affect my proposed change?
<rbasak> AIUI, I can ignore that?
<allenap> rbasak: fyi
<allenap> Yeah.
<mgz> can I mark my own mps approved if they have an approve vote and I've done the requested changes?
<rbasak> Right. Thanks!
<allenap> mgz: Yes.
<mgz> allenap: ta
<allenap> mgz: For small changes you can +1 and land your own mps too if waiting for a review is going to block you.
<rvba> mgz: don't forget to set the commit message otherwise the MP won't be picked up by tarmac.
<mgz> rvba: also ta
<mgz> "[bug=]"... seriously?
<mgz> not pulling the author/bug details from bzr is bad enough, but we want to pander to commit log parsers so dumb they can't cope with a missing field?
<mgz> or is tarmac adding that?
<rvba> Yep, tarmac does that.
<mgz> okay, /me bops tarmac on the head for being silly
<smoser> this make any sense to anyone
<smoser> https://bugs.launchpad.net/maas/+bug/1051626
<ubot5> Ubuntu bug 1051626 in MAAS "next-server written wrong" [Critical,Confirmed]
<smoser> see my last comment there. i'm not sure what is making the pxe boot take a different path
<smoser> allenap, where is your maas cli branch ?
<smoser> never mind
<smoser> https://code.launchpad.net/~allenap/maas/command-line/+merge/124704
<roaksoax> rvba: btw.. were you able to look on the release support branch?
<allenap> smoser: Weird indeed!
<rvba> roaksoax: we talked about it this morning during the standup.  Jeroen pointed out that you should use the new model BootImage, instead of getting the list of releases from the command line tool.
<roaksoax> rvba: we are not getting the releases from a command line tool
<roaksoax> rvba: the realeases are being get from python-distro-info
<rvba> roaksoax: ah right, I see that now.  I was just wonder were that UbuntuDistroInfo was coming from.
<rvba> roaksoax: still, BootImage should probably be used instead.
<roaksoax> rvba: what's that now ?
<rvba> roaksoax: src/maasserver/models/bootimage.py
<roaksoax> rvba: right, so hold on, how we want to obtain the releases from what boot images we have available, since we should obtain the bootimages from the releaes that we have available
<roaksoax> rvba: i mean... we should obtain images from release, not release from images available
<smoser> allenap, at the risk of seeming completely stupid.
<smoser> how can i play wiht maascli
<roaksoax> jtv: still around?
<rvba> roaksoax: maas-import-pxe-files should populate BootImage.
<rvba> and maas-import-pxe-files uses distro-info.
<allenap> smoser: Branch lp:~allenap/maas/command-line, make, then use bin/maascli api login --help to get started.
<allenap> smoser: It hasn't landed yet :-/
<roaksoax> rvba: right, but IMHO, maas-import-pxe-files should obtain the images from the releasea MAAS knows about, not the other way around
<smoser> allenap, well, 'make bin/maascli' was failing for me
<smoser> i had'nt 'amke install-dependencies' yet
<roaksoax> rvba: so maas-import-pxe-files should obtain the releases tht MAAS support
<roaksoax> rvba: so maas should determine what releases it supports, not a helper script
<smoser> but truthfully, the point of 'make' is that it would have recognized i'd not done that :)
<smoser> plus, i already have maas installed on the system via package. i hate pypy
<rvba> roaksoax: your suggestion makes sense to me.
<smoser> anyway, i'm getting there.
<roaksoax> rvba: ok, so we really need to get something in asap as it is really delaying my work
<roaksoax> rvba: improvements can always con after we have the main parts in
<roaksoax> such as better determining the avaalble releases
<rvba> roaksoax: granted.  So my suggestion is this: hardcode the available versions for now: XXX = ['precise', 'quantal']
<rvba> roaksoax: the rest can stay as is.
<roaksoax> rvba: OK
<roaksoax> rvba: do you also want split braches?
<rvba> roaksoax: you could simply split that branch into two: one for the db change and one for the rest but I'm ok with one branch if that's easier for you.
<smoser> rbasak, lp:~smoser/maas/maas.ubuntu.com.images-ephemeral now has my pushed branch
<roaksoax> rvba: i'll split it for better understanding
<smoser> i hadn't updated previously. i thought i had pushed.
<smoser> :-(
<roaksoax> rvba: though, will it get merged before having all the tests addressed?
<rbasak> smoser: I'm having trouble building your PPA mountall with sbuild
<rvba> roaksoax: usually, the tests should be done in the same branch.
<smoser> rbasak, why?
<smoser> (fwiw, what is there is == to what is in lp:ubuntu/mountall at the moment)
<roaksoax> rvba: ok, so that means fixing looooooooooots of them
<rbasak> smoser: http://paste.ubuntu.com/1213219/
<smoser> but note, that lp:ubuntu/mountal != whats in the archive.
<rbasak> smoser: looks like it wants plymouth-dev instead of libplymouth-dev
<rbasak> smoser: http://osdir.com/ml/general/2012-03/msg44302.html looks like the same problem
<rvba> roaksoax: really?  Since there is a default release, I don't expect this to break that many testsâ¦
<roaksoax> rvba: the new attribute brekas them I think
<roaksoax> rvba: i'll have to recheck
<smoser> rbasak, you're trying to build in quantal, right?
<smoser> yeah, looks like it.
<smoser> strange.
<rbasak> in a quantal chroot, in precise
<rbasak> I found --resolve-alternatives
<rbasak> trying it now
<rvba> roaksoax: only 2 failures.  We should manage :)
<rbasak> OK that seems to have worked
<roaksoax> ok cool
<roaksoax> lol
<rbasak> Looks like it's intended sbuild behaviour
<roaksoax> rvba: alright, I'll do the changes and re-submit the merge proposal(s)
<rvba> roaksoax: cool.  One more thing, let's set the default to be '' instead of None so won't have to check for both every time we want to know if the value is empty.
<roaksoax> rvba: ok cool
<rbasak> smoser: http://people.canonical.com/~rbasak/mountall_2.41~ppa415_armhf.deb but I can loopback mount the ephemeral image once it's installed to stick that in, right? And you want me to regenerate an image from lp:~smoser/maas/maas.ubuntu.com.images-ephemeral and test with that?
<smoser> rbasak, yeah, pull the m.u.c branch. then edit ARCHES to put armhf in it.
<smoser> and run
<smoser> or, you dont really need all the launcher stuff
<smoser> just download the .tar.gz file, extract and then run
<smoser> ./maas-cloudimg2ephemeral disk.img arm-kernel arm-initrd arm-manifest
<smoser> and it should handle it
<smoser> (then mount loopback and dpkg -i the mountall)
<rbasak> What .tar.gz file? Will a branch checkout do?
<rbasak> smoser: ^^
<smoser> working on it
<smoser> rbasak, http://paste.ubuntu.com/1213255/
<smoser> it looks a lot like that
<smoser> but then add the moutnall
<smoser> and that is not working for me on amd64 on quantal right now
<smoser> as the apt-add-repository is failing
<rbasak> smoser: I'm not with you
<smoser> no?
<rbasak> smoser: we're trying to get me to generate an armhf ephemeral image, right?
<smoser> yes
<rbasak> what's nelson?
<smoser> my local '$mirror'
<rbasak> what can I use instead?
<smoser> cloud-images.ubuntu.com
<rbasak> cloud-images.u.c?
<rbasak> ok
<rbasak> smoser: so I don't run the command on the first line, right?
<smoser> rbasak, shoot.
<smoser> right.
<smoser> do not run the first line
<smoser> only subsequent
<smoser> bad paste
<rbasak> ok
<rbasak> almost there
<rbasak> discovering some dependencies - qemu-user-static and rsync
<smoser> http://paste.ubuntu.com/1213282/
<smoser> that looks a bit better
<smoser> you should not need qemu-user-static
<smoser> if you're doing this on arm
<rbasak> I'm not
<smoser> and rsync?
<rbasak> A script seemed to use rsync
<smoser> i dont think so
<rbasak> I'm doing this on my test maas machine, which is virtualised amd64
<smoser> ah. you're right . tree2query does
<smoser> rbasak, but for this exercise you dont need tree2query
<rbasak> smoser: it failed without rsync
<smoser> you're nto running tree2query
 * rbasak shrugs
<smoser> shoot
<smoser> and if you're hitting that cod then something else is wrong
<smoser> rbasak, shoot. thats a bug. let me fix that.
<smoser> i'm sorry
<rbasak> it's ok
<rbasak> I can cope with needing to install rsync :)
<rbasak> smoser: dd: writing `/tmp/maas-cloudimg2ephemeral.LKQPwv/mp.K8gUX1/tmp/zero': No space left on device
<rbasak> is that a problem?
<rbasak> or intentional to zero out unused space?
<smoser> intentional
<rbasak> OK so I think I have an image
<rbasak> in ~/dl?
<rbasak> smoser: now what?
<rbasak> smoser: I don't understand the different forms these images can take
<rbasak> This doesn't look like something that maas-import-ephemerals can read, and I don't see an initrd.gz
<smoser> rbasak, it updates $img in place
<smoser> and copied out kernel and intiramfs to the places you told it to
<rbasak> Ah
<smoser> dont use maas-import-ephemerals, just copy those files to the right places.
<rbasak> OK I think I follow
<smoser> rbasak, 39. i think is reasonable.
<smoser> r39 in that branch.
<smoser> almost finished here.
<smoser> rvba, why do you want to hardcode a list of releases?
<smoser> we've solved this problem in distro with 'distro-info' and it magically gets serviced for you.
<rvba> smoser: it's just a temporary measure.  We want a central place to store that information.
<smoser> temporary as in how long?
<smoser> if temporary as in its-going-to-go-in-12.10
<smoser> then use distro-info the shell utility
<rvba> Jeroen has recently created the BootImage table so it sounds reasonable to use that.
<rvba> Temporary as in get-andres-unblocked right now.
<rvba> smoser: definitely not something that should go in 12.10.  I'll talk to Jeroen about that tomorrow.  But BootImage should be populated by maas-import-pxe-files which uses distro-info.
<rbasak> smoser: it's trying to hit archive.ubuntu.com and not ports
<smoser> rbasak, can i see logs ?
<rbasak> smoser: so at least two problems that I can see
<rbasak> It hits archive.ubuntu.com
<rbasak> and resolv.conf is still broken
<rbasak> smoser: I'm EOD+1h now
<rbasak> smoser: but if it'll help I can show you how to test on this machine yourself
<rbasak> It's pretty straightforward
<smoser> rbasak, your'e not booting that image.
<rbasak> smoser: I just this moment realised that
<rbasak> sorry
<rbasak> smoser: so I only see one /var/lib/maas/...disk.img which I've replaced
<smoser> rbasak, restart tgtd
<smoser> and make usre you updated your v/ar/lib/maas/tftp/..... kernel and initrd.gz
<smoser> sorry. i know you're edo
<smoser> edo
<smoser> eod
<rbasak> /var/lib/maas/tftp?
<rbasak> or /var/lib/maas/ephemeral?
<rbasak> the latter I've done
<rbasak> the former comes from d-i netinst, no?
<rbasak> smoser: looks like it's timing out on nonet again
<rbasak> smoser: we need to get it so you can test directly I think
<smoser> rbasak, lets just look more tomorrow.
<smoser> k?
<rbasak> ok
<smoser> i'll try to get in kind of early.
<smoser> and we can poke at it together.
<rbasak> ok, ping me when you're in
<smoser> rbasak, /var/lib/maas/tftp/amd64/generic/precise/commissioning/ is not install though
<smoser> its the kernel copied from import-ephemerals
<rbasak> good point
<rbasak> so I probably just ran the wrong initrd against the image
<rbasak> never mind, I'll try again tomorrow
<smoser> rbasak, shoot.
<smoser> what does os.uname report on arm ?
<roaksoax> rvba: still around?
<rvba> roaksoax: unfortunately, yes :)
<roaksoax> rvba: are you gonna be here long?
<rvba> roaksoax: probably not.
<roaksoax> rvba: so I should start then: https://code.launchpad.net/~andreserl/maas/add_node_distro_series/+merge/125010
<rbasak> smoser: http://paste.ubuntu.com/1213406/
<smoser> rbasak, and uname -m ?
<smoser> actually. that is good enough.
<smoser> gracias.
<rbasak> smoser: armv7l
<smoser> rbasak, sorr to abuse you
<smoser> dpkg --print-architecture
<smoser> prints armhf, right?
<rbasak> smoser: armhf
<rbasak> yes
<roaksoax> rvba: https://code.launchpad.net/~andreserl/maas/distro_series_support/+merge/125012
<smoser> then i dont know what is going wrong with mirror selection.
<rbasak> It might be that I used the wrong initrd
<rbasak> I'll test tomorrow
<smoser> well, that would possibly cause errors, but not *those* errors :)
<roaksoax> rvba: where do I modify apidoc?
<roaksoax> since I'm adding a parameter to "start"
<rvba> roaksoax: in the docstring of the API method.
<roaksoax> rvba: should we explain what it is used for?
<rvba> roaksoax: yes.
<roaksoax> rvba: and finally: https://code.launchpad.net/~andreserl/maas/add_api_parameter_for_ubuntu_series/+merge/125016
<roaksoax> rvba: now, does these two tests satisfy the new methods added on src/maasserver/models/node.py (get_distro_Series and set_distro_series)
<roaksoax> rvba: http://paste.ubuntu.com/1213438/
<rvba> roaksoax: looks ok to me.
<rvba> roaksoax: I'll step out in a few minutes but I'll review your branches tomorrow.  Thanks for all the changes and for refactoring your work into separate branches.
<roaksoax> rvba: no prob ;)
<roaksoax> and thanks for reviewing
<smoser> matsubara, around ?
<smoser> i'm finally into the lenovo lab
* flacoste changed the topic of #maas to: 3 weeks until Final Freeze | Discussion of upstream development of Ubuntu's Metal as a Service (MAAS) tool | MAAS jenkins: https://jenkins.qa.ubuntu.com/job/maas-trunk/
<smoser> matsubara, ping
<matsubara> hi smoser
<smoser> matsubara, hi.
<smoser> sorry. just saw this.
<smoser> i'm poking at the lab right now.
<matsubara> cool
<matsubara> smoser, I'm sharing the terminal with you. did you reinstall maas there?
<smoser> no.
<smoser> i've only edited the commissioning kernel cmdline
<matsubara> smoser, ok. I think it should be fine to boot a node and see the same issue we were talking about yesterday
<matsubara> I thought I had purged the install but it's still there
<smoser> i think your initial thought was right.
<smoser> i think we are waiting on eth1 to come up
<matsubara> hmm so is it a problem with the image itself?
<matsubara> smoser, ^
<smoser> well, sort of.
<smoser> matsubara, yeah. my kernel cmdline changes regressed this.
<matsubara> smoser, let me know if you need help test things out there. Are you using the browser based raritan client?
<matsubara> smoser, or the java client?
<smoser> the browser didnt' work at all
<roaksoax> smoser: i had to install oracle's java client
<roaksoax> or java plugin i mean
<smoser> matsubara, ok.
<smoser> i am running the standalone and it doesn't completely suck
<matsubara> smoser, I'm using the standalone as well.
<smoser> matsubara, so here is what i found
<smoser> my kernel commadnline cleanups regressed this.
<smoser> so i'll submit an mp for that trivial-ish short term fix.
<smoser> and will pursue a better packaging fix.
<matsubara> smoser, cool. thanks
<matsubara> did you file a bug for this?
<smoser> i will do that
<smoser> also, you seem to have a bug or misconfiguration of dns
<smoser> i dont know, but the node thinks its should be able to get dns from 192.168.21.1
<smoser> but that does'nt work
<matsubara> smoser, yeah, dns is not working as it was supposed to. Julian asked me to try a few changes to named.conf.options but I didn't yet because of this issue
<smoser> well, dns does work for me in my tests
<roaksoax> smoser: so enlistment would also be affected maybe if having an external DNS?
<smoser> at least caching portion of dns does
<smoser> roaksoax, i'm confused
<roaksoax> smoser: enlistment tries to detect a DNS server and see whether a host has a DNS entry for it
<roaksoax> smoser: so if cloud-init correctly thinkgs there a DNS, enlistment is affected
<matsubara> smoser, with the changes bigjools suggested to named.conf.options the `host security.ubuntu.com 192.168.21.1` resolves
<roaksoax> smoser: I'll get https://code.launchpad.net/~jtv/maas/packaging-custom-dhcpd/+merge/124594 merged if yoiu dont have any more objections
<roaksoax> comments or suggestions
<smoser> matsubara, roaksoax https://code.launchpad.net/~smoser/maas/lp1052660/+merge/125046
<smoser> ack that would be nice.
<smoser> matsubara, that will fix your issue on that system.
<matsubara> smoser, thank you
<smoser> you will still not have console to the graphical console
<roaksoax> smoser: done
<smoser> to get that you will need to either locally edit files or get https://bugs.launchpad.net/maas/+bug/1044503 fixed.
<ubot5> Ubuntu bug 1044503 in MAAS "kernel command line is not easily customizable" [High,Triaged]
<smoser> rbasak, just saying this out loud so i might remember it.
<smoser> for getting BOOTIF to be pegged to 'eth0' (due to limitation of cloud-init and /etc/network/interfaces)
<smoser> we might be able to make use of the fact that udev reads rules from /run/udev/rules.d/.
<smoser> ie, we can write those in the initramfs
<smoser> ok. i'm out for th enight.
#maas 2012-09-19
<lifeless> smoser: around ?
<lifeless> smoser: I'm curious, in http://bazaar.launchpad.net/~smoser/maas/maas-pkg-test/view/head:/maas-ephemeral-test-quantal.txt , why you're using libvirt, which will run dnsmasq, when you want maas to be managing dhcp and dns
<jtv> jam, jelmer: you're not experts on âbzr builddebâ by any chance, are you?
<bigjools> heh
<jam> jtv: jelmer is, I am not. I don't think he's online for another hour, though
<jtv> Any idea who might be?
<jtv> (And don't say William, because he said to ask former bzr people!)
<jtv> This failure looks similar: http://www.mail-archive.com/openstack-ubuntu-testing-notifications@lists.launchpad.net/msg00290.html
<jtv> Hi rvba
<rvba> Hi jtv.
<jtv> rvba: could you help me with an experiment?
<rvba> jtv: sure
<jtv> The package build seems to have broken.
<jtv> So please, _don't_ update your packaging branch just yet,
<jtv> go into your packaging branch,
<jtv> and type:
<jtv> bzr bd -- -k<your-gpg-key-email-address>
<jtv> Or first, install your build-deps:
<jtv> sudo apt-get builddep maas
<jtv> *build-dep
<jtv> That may install some packages that might be missing.
<jtv> And after that, the âbzr bdâ command line _should_ build a package â but currently doesn't.
<rvba> I don't like installing the maas package on my dev machine but I guess I'll just purge it after the experiment :)
<jtv> No need to install it.
<jtv> Just the build dependencies.
<rvba> Ah right.
<rvba> jtv: http://paste.ubuntu.com/1214273/
<jtv> rvba: then I guess that's a failed experiment...  means you don't have the required bzr plugin.  :(
<jtv> Nobody seems able to help with this at the moment, so I'll just start bisecting.
<jtv> Well, I _have_ started bisecting.
<jtv> Thanks for trying though â it was worth a shot.
<rvba> I can install the right plugin :)
<jtv> It's called builddeb.
<rvba> jtv: looks like I need to install quilt (http://paste.ubuntu.com/1214283/)
<jtv> Ah yes, that too.
<rvba> jtv: no error it seems: (that's the end of the output) http://paste.ubuntu.com/1214288/
<jtv> !
<jtv> What revision is your packaging branch on?
<jtv> 971?
<jtv> No, that's got to be the trunk revision.
<rvba> More like 78.
<jtv> That one's failing for me, I think.
<rvba> What's the error?
<jtv> No wait, I was looking at 87.  :)
<jtv> The patching of the network settings maas_local_settings.py fails.
<rvba> Ok, let me try with that revision.
<jtv> Quilt calls patch, patch says it can't find the file it should patch.
<jtv> Then it gives you the impression that it continues regardless, but the return value is 3, not 0.
<lifeless> bigjools was having that
<lifeless> I think
<jtv> Yes.
<bigjools> yes
<bigjools> I take it the taxi didn't take too long then lifeless
<lifeless> bigjools: apparently not
<lifeless> bigjools: was at the airport at 25 to
<bigjools> nic
<bigjools> e
<lifeless> bigjools: thanks again for the power adapter. SHEESE.
<bigjools> did you go in the tunnel?
<bigjools> lifeless: I saw it an thought I'd better dig up your number, yes :)
<lifeless> there was a tunnel yes
<lifeless> Dunno if its 'the' tunnel
 * jtv forgets what power plugs NZ usesâ¦ not the Australian kind then I take it?
<lifeless> Same
<lifeless> just wouldn't be useful to me if I was in NZ and it was in Julians house.
<jtv> I was lucky to find a converter for that in Buenos Airesâ¦ just prior to getting stuck at the airport for 5 hours or so with only Australian-style sockets for some reason.
<jtv> Ah!
<jtv> Now, _why_ would dh say âunknown sequence get-packaged-orig-sourceâ?
<jtv> lifeless, any ideas?
<lifeless> jtv: http://en.wikipedia.org/wiki/AC_power_plugs_and_sockets#Australian_standard_AS.2FNZS_3112_.28Australasian_10.C2.A0A.2F240.C2.A0V.29 specifically :P
<rvba> jtv: same problem here: http://paste.ubuntu.com/1214295/
<lifeless> jtv: I've no idea, I haven't, and don't plan on, used/using bzr-builddeb that way :)
<jtv> rvba: thanks â that puts it somewhere between r78 and now.
<lifeless> jtv: I'm fairly sure thats not a standard target
<jtv> Clearly it isn't.
<jtv> But then who invokes it and why?
<jtv> Looks like r81 is OK.
<lifeless> check your rules file
<jtv> There is a target of that name there.
<jtv> What am I looking for?
<jtv> r81 is OK, r85 is broken.
<lifeless> jtv: so - http://www.debian.org/doc/debian-policy/ch-source.html - no mention of your custom target.
<jtv> Is it a custom target?
<lifeless> to find what invokes it, you probably need to grep around and follow every possible lead
<lifeless> yes, its not part of the stock debian toolchain
<bigjools> it's a builddeb target
<jtv> That's strange.  William/Steve mentioned the question of whether the package supported get-packaged-orig-source, and having the target in the rules file was more or less the definition of support.
<lifeless> it looks like a builddeb special
<lifeless> https://code.launchpad.net/~jelmer/bzr-builddeb/get-packaged-orig-source/+merge/83980
<jtv> Looks as if the addition of tests broke things: http://bazaar.launchpad.net/~maas-maintainers/maas/packaging/revision/82
<jtv> I need to afk for a bit.  But r82 of the packaging branch seems to be the problem.  It doesn't help that I reviewed it.  :)
<jam> bigjools: so do we need to teach the launchpad email parser about pirate speak? merge: be approved
<jam> rejected could be: "merge: to davy Jones' Locker wit ye"
<bigjools> jam: your MP is going to walk the plank, arrrr
<jtv> jam: what bigjools said.  And likewise if you extend bzr's revision specs to accept âarrrr931â
<jam> :)
<bigjools> the "bring out your dead" van is going down the street
<jam> jtv: there is a rule for 'get-orig-source' vs 'get-orig-packaged-source' I wonder if they could be combined somehow?
<jtv> jam: I have absolutely no idea.
<jam> I wonder if builddeb is thinking it can pass a rule down to 'dh' and it will run the equivalent of make -f debian/rules $RULE
<jam> I would guess offhand that builddeb is ignoring that failure as not supported
<jam> unfortunately our master jelmer is still feeling quite ill today
<jam> jtv: I do see this in the builddeb code: http://paste.ubuntu.com/1214596/
<jtv> Yes, I get that in the output.
<jtv> Maybe it's a simple matter of disabling get-orig-source?
<jam> however, I see no such thing in http://www.debian.org/doc/debian-policy/ch-source.html
<jam> which seems to say 'get-orig-source' is the right thing to do.
<jam> jtv: looking at the bzr-builddeb code, it would be as simple as doing:
<jam> get-packaged-orig-source: get-orig-source
<jam> so the 'make -f debian/rules' will be happy
<jtv> Unfortunately I'm running out of time for experimenting with thisâ¦ do you get the failure too?
<jam> jtv: I'm not sure how to 'build the package' where are you running 'bzr builddeb' ?
<jam> and not (bzr builddeb -S or whatever those things are)
<jam> jtv: I don't see the dh failures, I see 'Trying to run get-packaged-orig-source' which then cleanly falls back to 'get-orig-source'.
<jtv> cd into a packaging branch and run âbzr builddeb -- -k<your-gpg-key-email-address>â
<jam> I'll see if I can trigger the failure you're seeing
<jam> right now it is still exporting
<jam> and doing it from lp:maas even though I have a local copy :(
<jtv> Be sure to try this on r82 or higher.
<jtv> Yeah, it sure likes slow downloads.
<jam> I'm on 87
<jam> yeah, it is re-downloading all of maas
<jam> because that is what 'make get-orig-source'  says to do
<jam> It looks like I broke Jenkins, but I can't get the 10.189.74.2 to load
<jam> to find out any actual details
<jam> and the public one just says "No Changes"
<smoser> lifeless, i do not have libvirt running dnsmasq in that. at least if i did then i had meant to disable that.
<smoser> i chose to use libvirt becaues it fairly simply a.) sets up nat b.) sets up bridges c.) starts the stuff on boot
<lifeless> smoser: it seems highly likely that your emulated network is the cause of the fault, is all.
<smoser> d.) will eventually allow me to plug in virsh power control for a set of systems  (similar to how vdenv does it) and let maas power on and off systems.
<smoser> lifeless, why would you say that?
<lifeless> IIRC the symptoms you had were being unable to reach the tftp server, which is a networking issue, if the tftp server service is running.
<smoser> well, no
<smoser> see the last comment there
<smoser> https://bugs.launchpad.net/maas/+bug/1051626
<ubot5> Ubuntu bug 1051626 in MAAS "next-server written wrong" [Critical,Confirmed]
<smoser> its strange. the tftp *does* work. it *does* get pxelinux.0 in both cases.
<smoser> the only thing i could guess was that pxelinux was making a decision based on the netmask of its IP adn the address of the server.
<smoser> and chaning its behavior.
<smoser> lifeless, does that make any sense to you?
<smoser> because it didn't make any sense to me.
<smoser> and all i could really think was, same as you, it didn't really get the pxelinux.0 file
<smoser> but it says it did.
<lifeless> smoser: sorry, its nearly 1am and I just got off a plane, I'll follow up tomorrow
<smoser> sure.
<smoser> i notcie that i am running a dnsmasq for dns
<smoser> but it is not running dhcp
<smoser> so that is not the issue
<smoser> anyone want to pick this off really quick:
<smoser> https://code.launchpad.net/~smoser/maas/trunk.enlist_minor/+merge/125199
<roaksoax> jtv: maybe it is becuase you issue bzr debbuild instead ob bzr builddeb (or bzr bd)
<smoser> roaksoax,
<roaksoax> smoser: lookin
<roaksoax> looking*
 * roaksoax has a crappy netework connection today :(
<roaksoax> smoser: done
<rvba> roaksoax: Hi there.  jam approved your branches but some tests are still missing.  I'm working on it right now.
<roaksoax> rvba: yeah I saw and got them approved and they got merged
<rvba> roaksoax: all right.  That's you unblocked then.  Gavin and I will work on adding a few tests.
<roaksoax> rvba: awesome thanks
<roaksoax> rvba: now, I've been thinking on getting the available releases vs dynamically adding new ones. I just realized that enums.js is created on packagebuild so if any release is not available during build time, it won't be shown on the UI at all if it becomes available later on, right?
<rvba> roaksoax: indeed.
<rvba> roaksoax: we could add an API method to get the available release and use that method in the UI.
<rvba> releases*
<roaksoax> rvba: yeah I think something like that would be necessary. I have a few improvements ideas too related to maas-import-pxe-files too so i'm trying to write them down and i'll send an email
<rvba> roaksoax: cool
<rvba> roaksoax: now it's my turn, I need your help with a change I need to make in the packaging.  It's related to bug 1050492.  I've created the following MP: https://code.launchpad.net/~rvb/maas/packaging.set-rabbitmq-creds/+merge/125248.
<ubot5> Launchpad bug 1050492 in maas (Ubuntu) "MAAS uses the 'guest' account to communicate with RabbitMQ" [Critical,Triaged] https://launchpad.net/bugs/1050492
 * roaksoax looks
<roaksoax> rvba: so that password is only on maas_local_settings.py?
<rvba> roaksoax: yes.  And then every cluster that will be accepted in the region controller will get these credentials.
<roaksoax> rvba: ok so you want me to generate a password and set it on maas_local_settings.py?
<rvba> roaksoax: that's what I tried to do in that branch yes.  Generate a password, create the rabbitmq user, and then set BROKER_URL in maas_local_settings.py.
<rvba> roaksoax: configure_maas_workers_rabbitmq_user is very similar to configure_maas_txlongpoll_rabbitmq_user.
<roaksoax> rvba: where's the branch?
<rvba> roaksoax: see the MP address I pasted above.
<rvba> https://code.launchpad.net/~rvb/maas/packaging.set-rabbitmq-creds/+merge/125248
<roaksoax> rvba: alright, i'll review it and merge it right after I finish something :)
<rvba> roaksoax: cool, thanks a lot.  I've got a few questions but let me know when you'll be available.
<roaksoax> rvba: give me say 20 mins
<rvba> Sure, no problem.
<rvba> roaksoax: I just realized that if we land this now it will break the package because the cluster controller still relies on the fact that we're using the default credentials to connect to RabbitMQ.  My change needs to be landed when we will have a separate maas-cluster package.
<roaksoax> rvba: ok, so that just made me think something. So cluster controller is the master MAAS, and what are you calling the client MAAS?
<roaksoax> how will the client MAAS know the password to connecto to RabbitMQ?
<rvba> The region controller is the master MAAS.
<rvba> So the plan is this:
<rvba> When a cluster controller is installed, a debconf question asks for the address of the Region controller.
<rvba> Then a script connect to the API of the region controller and says: I'm the cluster controller with UUID=1234.
<rvba> The on the region controller, an admin has to accept that cluster controller.
<rvba> The cluster controller then polls the region controller, waiting for an admin to accept the cluster controller.
<rvba> So the answer of the region controller to the cluster controller is: "hold on, an admin need to accept you"
<rvba> When an admin accepts the cluster controller, then the answer changes (remember the cluster controller is still polling).
<rvba> The answer now contains the credentials so that the cluster controller can now connect to RabbitMQ.
<roaksoax> rvba: right, the anwer that contains the credentials, need to be written on maas_local_settings?
<rvba> The cluster controller will do that each time the service is started, but, in my example, next time the cluster controller starts, it will already be accepted in the region controller so the credentials will be sent right away.
<roaksoax> rvba: right, but when it has the response with the credentials, does it have to write them somewhere? i.e. maas_local_settings?
<rvba> roaksoax: well, yes. For two reasons: a) the region controller need to be able to send tasks via RabbitMQ and b) the region controller need to be able to send the credentials to the cluster controllers.
<roaksoax> rvba: ok, so that process or writing into maas_local_settings will be done wher? upstart?
<roaksoax> or within the django code?
<roaksoax> cause note that packaging cannot do that in that particular case
<rvba> roaksoax: no, the cluster controller will use the credentials to start celeryd: celeryd -borker-url=123
<rvba> broker-url*
<roaksoax> right
<roaksoax> so the package will only install the cluster controller
<roaksoax> and after installation has finished
<roaksoax> then the cluster controller will modify maas_local_settings.py
<rvba> There is no maas_local_settings.py on the cluster side.
<roaksoax> oh ok, but where is this information stored then?
<rvba> It does not need to be stored: the upstart script of the cluster will contact the API of the region controller to get the credentials every time it starts.
<roaksoax> ah!! I see
<rvba> roaksoax: ok, I've added a card on our kb board.  This MP is on hold for now.  We need a separate cluster controller package with all the polling logic in place before we can land this.
<roaksoax> rvba: ok, cool. So now, we need to start figuring out what part of the software is that we want on the region, and what on the cluster
<roaksoax> rvba: so, what does the region does not do in comparison to the current package we have. What does the cluster controller do?
<rvba> roaksoax: indeed.  But that's pretty well defined already.  The cluster contains pserv, the dhcp stuff and celery.
<rvba> roaksoax: Julian started working on that.  He wants to touch base with you guys about it.
<roaksoax> rvba: righjt, but we need to figure out what's common code, and what pieces of the code we need. then we need to split up postinst
<roaksoax> rvba: so for example, maas package should now pull both region and cluster controllers and have everything running in one machine
<rvba> roaksoax: right.
<roaksoax> the maas-region only the region code
<roaksoax> and etc et
<roaksoax> rvba: which means that, do they all have to install src/maasserver? do they all have to install src/provisioningserver? etc etc
<rvba> roaksoax: the region needs all the code.  The cluster needs src/provisioningserver.
<roaksoax> rvba: so region *also* needs src/provisioning server then?
<rvba> roaksoax: yes.
<rvba> roaksoax: that's because of celery.  The signature of the tasks are defined in src/provisioningserver.
<rvba> roaksoax: but maybe we could have a maas-common package with all the code and then maas-region and maas-cluster could contain only the upstart scripts.
<rvba> That's just an idea for now.
<rvba> Julian is the packaging expert on our side :).
<roaksoax> rvba: yeah, well let's see what julian says
<rvba> roaksoax: yep.  I hope he will be able to make progress on this front soon as this is a fairly large change which will require a lot of testing.  Plus it's blocking some work that needs to be done.
<roaksoax> right, this is not gonna be an easy thing though :)
<rvba> It should.
<rvba> roaksoax: you don't overlap much with Julian do you?
<roaksoax> rvba: no I don't unfortunately
<roaksoax> rvba: i don't at all TBH
<roaksoax> rvba: do we also need metadaserver on the cluster I guess?
<rvba> roaksoax: no, that's on the region too.
<roaksoax> rvba: so machines deploying will contact the region instead of the cluster controller to get the meta-data they need, say commissioning?
<rvba> roaksoax: yes.
<roaksoax> rvba: ok, but what if you put the cluster to deploy nmodes on a particular network that you dont want to access the region?
<rvba> roaksoax: I guess we will need to add some sort of proxy in that case.
<roaksoax> rvba: would provisioningserver still be considered django code?
<roaksoax> no right?
<rvba> That's celery code really.
<rvba> It simply contains celery tasks.
<roaksoax> rvba: pr im othjer words, what's considered django code? maasserver metadaserver?
<rvba> Yes, these two.
<rvba> And it's not considered django code, it *is* django code :).
<rvba> Well, python code based on Django.
<mgz> what will the clusters use for storage initially, just the filesystem?
<roaksoax> rvba: so the cluster controller does not need src/maas right?
<rvba> roaksoax: no.
<mgz> I'm not sure what things are going to look like after the first pass of multi-cluster support either really...
<rvba> mgz: I guess so for now, since mongodb has been ruled out.
<mgz> but they run some kind of server that exposes an api?
<rvba> No.
<rvba> They are just celery nodes.
<mgz> so nodes on commissioning will post directly to the region controller?
<rvba> Yes.
<rvba> There is no way around that right now.
<mgz> okay, thanks, that clarifies the scope of what I need to do right now quite a bit.
<roaksoax> rvba: so this is what I'm thinking: http://paste.ubuntu.com/1215097/
 * roaksoax bbl
<rvba> roaksoax: looks good to me.  There is something else: we need a special controller called the master which is in charge of dealing with master tasks like setting up the DNS.
<rvba> roaksoax: Julian mentioned we could use a virtual package for that.  That package would basically be a cluster controller package but configured slightly differently (instead of generating a UUID to send to the region controller, that cluster would be calledâ¦ wait for itâ¦ 'master').
<roaksoax> right
<roaksoax> yeah that'
<roaksoax> s easy to add
<roaksoax> I think i'd need to catch up with him
<roaksoax> anyways
<roaksoax> i'll be back later
<allenap> roaksoax: Hello!
<allenap> roaksoax: How do you feel about creating a new binary package for the cli?
<allenap> roaksoax: I see you're away. I'll email you about it.
<roaksoax> allenap will be available in 10 mins
<allenap> roaksoax: I'll be away in 10 minutes, and there's enough detail that it's worth emailing anyway.
<roaksoax> allenap: k
<roaksoax> allenap: if you happen to see this, tell me where's your CLI and what does it need and I'll create a new package. it is simple enough to do
<roaksoax> smoser: around?
<smoser> roaksoax, here.
<roaksoax> smoser: could you please approve this: https://code.launchpad.net/~andreserl/maas/maas_correct_paths/+merge/125286
<smoser> roaksoax, this grades on me.
<smoser> the right fix to that problem is NOT TO SPECIFY FULL PATHS!
<smoser> why do people do that?
<smoser> why do they want their code to break because a program changes path?
<roaksoax> smoser: i agree we should not need to specify paths, but well... we shoudl raise that upstream
<smoser> why do they not want me to be able to put preferred versions of a program in /opt/bin and do the right thing?
<roaksoax> heh
<smoser> https://bugs.launchpad.net/maas/+bug/1053025
<ubot5> Ubuntu bug 1053025 in MAAS "do not hard code paths to executables" [Undecided,New]
<roaksoax> smoser: i think you are gonna like this:
<roaksoax> smoser: https://code.launchpad.net/~andreserl/maas/maas_packaging_fixe_bzr1030/+merge/125313
<roaksoax> smoser: thanks!!
 * roaksoax lunch
<wkharold> juju issue after successful maas install:
<wkharold> 2012-09-19 18:08:22,490 DEBUG Initializing juju status runtime
<wkharold> 2012-09-19 18:08:22,503 INFO Connecting to environment...
<wkharold> 2012-09-19 18:08:22,783 DEBUG Connecting to environment using maas07...
<wkharold> 2012-09-19 18:08:22,784 DEBUG Spawning SSH process with remote_user="ubuntu" remote_host="maas07" remote_port="2181" local_port="59813".
<wkharold> 2012-09-19 18:08:23,334:3276(0x7f39ca8ec700):ZOO_INFO@log_env@658: Client environment:zookeeper.version=zookeeper C client 3.3.5
<wkharold> 2012-09-19 18:08:23,335:3276(0x7f39ca8ec700):ZOO_INFO@log_env@662: Client environment:host.name=maasctrl
<wkharold> 2012-09-19 18:08:23,335:3276(0x7f39ca8ec700):ZOO_INFO@log_env@669: Client environment:os.name=Linux
<wkharold> 2012-09-19 18:08:23,335:3276(0x7f39ca8ec700):ZOO_INFO@log_env@670: Client environment:os.arch=3.2.0-30-generic
<wkharold> 2012-09-19 18:08:23,336:3276(0x7f39ca8ec700):ZOO_INFO@log_env@671: Client environment:os.version=#48-Ubuntu SMP Fri Aug 24 16:52:48 UTC 2012
<wkharold> 2012-09-19 18:08:23,338:3276(0x7f39ca8ec700):ZOO_INFO@log_env@679: Client environment:user.name=ubuntu
<wkharold> 2012-09-19 18:08:23,341:3276(0x7f39ca8ec700):ZOO_INFO@log_env@687: Client environment:user.home=/home/ubuntu
<wkharold> 2012-09-19 18:08:23,341:3276(0x7f39ca8ec700):ZOO_INFO@log_env@699: Client environment:user.dir=/var/lib/maas/media/storage
<wkharold> 2012-09-19 18:08:23,341:3276(0x7f39ca8ec700):ZOO_INFO@zookeeper_init@727: Initiating client connection, host=localhost:59813 sessionTimeout=10000 watcher=0x7f39c88906b0 sessionId=0 sessionPasswd=<null> context=0x30f5910 flags=0
<wkharold> 2012-09-19 18:08:23,343:3276(0x7f39c55ea700):ZOO_INFO@check_events@1585: initiated connection to server [127.0.0.1:59813]
<wkharold> 2012-09-19 18:08:24,250:3276(0x7f39c55ea700):ZOO_ERROR@handle_socket_error_msg@1603: Socket [127.0.0.1:59813] zk retcode=-4, errno=112(Host is down): failed while receiving a server response
<wkharold> 2012-09-19 18:08:27,587:3276(0x7f39c55ea700):ZOO_WARN@zookeeper_interest@1461: Exceeded deadline by 911ms
<wkharold> 2012-09-19 18:08:27,588:3276(0x7f39c55ea700):ZOO_ERROR@handle_socket_error_msg@1579: Socket [127.0.0.1:59813] zk retcode=-4, errno=111(Connection refused): server refused to accept the client
<wkharold> oops, that's from juju -vvv status after an uneventful juju bootstrap
#maas 2012-09-20
<jtv> bigjools: complication with the specify-nodegroup-when-creating-node story is that we don't give users a way to identify nodegroups apart from uuids.
<bigjools> morning jtv
<jtv> And good morning
<bigjools> yes, we briefly talked about that yesterday
<bigjools> which is why I said to use subnet
<jtv> Which didn't work for cases where we don't manage dhcp.
<bigjools> it can, if the subnet is provided regardless
<bigjools> where provided means configured on nodegroup
<jtv> Yes, that'd help.
<bigjools> did you have any other ideas?
<jtv> Only things like âidentify by uuid but show name and subnet in the UI.â  I still haven't found a way to identify objects _in the API call_ based on something other than id though.
<jtv> The form logic seems to mandate id as the key.
<jtv> I'm trying to get around that.
<bigjools> oh smeg
<jtv> Yeah.  The convenience of frameworks is like the beauty of a Potemkin village.
<jtv> Skin deep.
<jtv> Also, always specifying the subnet feels like it's going to have widespread consequences.
<bigjools> it would be worth asking for more opinions on this
<jtv> I already had a pre-imp with RaphaÃ«l.  He said it was doable to use a different key for passing a nodegroup to the form, so I'm still searching.
<bigjools> I need lunch
<bigjools> back later
<bigjools> jtv: btw I sorted the package build problem
<bigjools> branch up for review
<jtv> bigjools: whoo
<bigjools> https://code.launchpad.net/~julian-edwards/maas/packaging/+merge/125393
<bigjools> not sure I like the tests themselves mind, they seem hard-coded to work in the qa lab
<jtv> bigjools: reviewed
<jtv> Yes, they are hardcoded to work in the qa lab.  I think I reviewed that bit and said the same thing.  But couldn't hold the whole thing up for that, given the circumstances.
<jtv> afk for a bit.
<jtv> Back.
<bigjools> me too
<jtv> Great, then we're both back.
<jtv> Wow, a quick round around the block can really clear the head.
<bigjools> yes
<jtv> I keep skipping that to get work done, and then when there's finally time, it's dark and raining.
<jtv> Making progress on select-nodegroup-for-node, thanks to postgres.
<jtv> But it's like trying to hack your way into a voodoo ritual.
<jtv> Which, in case you've never tried it, is mostly a matter of just trying things.
<jtv> bigjools: currently working on getting the django form to do what I want; we'll also need to figure out what needs doing in order to get a subnet for every nodegroup.
<bigjools> jtv: we'll make it part of cluster registration
<bigjools> jtv: subnet will return many matches on NodeGroupInterface but fortunately one NodeGroup
<jtv> Many, even?
<jtv> BTW since it's easy, I'm making it accept any IP address within the nodegroup's subnet.  So you can pass the node's IP, or the cluster manager's IP within the subnet, or the base address, or the broadcast address, orâ¦
<jtv> Avoids confusion about the bits that just don't matter.
<bigjools> broadcast address?
<bigjools> ok might be ok
<jtv> I notice for example that RaphaÃ«l likes to write addresses like 192.168.1.1/24 where I prefer 192.168.1.0/24.  The difference shouldn't matter.
<jtv> \o/ I built a package!  Thank you again.
<bigjools> :)
<jtv> Now, one issue: how do I represent the nodegroups as labels in the UI, if the label is a subnet and the nodegroup may have multiple subnets?
<bigjools> labels?
<jtv> Labels for the selection of a node's nodegroup.
<jtv> In other words, what is the human-readable identification of a nodegroup?
<jtv> I was thinking of showing subnet and name, but if there are multiple subnetsâ¦
<bigjools> hmmm
<bigjools> I'd just show first subnet/name
<jtv> I could probably just show all, but I don't know how many subnets there might be per nodegroup.
<jtv> I guess right now it's still just one.
<jtv> get_managed_interface() is singular.
<bigjools> yer
<jtv> I wonder why the lovely nodegroup field I added shows up when editing an existing node (when I don't want it) but not when creating a new one (when I do want it).
<bigjools> grar
<bigjools> jtv: I know a man who will know
 * bigjools wonders why the maas-dhcp package depends on the maas package
<jtv> !?
<jtv> Shouldn't that be the other way around?
<jtv> And then maas-dhcp can depend on maas-common?
<bigjools> no, there should be no dependency at all
<jtv> Ah, right.  Not if we want to be able to run appservers without master workers.
<jam> mgz: ping me when you are back from lunch, I decided to reverse the many-to-many to have node.tags rather than tag.nodes.
<jam> It felt more natural to say node.tags.add(tag) rather than tag.nodes.add(node)
<mgz> jam: okay, will update my copy of your branch
<jam> mgz: I'm happy to review or just preliminary look over (and fix up) a branch that you have
<mgz> jam: ta, will post things
<mgz> allenap or rvba: can you take a look at jam's tag-tables mp and see if there's anything that you're not happy with?
<mgz> this is the main bit of interface we'll actually be sticking with, everything else is more temporary
<rvba> mgz: ok, I'll have a look.
<allenap> mgz, jam: It looked good to me a day or two ago. rvba, any Django-expert reservations about tag-tables?
<smoser> rvba, so did we decide what '--ip=' is supposed to do to mean when given to 'maas config_master_dhcp'
<rvba> mgz: jam allenap, that change looks good to me.
<mgz> ace, thanks guys
<jam> mgz, rvba: thanks, submitted.
<mgz> hm, for migrations, should they be strictly linear? so, I should base my branch off any existing migration branches so we don't get two 0026-s?
<jam> mgz: i think allenap is the one to ask, but it does look that way to me
<rvba> mgz: it's very important that you merge trunk first and regenerate the migration if necessary.
<mgz> I'll pull and rebase then, thanks.
<rvba> South puts the complete state of the models in every migration.  It uses the last migration to compute diffs when you change a model.
<rvba> I suppose you can see how wrong this can go :)
<mgz> yeah, just looking at that, why record all models, even the completely unrelated ones?
<rvba> Yeah, it's a bit stupid but even if South was smarter that would not solve all the potential problems.
<rvba> mgz: the rule of thumb is that if you see someone created a migration while you were working on yours, you have to merge and *recreate the migration*.  Rebasing won't be enough.
<jam> mgz: you have to change your needsfixing to approve
<jam> rvba: isn't it possible to rm *my_migration, 'bzr merge theirs/trunk', bin/... --auto ?
<rvba> mgz: because if the other migration added a field, your new migration (if you simply rebase) won't have that field and so the state in the latest migration will be wrong (that new field will be missing).
<rvba> jam: absolutely.
<rvba> That's what I meant by 'recreate the migration'
<mgz> jam: didit.
<jam> allenap, rvba, mgz: I'm looking at adding an API equivalent to Nodes.list() for Tag.list()
<jam> I'm noticing that nodes have some NODE_PERMISSION.VIEW etc stuff.
<jam> should we be setting ownership for tags similarly?
<mgz> hm, I'd say not
<mgz> tags are an adminny thing, but don't really have ownership, whereas nodes may need to be queried by non-admin users
<rvba> I think this will complicate things for little added benefit.
<jam> rvba: I definitely agree it will complicate things. I just don't know the Maas users model very well.
<jam> If it would be a problem that user A created a tag, and user B would have access to change it.
<rvba> jam: is tag editing something that is accessible to all users?
<mgz> rvba, I think not.
<jam> rvba: is tag editing something that should be restricted to specific users? If so, which ones?
<jam> I can give answers, but I don't have the depth of background to know for sure that they are good ones. :)
<jam> we can certainly say must be superuser or somehow marked as admin?
<rvba> That sounds reasonable to me to restrict that to admin users.
<rvba> But I can't say I have looked at the use case in great detail.
<jam> rvba: so there seems to be 'User.is_superuser' and 'User.is_staff'
<rvba> jam: 'is_staff' means 'can access the admin site'.
<rvba> jam: in MAAS, we only use 'is_superuser'.
<jam> right, which sounded like an admin to me
<jam> k
<rvba> roaksoax: Hi Andres.  It turns out we can land the branch we discussed yesterday which creates the rabbitmq user used for celery communications.  Right now, both the celery worker and the MAAS server use the same file to get the broker credentials.  So the change I'm proposing in https://code.launchpad.net/~rvb/maas/packaging.set-rabbitmq-creds/+merge/125248 can be applied right now.
<rvba> roaksoax: I've added (upsteam) a file named contrib/maas_local_celeryconfig.py.  That file is loaded from celeryconfig and should contain the location-specific BROKER_URL.  It's that file that my change in the packaging modifies.
<roaksoax> rvba: alright, I'll look at it later today
<rvba> roaksoax: this works exactly as contrib/maas_local_settings.py works but of course I'll need you to help me out with the packaging branch and the testing as I might have missed some things.
<rvba> roaksoax: cool, thanks a lot.
<roaksoax> rvba: hold on
<roaksoax> rvba: we are shipping a celeryconfig.py and now a maas_local_celeryconfig.py?
<roaksoax> rvba: and that file is symlinked to usr/share/maas/celeryconfig.py
<rvba> roaksoax: yes, I'm ok to change that it you can think of a better way, but this is exactly the same as what we've done with src/maas/settings.py and contrib/maas_local_config.py.
<roaksoax> rvba: cant it just be the same file ? celeryconfig.py and maas_local_celeryconfig.py?
<rvba> roaksoax: well, one is part of the package and the other one is populated at install time.
<rvba> I thought this was the right way to do it.  But I'm happy to do that differently if you think that's better.
<rvba> roaksoax: maas_local_celeryconfig.py only contains the things that are specific to each installation, right now only the BROKER_URL param.
<roaksoax> rvba: i'll take a look first, and then will let oytu know
<rvba> roaksoax: all right.
<roaksoax> rvba: so celeryconfig.py will be installed in usr/share/maas/ and maas_local_celeryconfig.py installed in /etc/maas and symlinked to usr/share/maas right?
<rvba> roaksoax: yes.
<rvba> roaksoax: celeryconfig.py is not meant to be changed by a user.
<roaksoax> rvba: alright
<roaksoax> allenap: ping
<mgz> urk, datamigration hiccough, I need to transfer stuff from metadataserver to maasserver... which are managed seperately by south
<mgz> is there something magic I need?
<mgz> ...the south docs seem to cover it at least
<jam> anyone know a way to get nose to only run the tests associated with one test class?
<jam> I want to add my tests into test_api, but that is 200+ tests that I don't need to run every time.
<mgz> the first arg should extend down from modules into test classes as per -s on bzrlib, no?
<jam> mgz: when I do it (as I think it would look) I get 0 tests run
<jam> it seems to only match at the Module leve
<jam> level
<jam> mgz: bin/test.maas --exclude=Node maasserver.tests.test_api.TestNodesAPI
<jam> for example
<jam> well, remove the --exclude, just a sec
<jam> yeah, still 0
<jam> bin/test.maas maasserver.tests.test_api.TestNodesAPI
<jam> note that if you have a typo
<jam> such as
<jam> bin/test.maas maasserver.tests.test_api.TestNodesAPIXXXX
<jam> then it tells you no-such-attribute
<mgz> ...that's no fun
<jam> mgz: http://nose.readthedocs.org/en/latest/usage.html looks like you need to use a :
<jam>  bin/test.maas maasserver.tests.test_api:TestNodesAPI
<rvba> jam: mgz: you can use ./bin/maas test src/maasserver/tests/test_api.py:TestNodeGroupAPI
<rvba> or even, to run a particular test: ./bin/maas test src/maasserver/tests/test_api.py:TestNodeGroupAPI.test_method
<jam> rvba: yeah, you can use the python path, or the filename path, and then a :Class, it just took me a while to find the ':' magic.
<rvba> jam: there is a note about that in HACKING.txt ;)
<mgz> rvba: I don't suppose you know the exact form of the filenames in NodeCommissionResult
<allenap> roaksoax: pong
<mgz> I'm reading etc/maas/commissioning-user-data but my bash is not good enough to be confident that I understand the exact form
<mgz> it looks like it should be 01-lshw.out, but will it be absolute including /tmp or does one of the bash magic things make it relative?
<jam> mgz:       fargs="$fargs --file=${file##*/}"
<jam> I think that means strip all the beginning
<jam> everything up to a '/'
<jam> mgz: see man bash, and /##
<jam> (grep for ##)
<mgz> thanks, and it's greedy with the double hash
<jam> mgz: also see the python code, which does files[os.path.basename(fpath)] = ...
<jam> that leaves a lot of open file handles lying around.
<jam> mgz: should I expose tag URIs by their tag name? or by their tag.id?
<jam> (nodes are expose by their system_id
<jam> which is probably closer to name than DB id)
<mgz> the name seems preferable
<rvba> mgz: no, sorry, my bash-fu is not strong enough for me to be really confident with that script ;)
<rvba> mgz: using the name seems much better to me too.
<roaksoax> allenap: apiclient needs only python-oauth or httplib2 too?
<mgz> "The model 'nodecommissionresult' from the app 'metadataserver' is not available in this migration."
<mgz> that is not encouraging...
<allenap> roaksoax: I'll check
<allenap> roaksoax: Only python-oauth right now, but it will soon require python-httplib2.
<roaksoax> allenap: ok will update the package when that happesn
<roaksoax> allenap: i separated apiclient from maascli
<roaksoax> allenap: it *is* required by provisioningserver
<allenap> roaksoax: Cool.
<mgz> hopefully --freeze metadataserver is not harmful...
<jam> mgz: if you are curious: lp:~jameinel/maas/tag-list-api now has exposed a '/tags/' api and a '/tags/<name>/' api. They don't really do much yet, but it is a start.
<jam> i'll poke at it a bit more later, but it is time for dinner now.
<mgz> jam: ace, will have a look
<mgz> the sampledata doesn't include anything from metadataserver though, so I'm not sure how confident I am of this migration code
<mgz> and migrations don't seem very testable...
<roaksoax> allenap: cna we already start nodes from your cli?
<roaksoax> rvba: around?
<roaksoax> jtv: around
<roaksoax> ?
<roaksoax> allenap: around?
<rvba> roaksoax: yep.
<mgz> I take it no one minds if I add more sample data
<roaksoax> rvba: were there any recent changes with the PXE templates? I'm getting   AssertionError: No PXE template found in '/usr/lib/python2.7/dist-packages/provisioningserver/pxe'!
<rvba> roaksoax: not that I know ofâ¦ let me have a look at the commit history.
<rvba> roaksoax: looks like this might be a side effect of the changes introduced in revision 1025. allenap, can you help us out here, I see you've reviewed that changeâ¦?
<roaksoax> rvba: ok I figured it out, it seems due to the fact that when you start a node and the node is not allocated to anybody
<roaksoax> the node still pxeboots
<roaksoax> and before we had a poweroff thing i think
<roaksoax> matsubara: the issue that you were seeing when booting and getting stuck, was on commissioning right?
<matsubara> roaksoax, enlisting
<matsubara> roaksoax, oh wait, you mean the ipmi thing? or the image issue?
<roaksoax> matsubara: the image issue. I'm getting a similar issue with quantal images
<matsubara> roaksoax, the image issue happened during enlisting. It was due to some changes to kernel options passed on that smoser knows more about
<roaksoax> matsubara: kyeah
<roaksoax> alright
<roaksoax> mine seems unrelated after all
<smoser> roaksoax, what are you seeing ?
<smoser> i am close to being able to have quantal images produced as 'daily'
<smoser> all the changes are into archive except for 1 (mountall bug 643289)
<ubot5> Launchpad bug 643289 in nfs-utils (Ubuntu Precise) "idmapd does not starts to work after system reboot" [High,Triaged] https://launchpad.net/bugs/643289
<roaksoax> smoser: nothing really, my own dumbness i guess
<roaksoax> smoser: your change to the console output made me think there was an error on quantal installer
<smoser> ah. yeah. i can see that.
<smoser> so we need to make that easily configurable.
<smoser> as your usecase is not unreasonable
<smoser> but in "hyperscale", i surely dont think anyone is going to be watching video consoles
<roaksoax> indeed
<smoser> and serial console is very likely to be loggable
<roaksoax> smoser: do you know why libvirt might not be be serving DNS anymore?
<smoser> what do you mean.
<roaksoax> smoser: for some reason, the machines I deploy on libvirt, i.r.       <host mac='00:16:3e:3e:aa:01' name='node01' ip='192.168.123.101' />
<roaksoax> no longer resolve
<roaksoax> to the dns name
<smoser> oh. you mean in vdenv ?
<roaksoax> smoser: Yep
<smoser> i'm not sure. i've not used in a long time.
<smoser> it*should* work :)
<roaksoax> yeah it was working
<roaksoax> for some reason it no longer does
<roaksoax> oh well
<roaksoax> smoser: could you please? https://code.launchpad.net/~andreserl/maas/packaging_maas_client_improvements/+merge/125507
<smoser> roaksoax, can you clarify for me?
<smoser> python -c 'import apiclient'
<smoser> is that how you'd use this "apiclient" ?
<smoser> because that is a flat out broken name.
<roaksoax> smoser: that's how upstream has it
<smoser> ie, 'python -c import maas_apiclient'
<smoser> yeah, thats broken.
<roaksoax> smoser: unless, that all gets installed as a private module
<smoser> what do you mean ?
<roaksoax> smoser: install it in /usr/share/maas
<smoser> i'll open a bug on it.
<smoser> its just bad though.
<roaksoax> i agree, but that's what private modules in packaging terms are for I guess
<roaksoax> though that isn't really that private
<smoser> upstream maas has essentially claimed the names 'provisioningsever', 'metadataserver' 'maasserver' and now 'apiclient'
<smoser> i'm perfectly fine with
<smoser> python -c 'import maas.provisioningsever'
<roaksoax> smoser: right, thought that's why we can change the installation path to be a private module rather than a public one
<roaksoax> i don't know, however, how things will be affected
<roaksoax> we'll definitely have things broken
<smoser> https://bugs.launchpad.net/maas/+bug/1053507
<ubot5> Ubuntu bug 1053507 in MAAS "maas installs python modules with out any namespacing" [Undecided,New]
<roaksoax> smoser: but I agree with you, it should be maas.XYZ
<roaksoax> maas.apiclient maas.provisioningserver etc etc
 * roaksoax lunch
#maas 2012-09-21
<bigjools> jtv: why would maasserver tests do this?
<bigjools> ImportError: cannot import name oauth
<bigjools> I can't reproduce in bin/py
<jtv> Isn't that the python-django-piston problem?
<jtv> Where _on our dev systems_ you got this error if you installed python-django-piston, but on Q/A systems you didn't?
<bigjools> grar
<bigjools> I'll remove the egg and see
<jtv> We ended up with the hypothesis that it was caused by mixing buildout and packages.
<bigjools> yeah
<bigjools> buildout's copy needs to be junked,we can't use it at all
<jtv> Still a load of test errors?  Damn.
<bigjools> down to 11 failures, 6 errors
<bigjools>     from testresources import FixtureResource
<bigjools> ImportError: cannot import name FixtureResource
<bigjools> hmm
<jtv> Latest version on pypy is from January; still has FixtureResource in __init__.py as before.
<jtv> *pypi
<bigjools> python-testresources 0.2.4-1ubuntu1 doesn't have it
<lifeless> Uhm
<bigjools> wtf
<lifeless> so check what that ubuntu1 upload is
<lifeless> someone may have uploaded without sending upstream
<lifeless> trunk is :
<lifeless> revno: 60
<lifeless> tags: 0.2.5
<lifeless> branch nick: trunk
<lifeless> timestamp: Fri 2012-01-27 17:59:50 +1300
<bigjools> yeah it should be in 0.2.5
<bigjools> I have the egg with it in
<bigjools> why is my buildout not picking it up
<bigjools> oh god
<lifeless> 0.2.5 is on pypi
<bigjools> it's not packaged, that's all
<bigjools> but I  thought buildout would pick the egg over the installed package based on version
<bigjools> seems not :(
<lifeless> nope
<lifeless> it trusts you have it all, if you allow it to use system packages at all
<bigjools> something in my quantal upgrade must have pulled it in
<bigjools> Down to: FAILED (SKIP=1, errors=7, failures=2)
<jtv> bigjools: need anything reviewed for that?
<bigjools> no, removing the package fixed itg
<jtv> Well, any of the fixes you came up with?
<bigjools> jtv: can you look at the top error here
<bigjools> http://paste.ubuntu.com/1218063/
<bigjools> yeah, starting on fixes now :)
<jtv> See?  I've been waiting for a chance to get in on this :)
 * bigjools grabs a sandwich, back in 10
<jtv> That top error is a Django-specified method in our XMLField getting hit by a signature change.
<jtv> Looks fixable.
<bigjools> yeah
<bigjools> also means blue squad is not on quantal :)
<jtv> Review? https://code.launchpad.net/~jtv/maas/quantal-get_db_prep_lookup/+merge/125632
<jtv> I'm trying to test it on a quantal canonistack instance, but having some trouble getting set up.
<bigjools> ok
<jtv> Did you get buildout complaining that it can't find lxml 2.3.2?  I'm trying 2.3.5 instead.
<bigjools> nope
<jtv> (My fix does pass tests on precise)
<jtv> Could you be unwittingly benefiting from caching or something?
<jtv> Like lxml 2.3.2 not being available for quantal, but buildout using your existing egg oblivious to the upgrade?
<bigjools> running tests with your branch
<bigjools> I have 2.3.2 in cache
<jam> I'm trying to run just 'make test', but it is failing because testscenarios has no attribute WithScenarios.
<bigjools> morning jam
<jam> hi bigjools
<bigjools> jam: hehe - see my email to maas-devel
<jam> this seems to only be in 'maastesting' vs 'maasserver' so I can skip it
<bigjools> are you on quantal?
<jam> bigjools: this is on precise, though, not Q
<bigjools> ok
<bigjools> do you have python-testresources installed?
<bigjools> if so remove it
<bigjools> jtv: approved
<jtv> thx
<bigjools> passes tests now
<bigjools> well, that one does
<jtv> Damn, there goes my momentary elation
<bigjools> jtv: although, it seems to have made the NoRabbit errors go away too
<bigjools> no idea how!
<jtv> Urr
<bigjools> 2 failures left
<jtv> Well don't complain.  :)
<bigjools> both apidoc
<jtv> Yeah
<jtv> And suspiciously dependency-no-longer-works-the-way-we're-used-to-like.
<bigjools> whut?
<jam> bigjools: 'make' installs testresources
<jam> so it is listed as a dependency
<bigjools> ha
<jtv> Oh joy my canonistack instance is full
<jam> I don't have it from 'apt-get install', though.
<jam> so I should do 'apt-get install' and try to match that version to the one for buildout?
<bigjools> jam: oh that is fine
<bigjools> no, you need the buildout one
<bigjools> the one we need is not packaged
<jam> k
<bigjools> jam: so I have no idea why you get that error then, it works fine here
<bigjools> you could see which actual file it's importing to make sure it's the one you expect
<jam> bigjools: the isolation doesn't seem to be working properly.
<jam> it is loading the system testscenarios (which was later than the buildbot one)
<jam> I'm surprised it loads from system before loading from buildbot
<jam> note that I need testscenarios for other code
<bigjools> apt-get remove python-testresources
<jam> so I can uninstall it for now
<jam> bigjools: apt-get remove python-testscenarios
<jam> not resources
<jam> however,
<bigjools> oh
<jam> I will need it to do u1db tests
<bigjools> we set up buildout to prefer system packages
<jam> so if bin/test would load from buildout cache before system, my life would be better
<jam> bigjools: isn't the whole point that buildout should override system?
<bigjools> it does, if you tell it to
<jam> (use system if it matches, but use the custom defined one if present)
<bigjools> I mean, it doesn;t compare versions
<bigjools> so if you tell it in buildout.cfg you want that package, then it'll use it
<bigjools> unless it's already installed
<bigjools> I think it was done like this to reduce the dependency on pypi, otherwise it downloads a lot of stuff
<jam> bigjools: I have testscenarios 0.3 installed in ~/.buildout/eggs
<jam> I also have 0.2? installed in /usr/lib
<jam> but when I run 'bin/test' it loads the system one
<jam> not the buildout one
<bigjools> yes that's expected
<jam> bigjools: I'm pretty sure the 'reduce dependency on pypi' was that it wouldn't download packages whose versions you already ha
<jam> had.
<bigjools> sadly buildout does not compare versions :(
<jam> bigjools: it did for me with ipython-0.12 vs ipython-0.12.1
<jam> when versions.cfg said 0.12 and I had 0.12.1 installed globally
<jam> it would try to download until I updated
<jam> the versions.cfg to point to 0.12.1
<jam> now, possibly at *runtime* it doesn't compare versions
<jam> but it does seem to at 'make' time
<bigjools> jam: it didn't download because you had a system one installed
<bigjools> it ignores versions completely
<jam> bigjools: it *did* download until I made the version in versions.cfg match the system one
<jam> I'm quite sure about that
<bigjools> oh?  lifeless ^ ?
<lifeless> ?
<lifeless> bigjools: whats up ?
<bigjools> lifeless: version thing you mentioned earlier
<lifeless> bigjools: if there is a pth file or egg metadata
<lifeless> bigjools: if there isn't, I don't think it can tell, and that will depend on the package
<jam> so I think what you want is for the 'build' step to say 'if you have the version in sys.path, use it, else download to the egg cach', and then the 'run' step to say 'if it is in the egg cache, use it, else use the system one'
<jam> just found out today that there is a 'great firewall of UAE': http://www.du.ae/Documents/Annex%201-IAM%20Regulatory%20Policy%20ver%201%200%2029July2008.pdf
<jam> I was a bit surprised that online dating is one of the blocked sites.
<jam> "social networking" is listed, but isn't that facebook/twitter/g+ ?
<jam> and those certainly aren't blocked
<jtv> Yeah, blocked in many countries though.
<jam> jtv: yeah fb was blocked in syria for a while, might even be now with the fighting
<jtv> Usually all kids and subversives know how to get around it, but âdecentâ people get kept out of the 21st century.
<jam> jtv: well the first blocked thing is places that let you get around blocking
<jam> but there are lots of ways to do that :)
<jam> but VOIP is also prohibited
<jam> I guess because phone calls are expensive here, and they want to keep their monopoly
<jam> (something like $0.40/min to call internationally)
<jtv> Here too, as are VPNs.  We've had Google's appserver blocked, dropbox, twitter, youtube...  The consequences of blocking aren't usually taken into account because the people who do this are rarely fully aware of what they're damaging.
<jtv> Didn't the UAE also have Etisalad with its infamous *.com SSL certificates?
<jam> jtv: the main carrier here is Etisalat (has been for a long time) I hadn't heard about *.com though
<jam> that's pretty worrying
<jam> my *specific* carrier is the only competitor Du, but that is just because of whatever region I'm in
<jtv> Yup.  Issued for the purpose of censorship.  Trusted by all clients, at least until a recent surge of awareness.
<jtv> My understanding is that typically these countries regulate their incumbent carriers' censorship policies onto other carriers as well.
<jam> jtv: the ultimate MitM attack, carried out by your provider, and government approved.
<jtv> CA-approved even.
<jam> which is why when the government does it, it is so much scarier than when j-random-citizen tries
<bigjools> quantal is doing my head in, no sound at all today
<jtv> Time to start thinking about dual-boot setups.
<jtv> So that you can track which of your hardware is really, natively supported in the upgrade before you commit fully.
<jtv> I got a message saying that I may not have a usable desktop after the upgrade.
<jam> jtv: there is some way to get raw content out of django, though, as I think we're trying to do that for the xmlfield
<jam> (for the file storage discussion)
<jtv> You mean you support a choice of encodings in the xml, without re-encoding for storage purposes?
<jam> jtv: https://docs.djangoproject.com/en/dev/howto/custom-model-fields/https://docs.djangoproject.com/en/dev/howto/custom-model-fields/
<jam> jtv: actually, we are just trying to make it so we can run custom xpath_* queries
<jam> which isn't directly supported by django
<jam> but it sounds like something that would let you do bytea as well.
<bigjools> jtv: what did you think to my packaging suggestion?
<jtv> It may have been something to do with the dynamicism of field conversions in django.
<jtv> bigjools: saw the thread, but didn't look too closely.  Which was your suggestion?
<bigjools> jtv: you need to read it
<bigjools> it's a little involved
<jtv> OK, I'll dig it up
<jtv> jam: when you write field conversions in django, you get very little information about what the intended conversion is.  Basically you get âa value,â and it's up to you to figure out whether that needs any conversion.  Sometimes the conversion seems to go in unexpected directions, too.
<jtv> bigjools: your suggestion sounds good to me â but then I never got around to understanding the distribution of responsibilities between maas-dns and maas-dhcp.  Until recently I thought maas-dhcp was de facto the seedling of the cluster-controller package.
<jtv> (Small note: the provisioning server may require maas-cli, since it uses apiclient)
<bigjools> gah
<jtv> Meanwhile, my experiments on quantal suggest that we need: https://code.launchpad.net/~jtv/maas/quantal-updates/+merge/125634
<bigjools> jtv: why do we need bzr?
<jtv> Ohhhh â that's the one Gavin added for now-unclear reasons, innit
<bigjools> commandant
<bigjools> I think it can go, I asked on the list earlier
<jtv> In any case, 2.5.1 will break the build and 2.6.0b2 doesn't.
<bigjools> 2.5.1 works here
<jtv> Cached?
<bigjools> well - it gets downloaded
<jtv> hmmm
<jtv> On a fresh canonistack instance it said no distribution found.
<bigjools> nfi then
<jtv> Ahh, I think that was before I ran an upgrade on it.
<bigjools> also, why are we specifying precise versions
<bigjools> why not > <version>
<jtv> Didn't know you could.
<bigjools> or >=
<jtv> I guess ideally at this stage, we'd be tracking Quantal's versions.
<bigjools> I'd rather not be specific
<bigjools> we have to QA it either way
<jtv> Doesn't that carry a risk of accidentally relying on changes that are newer than what quantal has/
<jtv> ?
<bigjools> no, because we have to QA it
<bigjools> we should only get specific when a particular problem is found
<bigjools> otherwise we'll forever be amending versions in buildout.cfg
<bigjools> versions.cfg even
<jtv> Soâ¦ want me to slap in a bunch of â>=â then?
<bigjools> we need to review it, but don't do it now.
<jtv> OK
<bigjools> your point above would equally apply to relying on versions that are less than quantals
<jtv> I do find I need a newer lxml though.
<jtv> Yes, absolutely.
<bigjools> ok
<jtv> What was causing that piston error about _is_string again?  You had a fix for that, right?
<bigjools> yeah remove your local piston egg and cache
<bigjools> we need to remove it from buildout and put it in required-deps
<jtv> Weird.  This is on a clean system.
<jam> jtv: I'd be interested in voice chatting with you about: https://code.launchpad.net/~jtv/maas/node-nodegroup-api-ui/+merge/125624
<bigjools> the only use of bzrlib that I can find is src/maascli/__init__.py:from bzrlib import osutils
<jam> just to get an understanding of that system, and review your code while I'm there.
<jtv> jam: OK â but I'll need a few moments to prepare.
<jam> allenap: you are using osutils.get_unicode_argv(), but it seems to be the only use of bzrlib
<jam> Is there a plan to use more? Or can we just split out that code rather than bringing in all of bzr as a dependency?
<bigjools> yes I was wondering the same
<jam> right, so it was certainly useful for commandant
<jam> but now that we aren't doing that
<jam> the dependency is quite small
<bigjools> allenap won't be around for about 2 hours though
<jtv> jam: ready now â name your medium
<jam> jtv: whatever is your favorite :)
<jtv> Face to face over coffee!?
<jam> jtv: that would be best, I agree
<jtv> Deal.
<jtv> Until you get here, I'll set up a hangout.
<jtv> jam: I've invited you.
<jtv> bigjools: removing my piston egg didn't help, and I don't think I have a cache.  Wonder what else could be going on.
<bigjools> jtv: clean and rebuild
<bigjools> well just make check will do that
<bigjools> this definitely fixed things for me earlier
<jtv> Not for me.  :(
<bigjools> jtv: have you installed the quantal python-django-piston?
<bigjools> it has the fix in it
<bigjools> for sure
<jtv> I don't even see it in my available packages.
<bigjools> you need 0.2.3-1ubuntu2
<jtv> Guess I need some repository that isn't configured.
<bigjools> like quantal? :)
<bigjools> it's right there https://launchpad.net/ubuntu/+source/python-django-piston/0.2.3-1ubuntu2
<jtv> This is a quantal instance.
<bigjools> apt-get update
<jtv> I wonder why it doesn't pick up the existence of that package.
<jtv> Yeah, been doing that.
<bigjools> how are you trying to install?
<jtv> dselect
<bigjools> ?!
<jtv> Nothing there with âpistonâ in the name.
<bigjools> apt-get install python-django-piston
<bigjools> if you want to query availability, use "apt-cache search <thing>"
<jtv> !?  How can that work in apt and not dselect?
<ubot5> jtv: I am only a bot, please don't think I'm intelligent :)
<jtv> Oh shut up.
<bigjools> dpkg -l <package> shows if it's installed
<jtv> I know about apt-cache search, it's just a hassle compared to interactive pattern searching.
<bigjools> don't use dselect
<jtv> But why doesn't it see the package?
<jtv> Oh God it has its own cached package listsâ¦
<bigjools> NFI
<bigjools> I don't even have it installed
<bigjools> friends don't let friends use dselect
<jtv> I've been used to it for about a decade.
<jtv> I found it friendlier than aptitude.
<bigjools> don't use aptitide
<bigjools> aptitude even
<bigjools> while it works most of the time, it does have a different dependency resolver to apt, and apt is the reference
<bigjools> jtv: https://code.launchpad.net/~julian-edwards/maas/fix-quantal-piston/+merge/125638
<jtv> Some people swear by aptitude's resolver, apparently.  Again, I'm more used to apt's.
<bigjools> it can offer some interesting resolutions to conflicts, but they are likely to break things even more.
<jtv> Reviewed.
<bigjools> cheers
<jtv> Had some weird trouble with the âlxml >= 2.3.2â in Precise, will try in Quantal.
<bigjools> oh?
<jtv> The error is one of those things that make you go âyes, andâ¦?â
<jtv> Â«Error: Picked: lxml = 2.3.5Â»
<bigjools> :)
<bigjools> oooooo I know
<jtv> Let's turn that smile up-side down.
<bigjools> we have explicit versions turned on iirc
<bigjools> bugger
<bigjools> allow-picked-versions = false
<bigjools> bugger
<bigjools> why, I wonder
<bigjools> we really need to start uding system packages more instead of pypi
<bigjools> using*
<bigjools> morning rbasak
<bigjools> argh
<bigjools> morning rvba
<rvba> Hi bigjools.
<jtv> Hi rvba
<rvba> \o jtv.
<jtv> Yes, rbasak does raise the suspicion of queue-jumping.
<bigjools> I have to reboot, because plugging in new usb device seems to still have a bug that is now about 4 years old which makes the mouse disconnect >:(
<jtv> It'll get triaged any day now, I'm sure
<bigjools> srsly annoying.
<bigjools> brb
<jtv> rvba: would appreciate your input on the django incantations I applied here â https://code.launchpad.net/~jtv/maas/node-nodegroup-api-ui/+merge/125624
<rvba> jtv: ok, I'll have a look.
<jtv> Thanks
<bigjools> rvba: did you see my packaging suggestion around clusters etc?
<rvba> bigjools: not yet.
<bigjools> rvba: check out maas-devel
<rvba> Reading it right now.
<rvba> jtv: I've reviewed your branch.  Looks ok but I've got a few remarks.
<jtv> Thanks for the additional notes.
<rvba> bigjools: I've made some experiments on how to route tasks in celery yesterday btw.
<bigjools> rvba: cool, all ok?
<rvba> bigjools: yes, queue creation works, routing ok, broadcast messages ok.
<mgz> jtv: thanks for fixing the get_db_prep_lookup thing
<jtv> np
<bigjools> good - I played around a long time ago and it was ok in my experiments so good to hear you went well too
<jtv> I'm happy at last to have validation for my habit of âif it's somebody else's signature, accept *args & **kwargs and pass them in the upcall.â  :)
<bigjools> GNARGH
<rvba> bigjools: btw, when running the test suite on quantal, I've got only 2 failures, all related to the api doc.
<bigjools> usb disconnection AGAIN
<bigjools> rvba: yes that is all that is left now
<rvba> bigjools: not so bad after all then :)
<bigjools> rvba: that's because we've been fixing them all day ;)
 * bigjools reboots AGAIN
<allenap> jam, bigjools: Yes, bzrlib's there just for osutils. I considered breaking out that code. It's a big dependency, but I think it's fairly low priority to fix that.
<jam> allenap: i guess bzr=2.5.1 fails on Q because bzr-2.6b? is there
<mgz> jam, jelmer: http://pastebin.ubuntu.com/1218325/
<mgz> when do I need to care about django model identity...
<mgz>         self.assertEqual(xmlbytes, Node.objects.get(id=node.id).hardware_details)
<mgz>         self.assertEqual(xmlbytes, node.hardware_details)
<mgz> not equivalent
<mgz> what I want it seems:
<mgz>         self.assertEqual(xmlbytes, Node.objects.get(id=node.id).hardware_details)
<mgz>         self.assertEqual(xmlbytes, node.hardware_details)
<mgz> bah! cp
<mgz>         node = reload_object(node)
<jam> poke mgz for great justice
<jam> and jelmer for goodness sake
<mgz> jam, just about to nip out, but nearly there (despite django) with setting cpu_count/memory
<allenap> jam: Yeah, I think so. It's not able to arrange for an earlier version of bzrlib because we allow site packages.
<jam> mgz: just curious where your db patch is at, since I cant evaluate tags until we have the column
<mgz> ah, I still need to actually propose the branch...
<mgz> jam: pushed to lp:~gz/maas/temp and I need to run
<roaksoax> morning
<roaksoax> rvba: is the webui only to be meant installed on the region?
<rvba> roaksoax: yes
<roaksoax> cool
<jam> I'm running into something strange with django.piston and nested fields
<jam> It doesn't seem to restrict the output to just the fields that are specified
<mgz> jam: sounds like more joy
<jam> mgz: I'm trying to confirm w/ macaddress_set since that was doing ('mac_address',)
<jam> but I can't seem to get it to only return just the 'name' and 'resource_uri' of the tag
<jam> of related tags.
<mgz> jam: I can't get UPDATE to work at all in a raw query...
<jam> rvba: ^^ Specifically, I'm trying to expose tags, but just saying "NODE_DISPLAYED_FIELDS = (..., 'tags')" means the full tag gets exposed.
<rvba> jam: can't you apply what we've done with 'macaddress_set' (in DISPLAYED_NODE_FIELDS)?
<rvba> jam: DISPLAYED_NODE_FIELDS= (â¦, ('macaddress_set', ('mac_address',)),â¦)
<jam> rvba: that doesn't seem to do what we think it does
<jam> I can't confirm mac_address yet, as I haven't found a test that actually tests the values in macaddress_set
<jam> however, if I put ('tags', ('name', ))
<jam> I still get all the fields
<rvba> jam: let me have a look at the code.
<jam> rvba: lp:///~jameinel/maas/tag-list-api
<jam> has a failing test
<jam> that shows what fields are being exposed.
<rvba> jam: cool, I'll have look.
<jam> rvba: and I see tests about 'POST_limited_fields' but none of them seem to test the actual content of the macaddress_set field, just that it exists
<rvba> jam: indeed.
<jam> rvba: and I do feel like what we are doing *should* work, from places like http://stackoverflow.com/questions/2215352/django-piston-how-can-i-exclude-nested-fields-from-handler-results-is-it-even
<jam> and here: https://bitbucket.org/jespern/django-piston/wiki/FAQ#!why-does-piston-use-fields-from-previous-handlers
<jam> but that doesn't seem to actually work
<jam> jelmer: any update to where you got to?
<mgz> okay, I think I have code ready for the tag stuff now jam
<rvba> jam: I don't understand why it does not work.  I'll have to put my hazmat suit on and debug piston.
<jam> rvba: so at least I'm not crazy
<mgz> ...now kapil will wonder why you want to dress up as him...
<rvba> haha :)
<jam> mgz: https://code.launchpad.net/~jameinel/maas/tag-list-api/+merge/125697 up for review
<rvba> jam: I got it.
<rvba> jam: it's using TagHandler.fields.
<jam> rvba: which I thought the definition in NodeHandler is supposed to override it for exposing tags on node
<jam> if you know a way to do it, I would be fine turning the tags attribute into a simple list of names
<jam> rather than a list of objects
<rvba> jam: let me investigate some moreâ¦
<jam> but we are using the default 'get' handler, and I don't know how to easily override it.
<mgz> jam: I have put up some branches for review
<rvba> jam: It does not seem to be possible to do that with piston (I even found a fork on github which adds this possibility https://bitbucket.org/liberation/django-piston); the only way is by adding a custom method like this: http://paste.ubuntu.com/1218559/
<jam> rvba: well, that change looks good to me, so I'll go with that. Thansk
<rvba> np
<jam> rvba: which is opposite to what I read https://bitbucket.org/jespern/django-piston/wiki/FAQ#!why-does-piston-use-fields-from-previous-handlers
<jam> but hey, tag_names actually works better for my purpose, I think
<rvba> jam: right, but the code right here overrides the list of fields with the list from a registered emitter: https://bitbucket.org/jespern/django-piston/src/c4b2d21db51a/piston/emitters.py#cl-160
<jam> rvba: well, update pushed. Your code actually nests the values because 'values_list' returns a list of tuples, but you can unwrap them and get it to work.
<rvba> jam: ah, right.
<rvba> jam: values_list('name', flat=True) will solve that for you :)
<jtv> roaksoax, are you here?
<jtv> It's about bug 1053295.  I must have missed a step in introducing that upstart file into the maas-dhcp package.
<ubot5> Launchpad bug 1053295 in MAAS "maas-dhcp does not install custom upstart script" [Critical,Triaged] https://launchpad.net/bugs/1053295
<rbasak> smoser: https://bugs.launchpad.net/maas/+bug/1054056
<ubot5> Ubuntu bug 1054056 in MAAS "ephemeral images do not support multiple kernel flavours" [Undecided,New]
<smoser> gracias
<roaksoax> jtv: yep
<jtv> Any idea what it might be?
<roaksoax> jtv: yep :)
<jtv> What is it?
<jtv> (You're not getting to me.  Not at all.  :)
<roaksoax> jtv: missing  dh_installinit --name maas-dhcp-server
<roaksoax> jtv: i'll fix it
<jtv> Ahhhh.  Â¡Muchas gracias!
<mgz> jam: https://code.launchpad.net/~gz/maas/populate_tags/+merge/125720
<mgz> whoops, forgot to set prereq branch
<guimaluf> where can I edit the cloud-init config for maas nodes?
<mgz> jam: and lp:~gz/maas/_try_migrate_hardware_details is my attempt at doing that migration... which still seems unhappy, but I'll have to look at that later
<mgz> ...without the leading underscore
<roaksoax> rvba: https://code.launchpad.net/~andreserl/maas/install_maas_local_celerysettings/+merge/125735
<rvba> roaksoax: s/etc/contrib/
<roaksoax> rvba: yeah already pushed another branch
<roaksoax> rvba: and in the packaging side we need to handle upgrades, not only installations :)
<roaksoax> rvba: i'll get that done though
<rvba> roaksoax: cool, thanks a lot.
<roaksoax> rvba: i'll approve myself the setup.py branch
<rvba> roaksoax: approved :)
<roaksoax> hehe :)
<roaksoax> rvba: so there's 1 text conflict in debian/changelog, If you want you can fix that and push an updated branch or If you prefer I'll merge it myself against a local branch and resolve the conflict and push it back
<rvba> roaksoax: I'll fix it, hang on.
<rvba> roaksoax: I don't see the conflict.
<rvba> roaksoax: if you're talking about ~rvb/maas/packaging.set-rabbitmq-creds, I've fixed the conflict yesterday.
<roaksoax> rvba: did you pull the latest packaging branch?
<roaksoax> rvba: http://pastebin.ubuntu.com/1218767/
<rvba> roaksoax: hum, let me merge trunk againâ¦
<rvba> roaksoax: conflict fixed.
<roaksoax> rvba: thanks! i'll test it one more time and get it merged
<rvba> roaksoax: ta.  Please review/test it carefully as I'm really no packaging expert.
<roaksoax> will do :)
<roaksoax> rvba: https://code.launchpad.net/~andreserl/maas/maas_local_celeryconfig/+merge/125745
<roaksoax> rvba: packaging needs to be updated from celerysettings to celeryconfig
<rvba> roaksoax: you're right.
<guimaluf> where can I append some script to the cloud-init running on maas nodes?
<roaksoax> smoser: ^^
<smoser> guimaluf, you mean in commissioning?
<roaksoax> guimaluf: cloud-init is only used for enlistment and commissioning. Not for deployed maas nodes
<smoser> roaksoax, thats not true
<smoser> cloud-init is used on install also.
<smoser> juju provides cloud-init user-data to the provisioned nodes, it is available through the api
<roaksoax> smoser: right, but what I mean is in already running nodes
<roaksoax> smoser: i guess I should have said, not for already deployed maas nodes
<smoser> roaksoax, well actually i think that is wrong too :)
<smoser> cloud-init is installed, and active. it will run things as it it does on regular instances
<roaksoax> smoser: right, but I dind't know that you can tell cloud-init, from maas, to do XYZ after the node was installed/configured
<roaksoax> :)
<guimaluf> exactly. so if I want to customize some new cloud-init script for new maas nodes, there is a way to do it, right?
<roaksoax> smoser: so that's what I mean, after I have deployed a node with juju, it installed the service or whatever, does it continue to poll the mAAS meta-data server?
<roaksoax> smoser: or for example, can i juju deploy something and tell it a cloud-config script to use?
<guimaluf> in deed I never get maas nodes to reach metadata server and get the maas-server ssh-key.
<roaksoax> rvba: i'll do the update if that's ok with you?
<rvba> roaksoax: have you been able to test the changes to the postinst script?
<roaksoax> rvba: yeah, it works
<roaksoax> obviously changing s/celerysettings/celeryconfig
<roaksoax> rvba: if you can change that real quick I'll merge your branch
<rvba> roaksoax: you mean renaming the file in contrib/ right?
<roaksoax> rvba: the file in contrib is already maas_local_celeryconfig.py
<roaksoax> rvba: so packaging needs ot be updated accordingly
<rvba> roaksoax: ah right.
<roaksoax> rvba: so maas.install maas.links and maas.postinst needs update
<rvba> roaksoax: ok, I'll update my branch.
<roaksoax> rvba: cool, other than that it seems to work as expected
<rvba> roaksoax: fix pushed.
<roaksoax> rvba: BROKER_URL = 'amqp://maas_workers:T1A3Ksj5wiEfOe1VrDjl@localhost:5672//maas_workers'
<roaksoax> so that's what I end up having in maas_local_celeryconfig
<rvba> That's good.
<roaksoax> allenap: ping
<allenap> roaksoax: Yo.
<roaksoax> allenap: so, what is the cli doing thus far? Can I alreay make changes to a node?
<roaksoax> allenap: idk if you recall.. but during commissioning we need to be able to modify the node's information
<roaksoax> allenap: and we were looking at having anonymous access
<roaksoax> specifucally to set up the power_parameters for ipmi autodiscovery
<allenap> roaksoax: It does basic stuff, including setting things. However, not everything works :-/ Bug 1052867 and bug 1052872 are pertinent here.
<ubot5> Launchpad bug 1052867 in MAAS "The metadata API description is not exposed" [Critical,Triaged] https://launchpad.net/bugs/1052867
<ubot5> Launchpad bug 1052872 in MAAS "Anonymous handlers are not treated as subsets of their non-anonymous counterparts in the API" [Critical,Triaged] https://launchpad.net/bugs/1052872
<allenap> roaksoax: There's probably a view missing from the metadata API too, for the anonymous setting of power parameters.
<allenap> I don't have a bug number for that.
<roaksoax> allenap: alright, i guess we can look deeper into that next week
<allenap> roaksoax: Cool, let's talk on Monday. Have a good weekend!
<roaksoax> allenap: thanks you do aswell
#maas 2013-09-16
<AskUbuntu> Does a MaaS region or Cluster controller going down mean the provisioned servers go down or only that new servers will not be provisioned? | http://askubuntu.com/q/346048
<freeflying> when does maas add CNAME, after enlist or after it be allocated?
<bigjools> freeflying: after commissioning
<freeflying> bigjools, is there any clue on why some node can't be added after commissionning
<bigjools> freeflying: what do you mean by added?
<freeflying> bigjools, the CNAME record
<bigjools> freeflying: you'd have to look a in a few places.  The path from commissioned node to dns cname is a long one, I'll try to explain:
<freeflying> bigjools, thanks
<bigjools> 1. the celeryd on the cluster controller periodically scans the dhcp leases file and reports active leases to the region controller
<bigjools> 2. the region controller associates the lease (MAC/IP combo) with any known nodes
<bigjools> 3. it sends a job to the celeryd-region daemon to write a new zone file
<bigjools> 4. it sends a job to the celeryd-region daemon to reload the zone
<bigjools> so check logs for both celeryd processes to start with and see if there's any errors
<bigjools> also check the maas log
<freeflying> bigjools, celeryd scans the lease of dhcp managed by maas only, right?
<bigjools> freeflying: yes
<bigjools> unless you have dhcp controlled by maas you won't get any CNAME
<freeflying> bigjools, but now we running a external dhcp server for enlisting/provisioning
<bigjools> freeflying: then you're out of luck, you need to use DDNS to update an external DNS server
<bigjools> this is largely because maas needs to be able to force a static host mapping in the dhcp server
<freeflying> bigjools, that explains I only have 2 nodes CNAME added by maas
<bigjools> if the leases file is on the same server as the cluster controller it can scan the leases, but if the IP changes things will break
<freeflying> bigjools, the leases file is on the same server, so we have isc-dhcp-server running, bind to one eth, and maas's dhcp bind to another eth on same server
<bigjools> freeflying: maas does not have its own dhcp server, it uses isc
<bigjools> I think its ok to have another isc running for a separate eth but I've never done that
<freeflying> bigjools, yes, and I run into problem that node's CNAME can't be added
<bigjools> freeflying: so you have maas-dhcp installed?
<freeflying> bigjools, yes
<bigjools> freeflying: then there must be an error in one of the logs somewhere to say what's going on
<bigjools> freeflying: which version of maas?
<freeflying> bigjools, 1.2+bzr1373+dfsg-0ubuntu1~12.04.2
<bigjools> freeflying: did you set the cluster controller to manage dhcp/dns?
<bigjools> in the web ui
<freeflying> bigjools, yes
<freeflying> bigjools, and I'm confused that we had 3 machines enlisted, and we successfully bootstrapped, and deployed ubuntu to another machine, I tried to add-unit, it fails, checked /etc/bind/maas/zone.maaslab.mast, only got 2 CNAME there
<bigjools> freeflying: that is odd
<bigjools> freeflying: can you look at the leases file and see if there is an entry
<bigjools> then can you do this:
<bigjools> $ maas shell
<bigjools> > from maasserver.models import DHCPLease
<bigjools> > for l in DHCPLease.objects.all():
<bigjools> >     print l
<freeflying> bigjools, only 2 entries can be found, I believe its because the third one hasn't boot up successfully after commissioning, so it never has a chance to get ip from dhcp managed by maas
<bigjools> freeflying: that sounds reasonable
<bigjools> I have to step out for a bit, back later
<freeflying> bigjools, so to use external dhcp, I need set ddns?
<freeflying> bigjools, ttyl
<AskUbuntu> Not abel to destory service as agent state is down | http://askubuntu.com/q/346228
<AskUbuntu> juju error: hook failed: "config-changed" | http://askubuntu.com/q/346276
<AskUbuntu> MAAS with external DHCP TFTP time out | http://askubuntu.com/q/346339
#maas 2013-09-17
<freeflying> bigjools, ping
<bigjools> freeflying: hi
<freeflying> bigjools, hey, do you have some mins for a chat?
<bigjools> freeflying: I can try.  Coming down with a cold or something so bear with me.
<freeflying> bigjools, I'm sorry to hear that, then I'll try catch someone else :) take care
<bigjools> freeflying: jtv is around too
<bigjools> ask anyway and someone will answer
<freeflying> bigjools, cool, thanks
<freeflying> so I'm still on the issue that to deploy with 2 dhcp servers, 1 for pxe to offer node boot/enlist/provisioning, the other is managed for maas, and is for for post deployed management network
<freeflying> I can enlist nodes now, but have problem with deploy service, CNAME of the node won't be added to DSN record correct, so will ddns on the dhcp server managed by maas solve the issue or need to do some other configuration with celeryd
<freeflying> jtv, if you happen to be here, would you mind take a look? thanks
<bigjools> you said you had 2 nodes with a cname and one without
<bigjools> we established it was not booting correctly
<freeflying> yes
<freeflying> the 3rd doesn't come up crrectly
<bigjools> then you need to work out why
<bigjools> it's nothing to do with dhcp or dns
<freeflying> during enlist/cmmissioning, both should get a ip from dhcp server, and celeryd-regional-controller is able to have the CNAME added after commissioning, it it corret?
<bigjools> CNAME is added after a node is accepted for commisioning and after a lease is added to the leases file
<bigjools> so it needs to boot and have the dhcp client request an address
<jbalonso> Is this a reasonable place to ask about (heretofore undocumented) custom commissioning scripts?
<kurt_> jbalonso: I would put your question in to askubuntu
<free50> hello everyone, I have a reasonably large cluster using infiniband as the interconnect. Does MAAS support FlexBoot?
<jbalonso> kurt_: Thanks. I'll look into that. From what I can google, however, the custom commissioning script system has only been discussed in a dev context, so I'm not very optimistic.
<kurt_> jbalonso: you'll get better round-the-clock exposure from askubuntu.
<free50> I guess a more general question is, does MAAS work with infiniband?
<kurt_> free50: I'm kinda clueless on inifiniband - does infiniband support PXE boot and WOL?
<jbalonso> kurt_: To close out this conversation, I've submitted my question to http://askubuntu.com/questions/346770/how-do-i-use-maas-custom-commissioning-scripts
<kurt_> jbalonso: cool.  Then bigjools will see it.
<AskUbuntu> How do I use MAAS custom commissioning scripts? | http://askubuntu.com/q/346770
<free50> kurt_: the docs on the mellanox site say they support ipxe
<free50> WOL is another question
<kurt_> PXE is the big thing
<free50> seems like the initrd has to have the infiniband (that is, OFED) drivers included with it
<kurt_> free50: you systems have to be able to PXE boot for MAAS to work
<kurt_> sorry, I'm not going to be much help in this area.
<free50> hmm.
<free50> kurt_: do you know if anyone here is knowledgeable WRT infiniband?
<kurt_> sorry, no.  as I suggested to jbalonso, you may want to post your question to askubuntu to get widest exposure.
<free50> k, I'll try that. thanks for your help
<kurt_> good luck
<AskUbuntu> Infiniband + Maas? | http://askubuntu.com/q/346780
<free50> hey kurt_, on a separate note: does MAAS support diskless boot? I see in the setup docs on ubuntu's site that the node "contacts the region controller, then shuts down"
<free50> obviously that isn't conducive to diskless boot..
<kurt_> free50: I'm not sure.  It may, but it's definitely not the focus.  The focus is on physical hardware and kvm.
<free50> kurt_: so maas is more of a solution for VPS?
<free50> rather, vps providers?
<kurt_> right.  its more of a physical thing
<kurt_> Metal-as-a-service
<kurt_> you could try looking at juju as your next layer
<kurt_> that being said, I have worked through using MAAS with VMware
<kurt_> and it works on KVM
#maas 2013-09-18
<bigjools> roaksoax: can you do anything about the package in precise-proposed?  Many people are hitting the bug with juju core now and the -proposed is verified.
<roaksoax> bigjools: not unly *all* the bugs are verified
<bigjools> roaksoax: oh it's one big package?  feck
<bigjools> I'll set about that then ...
<roaksoax> bigjools: yeah, SRU's usually recommned to fix various bugs in 1 upload
<bigjools> ok
<AskUbuntu> Scaled down Openstack Grizzly installation with Juju and Maas | http://askubuntu.com/q/346898
<bigjools> smoser: can you verify this please? https://bugs.launchpad.net/maas/+bug/1064527
<ubot5> Ubuntu bug 1064527 in maas (Ubuntu Quantal) "detect_ipmi needs improvement. detects non-existant device in nested kvm" [High,Triaged]
#maas 2013-09-19
<rvba> roaksoax: hi, sorry we've not been able to catch up lately.  Please ping me when you'll be available.
<roaksoax> rvba: howdy!
<jbalonso> Hi all. Can anyone here help me with understanding the custom commissioning script framework? http://askubuntu.com/q/346770 (I'm trying to catch the tail end of the UK workday this time).
<kentb> I noticed that newer versions of Maas will pre-populate the IPMI power parameters with a maas username and random password.  Is that even usable?  I've been going in and changing those to a known-working username/password without trying the one maas gives me.
#maas 2013-09-20
<roaksoax> bigjools: maas-dhcp should be on the cluster right?
<bigjools> roaksoax: yes
<bigjools> you *just* caught me, about to go to lunch
<roaksoax> bigjools: enjoy
<bigjools> :)
<roaksoax> bigjools:
<roaksoax> Failure: twisted.internet.error.ConnectionRefusedError: Connection was refused by other side: 111: Connection refused.
<roaksoax> 2013-09-20 12:03:12+0900 [Uninitialized] Stopping factory <HTTPClientFactory: http:///MAAS/api/1.0/pxeconfig/?cluster_uuid=5c11d0fa-6b41-4cd6-b278
<bigjools> roaksoax: I have never seen that
<roaksoax> bigjools: we are seeing this right now ;/
<roaksoax> how does pserv get that address?
<bigjools> what address?
<roaksoax> bigjools: the address of the region
<bigjools> DEFAULT_MAAS_URL
<bigjools> has to be contactable by the nodes
<bigjools> and clusters
<roaksoax> bigjools: it is
<roaksoax> but pserv is trying to contact without address:"  http:///MAAS/api/1.0/pxeconfig/?cluster_uuid=5c11d0fa-6b41-4cd6-b278
<bigjools> oh I see now!
<bigjools> jtv1: ^
<bigjools> halp
<roaksoax> bigjools: this is kind of critical btw
<bigjools> roaksoax: what is in /etc/maas/maas_cluster.conf
<bigjools> the MAAS_URL in there should be the region's
<roaksoax> it is
<bigjools> so that Connection refused error is in the pserv log?
<bigjools> roaksoax: ^
<freeflying> roaksoax, seems the same
<bigjools> roaksoax: can you sniff its tcp and see what it's trying to connect to
<bigjools> it's just a bad config somewhere
<bigjools> or perhaps a proxy getting in the way
 * jtv1 reads backscroll
<roaksoax> yes p serv.log
<roaksoax> bigjools: this is multinode maas btw
<bigjools> roaksoax: you mean multi cluster?
<roaksoax> ok hold on
<roaksoax> it seems squid homehow messing things up
<roaksoax> but it shouldn't
<jtv> Might be worth checking whether the start-cluster-controller command line has the right server URL.
<bigjools> that's what I was juuuust about to say
<bigjools> jtv: it comes from MAAS_URL in the maas_cluster.conf file right?
<jtv> If it doesn't, then either /etc/maas/maas_cluster.conf is messed up, or alternatively I'd say something changed in how upstart scripts work.
<bigjools> I think that's what the packaging uses
<jtv> Yes.
<jtv> The upstart script sources that config file, then passes $MAAS_URL on the command line.
<jtv> Oh.
 * jtv checks something...
<bigjools> roaksoax: /etc/init/maas-cluster-celery.conf starts it remember
<roaksoax> yeah looking at it
<bigjools> but you said that config was already ok
<bigjools> so squid getting in the way?
<jtv> How could squid get in this particular way?
<roaksoax> bigjools: yeah, otherwise it would not have registered the cluster controller in the region
<bigjools> roaksoax: right
<bigjools> jtv: it could be down :)
<jtv> Down, sure.  But mangling URLs..?
<bigjools> who knows what its config us
<bigjools> is
<roaksoax> maybe a dirty pyc file?
<bigjools> unlikely
<jtv> Could happen with permissions problems and an upgrade, I suppose.
<roaksoax> jtv: clean system
<bigjools> roaksoax: have you traced the tcp?
<bigjools> ethereal or something
<bigjools> tcpdump
<bigjools> take it one step at a time and divide the problem into possible areas
<roaksoax> bigjools: https://pastebin.canonical.com/97785/
<bigjools> roaksoax: stops short ...
<roaksoax> bigjools: repeats itself
<bigjools> roaksoax: is it connecting to the right place?
<roaksoax> bigjools: yeah
<roaksoax> again, otherwise the cluster controller would not have registered itself
<bigjools> roaksoax: ok if you trace on the region controller do you see traffic?
<roaksoax> bigjools: hold on, i rebooted the cluster
<bigjools> jtv: roaksoax: so the config actually comes from /etc/maas/pserv.yaml
<bigjools> tftp:generator:
<bigjools> roaksoax: so I suspect the bug is in the packaging and it doesn't set that file up properly sometimes
<bigjools> maybe a race condition with another package
<bigjools> and the wrong one got installed first
<freeflying> where can I watch commissioning log?
<freeflying> bigjools, now I can  enlist node, but have problem to commission it, have apt_proxy in enlist_data and commission, any clue?
<freeflying> jtv, ^^
<jtv> Hi freeflying
<jtv> I think a commissioning node will direct its syslog to either the region controller or the cluster controller...
<jtv> Look for an "rsyslog" log.
<freeflying> jtv, no log there
<freeflying> jtv, it gives connect to 169.xxx fails, after it get ip address
<jtv> The node says that on its console?
<freeflying> yes
<jtv> Any idea what the 169.xxx address is?
<freeflying> no, all address we're using within 10.x.x.x
<freeflying> looks that is epheremal image?
<jtv> Yes, commissioning runs an ephemeral image.
<jtv> But I don't think the node should be talking to the internet at that point.
<jtv> Doesn't look as if it's the Ubuntu archive either, although I suppose it might be your local mirror.
<freeflying> why its calling its calling 169.254.169.254/2009-04-04/meta
<jtv> So that's where it's trying to find its metadata service.
<jtv> Strange address...
<freeflying> jtv, where shall I configure it, or is it because it can't access to maas-regional contoller
<jtv> That's a zeroconf address.  Any chance there's a wifi interface being mistaken for your server?
<freeflying> jtv, no
<freeflying> thre are 8 ports on the server, 1 of them are 10 gig, for of them are 1 gig;s
<jtv> At least, when I use "whois" on it, it says computers use 169.154.*.* (note 154, not 254!) when they don't have an IP address and don't get one from the network.
<freeflying> from weui, the metatada_url was set to maas regionl's
<jtv> And that's a 10.*.*.* address, right?
<jtv> And no 169.*.*.* networks at all?
<rvba> 169.254.169.254 is used in Amazon EC2 and other cloud computing platforms to distribute metadata to cloud instances.
<jtv> !
<rvba> So cloud-init is acting up.
<jtv> Thinking this is EC2...
<rvba> cloudinit/sources/DataSourceEc2.py:DEF_MD_URL = "http://169.254.169.254"
<freeflying> jtv, yes, in the preseed generated for commissioning is 10.209.13.204/MAAS
<rvba> (this is in the cloud-init source code)
<jtv> I'm looking at the cloud-init source now...
<rvba> I suspect the node can't reach the region and thus cloud-init falls back to using the EC2 metadata address.
<jtv> Ah, I was thinking it might not have received the right configuration...
<rvba> Well, I don't see how the EC2 IP could originate from MAAS.
<jtv> Neither do I...  I was thinking that cloud-init might not have received the right configuration, and decided to try things the EC2 way.
<jtv> I'm trying to figure out how cloud-init chooses the DataSource to use.
<rvba> That's possible indeed.  But from what freeflying was saying, it seems the configuration is right.
<rvba> freeflying: if cloud-init errors somehow (and uses the EC2 address as a â somewhat crezy â fallback), you will see errors on the node console while it is commissioningâ¦ do you have access to it?
<freeflying> rvba, you mean the kvm?
<jtv> The screen, yes.
<rvba> freeflying: well, the node's screen if it is a physical machine.
<freeflying> let me post a screenshot
<jtv> ("kvm" can be either the mouse/keyboard switch on a physical machine, or a commonly used type of virtual machine)
<freeflying> in this case, it mean mouse/keyboard :)
<rvba> Well, it's the V in KVM that I'm interested in :)
<freeflying> people.canonical.com/~zhengpenghou/20130920_162508.jpg
<freeflying> uploading
<jtv> Thanks
<jtv> Yup, that's cloud-init running out of DataSource candidates.
<rvba> Yep
<jtv> AFAICS cloud-init tries to download data from various sources, until it finds one that works.
<jtv> It's not finding any.
<freeflying> any suggestion?
<jtv> We'll have to find the root cause first...  Do you have a way of verifying that the nodes can reach the given IP address?
<rvba> When I encountered that problem (cloud-init was using the EC2 IP), it was because the node could not reach the MAAS IP address.
<rvba> So it's worth checking, as jtv said.
<jtv> It would be ideal if you could access the full URL on http...  if you get a 404, it's likely to be a problem in the URL configuration.
<jtv> If it's a permissions error, then it should just have worked and we have a mystery.
<jtv> If it's a networking error, then there's our problem.  :)
<freeflying> jtv, no, the node never fails to be commissioned
<jtv> I thought it failed during commissioning..?
<freeflying> jtv, funny thing is I do have 1 node commissioned :)
<freeflying> jtv, yes
<jtv> I don't understand... if it fails during commissining, then the node fails to be commissioned, right?
<freeflying> before cloud-init gives the error info, I did see the commissioning node get ip
<jtv> So DHCP is working...  did it get its IP from the right server?
<freeflying> jtv, I enlist 3 machines, 1 succeeded, not the other 2
<freeflying> jtv, yes
<rvba> Is there anything special about these two machines network-wise?
<freeflying> rvba, this could be a issue, but not sure
<jtv> Are all the nodes visible in the web UI, and similarly (correctly) configured?  If something went wrong there, they might fail to get to the metadata service.
<freeflying> jtv, all of them are listed in webui
<jtv> If we're very lucky, the metadata server log will show the nodes' requests...
<rvba> So one of them is "ready" and two of them stuck "commissioning", correct?
<freeflying> rvba, exactly
<freeflying> rvba, and have proxy set up in both commissioning/enlist_data
<freeflying> jtv, rvba would like t have a check?
<jtv> Always worth a check...  if you have a way to simulate an http request to that URL from the same node, that might tell us something too.
<jtv> (I should say: by "that URL" I mean the metadata URL)
<rvba> I see requests to the metadata service from 10.209.13.1{0,1,2,3}.
<jtv> freeflying: which node is the successful one?
<rvba> jtv: the errors in maas/maas.log are concerning
<rvba> The "PermissionDenied: Not authenticated as a known node." errors.
<jtv> And first, a problem registering the node group..?
<rvba> The two problems might be linkedâ¦
<jtv> Yup.
<jtv> Looks like the NodeGroupWithInterfacesForm.
<freeflying> jtv, working node called xggt6
<rvba> freeflying: we need its IP or it's uuid.
<jtv> freeflying: do you know the last number of its IP address?  We see 4 machines making requests to the metadata service.
<freeflying> rvba, 10.209.13.10
<jtv> Thanks!
<rvba> freeflying: you said you had a config with 2 clusters right?
<rvba> s/had/have/
<freeflying> rvba, 1 cluster 1 regional
<rvba> freeflying: when you go to the settings page, do you see one or two cluster controllers?  (because there is one cluster alongside the region by default)
<freeflying> rvba, only 1
<rvba> Is it called 'master'?
<freeflying> rvba, we don't have maas-cluster-controller installed on regional
<freeflying> rvba, the one I can from webui is cluster-xxxxx
<rvba> freeflying: okay, I see.  Not having the maas-cluster-controller installed on the region is an untested setup.
<freeflying> rvba, hehe
<rvba> freeflying: the MAAS region has IP 10.208.11.203 right?
<rvba> Or is that the cluster machine?
<freeflying> that is cluster
<freeflying> regional is 204
<jtv> The 403 errors match the "Not authenticated as a known node" errors in the maas log.
<jtv> A kernel download failed at one point.  But that should either break commissioning completely, or leave it unaffected.
<rvba> freeflying: could you please run this in 'sudo maas shell': http://paste.ubuntu.com/6131745/ ?
<freeflying> jtv, when idid that error happen
<rvba> freeflying: it will just print information about the nodes and the clusters, to help us debug the problem.
<jtv> freeflying: that failure happened at 11:13:54 +0900
<freeflying> rvba, on it, give me secs
<freeflying> rvba, 1 nodegroup there, and 2 node
<rvba> freeflying: only two nodes total?  I though you said you had 3?
<rvba> thought*
<freeflying> jtv, during that time, we're still trying to configure them, and after that, roaksoax has reconfigure cluster
<jtv> Yeah, I think the 404 is harmless here or we'd have seen different failures.
<jtv> What IP addresses did you get from rvba's script?
<jtv> A paste of the output would be ideal.
<freeflying> rvba, sorry, forgot to say I deleted others stucked in commissioning
<rvba> freeflying: okay, can you try re-enlisting then re-commissioning the problematic nodes, then run that script again?
<freeflying> rvba, ok, give me mins :)
<freeflying> thanks
<rvba> freeflying: sorry but I'm a bit confused, you said you had 3 nodes total, but I can see 4 different IP adresses requesting the preseedâ¦
<freeflying> rvba, we actually have 31 machines, guess some one else powered on it
<rvba> Okay.
<freeflying> rvba, http://paste.ubuntu.com/6131822/
<rvba> freeflying: can you run [(n.ip_addresses(), n.system_id, n.nodegroup, n.architecture, n.status, n.hardware_details) for n in Node.objects.all()]
<rvba> freeflying: the output will be large :)
<freeflying> rvba, any module I shall import?
<rvba> freeflying: just 'from maasserver.models import Node'
<rvba> (nothing new compared to the previous commands)
<freeflying> Traceback (most recent call last):                                                                                                                 âÂ·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·
<freeflying>   File "<console>", line 1, in <module>                                                                                                            âÂ·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·
<freeflying> AttributeError: 'Node' object has no attribute 'ip_addresses'
<rvba> freeflying: ah, right, you're using the precise package.
<rvba> freeflying: could you run this: [(n.system_id, n.nodegroup, n.architecture, n.status, n.hardware_details) for n in Node.objects.all()]
<AskUbuntu> Should MaaS and Juju get installed on one of my servers or on a client system? | http://askubuntu.com/q/347866
<jtv> freeflying: I also have a bit of python I'd like to see the output to.
<jtv> from metadataserver.models import NodeKey
<jtv> for nk in NodeKey.objects.all():
<jtv>     print(nk.node.nodegroup.uuid, nk.node.system_id, len(nk.key))
<jtv>  <- that should tell us a bit (not the actual keys of course) about which oauth keys are being sent to which nodes.
<jtv> Because we're seeing those nodes fail to authenticate with those keys.
<freeflying> rvba, http://paste.ubuntu.com/6131873/
<freeflying> jtv, how can I redirect from python console to stdout
<jtv> Try:
<jtv> python <<EOF
<jtv> # Script code goes here
<jtv> EOF
<jtv> Ahem.  Not python, of course, but "sudo maas shell <<EOF"
<jtv> The <<EOF tells it to feed what comes next (until the EOF line) into stdin.
<jtv> To redirect: sudo maas shell >/tmp/my-output <<EOF
<rvba> freeflying: okay, so everything seems fine so far, you're got one allocated node and 3 commissioning nodesâ¦ did they get out of commissioning or are they stuck, same as before?
<freeflying> rvba, same
<rvba> freeflying: can you try removing the working node and re-enlist, re-commission it?
<rvba> freeflying: if that works, then there is definitely a difference between this node and the others (I suspect related to the network config).
<freeflying> jtv, no output
<freeflying> rvba, error: gomaasapi: got error back from server: 409 CONFLICT (Node cannot be released in its current state ('Commissioning').
<jtv> No output!?
<rvba> freeflying: wait, the node in question should not be commissioning.
<freeflying> jtv, no
<jtv> That would explain why the nodes fail to authenticate with the metadata service, but...
<freeflying> jtv, any configure I need change to get it fix?
 * freeflying gonna go, will be back late, need grab some food 
<jtv> freeflying: I think somehow either the input or the output must have been lost.  It's got to print at least one entry for the working node, and if all is normal, one for each of the other ones as well.
<rvba> freeflying: you can manually get rid of the juju environment and all the nodes using this: http://paste.ubuntu.com/6131943/
<rvba> freeflying: again, if you get one node commissioned, this means you need to investigate how the other nodes (the one stuck commissioning) differ from this one.
<rvba> freeflying: can these nodes download stuff from the internet for instance?
<rvba> freeflying_away: could you also show us how the cluster controller is configured? (the network config on the cluster page)
<jtv> At 14:02:22 there's a POST from the _successful_ node to a broken URL: /MAAS/api/1.0/nodes//MAAS/api/1.0/nodes/
<jtv> Oh, not broken apparently -- I'm told there's a workaround on the MAAS side for that.
<jtv> The other nodes are signaling to the metadata service...  their individual Node pages in the UI may show useful output.
<jtv> Later attempts to do that hit 403.  But the attempts around 14:02:27--14:02:45 got OK responses.
<freeflying> rvba, ok, so I'll delete all nodes, and re-enlist
<rvba> Yep, let's see if what you've seen before can reproduced.
<freeflying> besides this, anything else I shall try
<rvba> jtv: ^ ?
 * jtv can't think of anything
<freeflying> rvba, I left there office, so might not be able to watch the screen
<rvba> freeflying: if you can still reach the MAAS machine, then that will be enough.
<rvba> Like I said, I want to be sure that the odd behavior you've seen (one node fine, two nodes stuck) can be reproduced.
<freeflying> rvba, http://paste.ubuntu.com/6132269/
<freeflying> rvba, we use maas to manager another network, which is a 10 gig, will have all later on traffic go through this one
<rvba> freeflying: there is a problem right there, the network defined here is 10.208.11.203/24 and the nodes connect to the region using IPs like 10.209.13.10.
<rvba> freeflying: did you get one node commissioned, same as before?
<freeflying> 10.209.13.0/24 we use for pxe boot, because of hw limitation, 10 gig can't do pxe boot
<rvba> We're hitting the same problem we talked about before, MAAS can only deal with one interface right now, used for pxe booting and later on, the IP attached to that interface is the one juju services deployed on the node will use.
<rvba> Now I really wonder how you got one node commissioned successfully :).
<freeflying> rvba, for commissioning should be fine, we have tested it last week, difference is it was using single server for maas
<freeflying> rvba, we have no problem to enlist/commission node
<rvba> freeflying: hang on, the problem we've been trying to figure out today is that the nodes never get out of the commissioning phase.
<freeflying> rvba, yes,  despite the magical one :)
<rvba> freeflying: the whole problem revolves around the network setup.  The nodes need to connect to the region using an IP in the network defined on a cluster controller.
<rvba> freeflying: that's how MAAS figures out to which cluster a node belongs.
<rvba> freeflying: now, why did it work with one node, that's what needs to be investigated (did you change the cluster configuration half-way through?).
<freeflying> rvba, no, the only things has done is set up proxy in preseed
<freeflying> rvba, btw, the second network(10 gig's 10.208.11.0/24, managed by maas) never been used so far, no item in that dhcp leases file
<rvba> freeflying: the config of the cluster is what defined DHCP config.  The onlyl option I can see is that the config changed when MAAS was running.
<freeflying> rvba, no idea
<rvba> freeflying: what's in the DHCP config?  cluster machine, file /etc/dhcp/dhcpd.conf.
<freeflying> rvba, http://paste.ubuntu.com/6132485/
<rvba> freeflying: it defines 10.208.11.0/24.  How come the nodes have ips in 10.209.11.0/24?
<freeflying> rvba, because we use an external dhcp to provide pxe boot, so during this stage, its only use pxe boot network, which is 10.209.11.0/24
<rvba> freeflying: so the problem is there, the cluster is configured to manage DNS and DHCP (cf http://paste.ubuntu.com/6132269/).  So it believes the nodes will have IP addresses in the range defined here ie. [10.208.11.10 - 10.208.11.250].
<freeflying> rvba, as long as the node bootup, it will have the ip :) (after deploying)
<rvba> freeflying: yes, but like I said, MAAS uses the IP the node uses to connect to the region to figure out to which nodegroup it should belong.
<freeflying> rvba, during our testing last week, it worked :)
<freeflying> rvba, thats the thing confusing me now
<rvba> freeflying: what changed then?
<freeflying> rvba, split regional and cluster onto two servers
 * freeflying really tired, need some relax and rest
<freeflying> rvba, anyway, I can't continue on it today, thanks for you guys
<rvba> freeflying: I understand, it's pretty late for you.  This is indeed a networking problem, with the region and the cluster on different machines, the nodes use, to connect to the region, an IP adress which is not recognized as belonging to the nodegroup.
<rvba> nn freeflying
<allenap> freeflying: Would you be able to summarise what's happened today and email it with us in Red?
<freeflying> allenap, individually? or do you have a list?
<marlinc> Where are the MAAS power templates stored?
<kentb> While on the subject of power, maas seems to pre-populate the IPMI power parameters with a maas username and random password.  Is that even usable?  I've been going in and changing those to a known-working username/password without trying the one maas gives me.
<roaksoax> marlinc: depends on the version
<roaksoax> kentb: they work
<marlinc> I found out already :)
<roaksoax> kentb: maas creates them intentionally
<roaksoax> kentb: and doesn't prepopulate
<roaksoax> kentb: it access the BMC and adds them
<roaksoax> marlinc: cool :)
<kentb> roaksoax: ok. thanks for clarifying
#maas 2013-09-22
<AskUbuntu> juju can't reaching servers | http://askubuntu.com/q/348702
#maas 2014-09-15
<lordcirth> Are there alternate download mirrors for MAAS boot images?  I'm only getting 50 kB/s from the default source.
<bigjools> no, they are the only ones
<rvba> bigjools: Up for a review? https://code.launchpad.net/~rvb/maas/rework-new-lifecycle-migration/+merge/234490
<rvba> jtv: Could you please have a look?  It doesn't seem that Julian had time to look at it.
<jtv> Can do.
<jtv> rvba: done
<rvba> jtv: thanks for the review
<jtv> np
<jtv> rvba: landing failed... I'd just remove that encoding line from the migration.
<rvba> jtv: It's the usual "There are additional revisions which have not been approved in review. Please seek review and approval of these new revisions."
<jtv> Yes.
<jtv> Nowadays we need to wait for the branch scanner to catch up, apparently.
<jtv> rvba: was that your branch that just failed in the manual Jenkins run?  Timeout.  :(
<rvba> jtv: the one that failed is the branch with the addition of the NUCs.
<jtv> rvba: I see.  My branch seems to be doing pretty well in Jenkins.
<jtv> By the way, if you have time, would love a review!
<rvba> jtv: one branch reviewedâ¦
<jtv> Thanks!
<dpb1> Is there a way to add dummy entries to maas?
<dpb1> I guess vms are the closest thing?
<rljohnsn_web> hello, can maas provide baremetal non ubuntu distributions ?
<bigjools> rljohnsn_web: there's experimental support for that
<bigjools> dpb1: what do you mean by dummy? Test nodes?  If so then yes, VMs.
#maas 2014-09-16
<dpb1> bigjools: thx
<rljohnsn_web> bigjools: thanks, I'll google harder
<bigjools> rljohnsn_web: not sure that will help, it's not really published functionality yet
<rljohnsn_web> ahh
<bigjools> it's  very experimental
<jtv> Any reviewers available?  I have a documentation branch and a code branch up.
<jtv> Documentation: https://code.launchpad.net/~jtv/maas/doc-ipv6-usage/+merge/234768
<jtv> Code: https://code.launchpad.net/~jtv/maas/ipv6-gateway/+merge/234791
<rvba> jtv: I'll review the code branch now.
<jtv> Thanks!
<jtv> It'll actually make a section of my documentation obsolete.  :)
<jtv> And I see you have one up for review as well.
 * jtv wishes again that he'd pushed his "this-is-my-local-network-and-its-hosts-change-address-but-it's-OK" openssh upstream years ago instead of rushing to get his project finished
<med_> dannf et al: Congrats on the big AMD announce today.
 * med_ hasnt' seen dannf in 4evah
#maas 2014-09-17
<bigjools> jtv: congraulations, your UI typo branch was r 3000 in trunk
<jtv> \o/
<jtv> Not what you'd want for such a bit milestone, is it?
<bigjools> seems appropriate somehow :)
<MasterPiece> moin all
<MasterPiece> R a mirror available 4 maas?
<MasterPiece> Can I create new mirror 4 it?
<jtv> MasterPiece: a mirror of what?
<bigjools> there r n0 mirr0rs
<bigjools> he probably means the ephemerals
<jtv> Well before we guess, let's find out.  :)
<bigjools> someone asked this the other day so it's an *educated* guess :)
<MasterPiece> mirrors so that more speed in downloading images, packages, etc
<bigjools> you can use sstream-mirror dor the images
<bigjools> package archives are configured in MAAS itself, just pick a mirror
<MasterPiece> & in order to Product Line and local mirror :)
<bigjools> dor?  I mean for
<MasterPiece> And How Can I be a mirror 4 MAAS ?
<jtv> You mean MAAS itself?  People get it from the package archive mirror.
<jtv> So you're probably best off just picking an Ubuntu archive mirror near you, and maybe setting up a caching proxy.
<jtv> Oh, we also have the PPA packages of course.  I think either an archive proxy (like squid-deb-proxy or apt-proxy) or a regular caching http proxy would be best for those.
<MasterPiece> I wanna to be a new mirror for it, How this is possible ?
<jtv> MasterPiece: I don't understand the question.  What _exactly_ do you want to be a mirror for?
<rvba> jtv: quick question for you since you reviewed Julian's branch (https://code.launchpad.net/~julian-edwards/maas/apt-mirror-for-commissioning/+merge/234919).  Why is it okay to change the call to generate_user_data() to pass it a node when I see that it accepts only an optional nodegroup?  I'm probably missing somethingâ¦ ?
<jtv> rvba: I don't think I understand the question...  It accepted an optional nodegroup, used only for testing, and now it accepts a node.
<rvba> jtv: ah, right, my bad.  I misread the diff.  Sorry about that.
<jtv> No worries.
<MasterPiece> jtv, so that I have more and more speed in downloading them, local network is very faster than WWW network :)
<jtv> MasterPiece: so you don't want to be a mirror of anything, so much as speed up downloads?
<MasterPiece> jtv, Y
<jtv> Okay, what operations specifically would you like to speed up?
<MasterPiece> importing boot images
<jtv> In that case, I'd go with what bigjools said: sstream-mirror.
<jtv> We don't have a network of "official" mirrors as far as I know, but you can keep your own mirror that way and make it available to people you know locally.
<jtv> I don't know the details about how that works, unfortunately.  But you can use the MAAS API to tell MAAS to download images from your mirrored server.
<jtv> Look for "boot sources."
<MasterPiece> Thanks jtv and bigjools
<jtv> np
<rvba> allenap: Could you please review https://code.launchpad.net/~rvb/maas/rename-monitoring/+merge/234950 ?
<allenap> rvba: Sure. Do you want to talk Twisted too?
<rvba> allenap: I think I manage to answer my own Twisted question :).
<rvba> managed*
<rvba> allenap: not so why I have these 'committed' conflicts.  I accidentally committed a couple of conflicts in the pre-req branches but it's all fixed now.
<rvba> s/not so/not sure/
<rvba> allenap: it's fine now, I just forgot to push a revision.
<lamont> at what point does maas know the power type of the macine (assuming ipmi)?  I have a machine that's declining to have its power type show up by the time it's declared, which makes commissioning it a manual powercycle.
<lamont> s
<lamont> when I manually add the IPMI (2.0) info, commissioning happens at the click of a button
<roaksoax> lamont: that'd mean that MAAS failed to discover IPMI for whatever reason.
<roaksoax> lamont: what MAAS version are you using, (1.5?)
<roaksoax> lamont: there might also be a cloud image issue, or even the commissioning environment is not accessing the network
<smoser> hey
<smoser> so i just added a source as doc'd in http://maas.ubuntu.com/docs/bootsources.html
<smoser> how do i tell maas to import all sthos ?
<roaksoax> smoser: maas <user> boot-resources import
<smoser> http://paste.ubuntu.com/8366766/
<roaksoax> blake_r: ^^
<jhobbs> smoser: have you done 'maas refresh' lately?
<roaksoax> smoser: yeah that's with the latest 1.7
<lamont> roaksoax: 1.5.2+bzr2282-0ubuntu0.2
<blake_r> roaksoax: yeah that only works with 1.7
<lamont> and I want to say that it's an HP DL380 G7 or so
<smoser> well, i showed the dpkg-query
<smoser> that is from maas stable
<roaksoax> lamont: yeah, so first thing to check is whether enlistment/commissioning can actually access the network
<blake_r> smoser: you can start the import with boot-images
<smoser> how ?
<lamont> roaksoax: on 623, or on what port?  (after I manally teach maas how to talk to the ilo, it successfully turns thebox on for getting from declared => commissioning, and all is well
<smoser> blake_r, i guess i can just ask.. if i'm going to try to install ppc64el, do i have a chance with 1.6 ?
<roaksoax> lamont: right, so on enlistment/commissioning maas access the archives to download freeipmi tools to do IPMI discovery
<smoser> or should i use 1.7
<roaksoax> smoser: +1 on 1.7
<smoser> so you would use daily  ppa ?
<lamont> roaksoax: that may entirely be it
<lamont> roaksoax: can you clarify "the archives"?
<roaksoax> lamont: archive.ubuntu.com
<lamont> archive.u.c I suspect?
<blake_r> smoser: yes ppc64el should work on 1.6
<roaksoax> lamont: correct!
<lamont> roaksoax: that network has access to about 63% of the archive machines. :(
<lamont> thank you
<smoser> ok, blake_r then how do i import ?
<lamont> roaksoax: that is, Ihave enough to let me get it sorted.  thanks
<roaksoax> lamont: glad to help!
<roaksoax> smoser: maas admin boot-resources import -> that will import the images to the Image store
<roaksoax> smoser: and then the clusters will import the images themselves
<blake_r> roaksoax: not on 1.6
<roaksoax> blake_r: correct
<roaksoax> smoser: on 1.7 that above will work
<blake_r> smoser: maas admin node-group import-boot-images cluster-uuid
<smoser> thank you blake_r .
<smoser> roaksoax, i dont even have an ideal on where i would get 1.7
<blake_r> smoser: maas-maintainers/experimental
<roaksoax> blake_r: in 1.7, how can you tell the clusters to import the images from the image store?
<blake_r> roaksoax: that same command I just gave smoser
<blake_r> roaksoax: you have to do it for each cluster
<smoser> blake_r, lets say i did that
<roaksoax> blake_r: yeah, that makes sense
<smoser> and i didn't see any disk space disappearing
<smoser> where would i look for issue?
<roaksoax> smoser: what do you mean by that? the import of images finished successfuly?
<blake_r> smoser: /var/log/maas/celery.log
<smoser> blake_r, ok. i had not specified a '*' for label
<smoser> so it was not matchign anything
<smoser> blake_r, http://paste.ubuntu.com/8367010/
<smoser> what did i do wrong ther e?
<smoser> all i have is trusty
<smoser> shoot
<smoser> ok. so that was my fault (no utopic ppc64el images in daily stream)
<smoser> thats being fixed.
#maas 2014-09-18
<bradm> anyone about to help debug a juju + maas bootstrap issue?
<bigjools> bradm: shoot
<bradm> I'm not even sure if its a maas issue, or a juju one
<bradm> I've got this setup to a stage when I do a juju bootstrap, maas does the right ipmi power stuff to the tagged bootstrap node, powers it up, shoves the right ssh key into it
<bradm> but the bootstrap is sitting there in a loop around ssh into the host, and even when I get the command to work outside of the juju bootstrap environment, its still looping
<bigjools> fwiw maas is not putting the key on, juju is (via user data)
<bradm> ok, right.
<bigjools> can you ssh in manually?
<bradm> sure can.  with the exact command line its spewing out at me
<bradm> as in, I'm seeing lots of:
<bradm> 2014-09-18 00:15:43 DEBUG juju.utils.ssh ssh_openssh.go:129 running: ssh -o "StrictHostKeyChecking no" -o "PasswordAuthentication no" -o "ServerAliveInterval 30" -i /home/jujumanage/.juju/ssh/juju_id_rsa -i /home/jujumanage/.ssh/id_rsa ubuntu@apollo.maas /bin/bash
<bradm> and I've made that line work manually
<bigjools> but juju can't get in?
<bigjools> so sounds like a juju bug
<bigjools> is the DNS resolving?
<bradm> thats the last thing I fixed
<bradm> but its actually flipping between DNS and the IP
<bradm> and both work
<bigjools> ok
<bigjools> well if the exact same command line works manually .... smells bad for juju
<bigjools> at this point MAAS is out of the loop, it has handed the provisioned machine over
<bradm> right, I suspected as much, good to get it confirmed.
<bigjools> np
<bradm> I'll go chase down some juju folk now and see what I can find out
<bradm> although finding some in this timezone could be fun
<bigjools> bradm: there's plenty over in #juju-dev
<bradm> I just realised the bootstrap node has 1.20, and the unit can only see 1.18, going to fix that first before going too far
<bradm> not sure if its an issue, but still
<bradm> how odd, before destroying it complains about /var/lib/juju/nonce.txt does not exist
<bigjools> rvba: so, regarding the bug I filed today, bug 1370887
<ubot5> bug 1370887 in MAAS "No event is registered on a node for when the power monitor sees a problem" [High,Triaged] https://launchpad.net/bugs/1370887
<bigjools> in src/provisioningserver/rpc/power.py:power_query_failure(), the second yield never gets reached... I am WTFing
<bigjools> I put a log statement before and after the first yield and only the first log msg is shown
 * bigjools is experiencing many WTFs/minute
<rvba> bigjools: just added a comment on the bug.
<bigjools> rvba: 0_o
<bigjools> not happening here for me
<rvba> bigjools: anything suspicious in the logs?
<bigjools> the node gets a red dot
<bigjools> nothing in the logs other than  my first log msg and all the other things are as expected
<bigjools> AHA
<bigjools> maasserver.exceptions.NodeStateViolation: The status of the node is 4; this status cannot be transitioned to a corresponding failed status.
<bigjools> only appears as an exception
<bigjools> I looked at the transition table earlier and wondered why there was no entry for READY
<rvba> What do you mean no entry?
<rvba> I see READY â COMMISSIONING, ALLOCATED, â¦, BROKEN.
<bigjools> get_failed_status
<bigjools> nothing for READY
<rvba> Well, READY is a "stable" state (i.e. MAAS isn't doing anything with a READY node), so it cannot "fail".
<bigjools> this is not cool on the client side - it must have returned an exception but it's just silently bailed out
<bigjools> rvba: well, power failures are an exception
<bigjools> think of it as a health check for READY nodes
<rvba> Hum, indeed, there is clearly a problem in the code there.
<rvba> Either we change the periodic checks to only issue a warning or we make is so that READY has a corresponding "failed" node.
<bigjools> I think the latter
<bigjools> but additionally it should be able to bring it out of failed, so it's not the same failed state
<rvba> Agreed.
<rvba> bigjools: each active state (i.e. a state that can fail somehow) must have its own "failed" state so that we can bring the node back or retry.  "Broken" is the result of a user marking a node as unusable (probably after a failure of a node and a failure on the user's part to fix the pb).
<bigjools> ok, this explains the         Failure: twisted.protocols.amp.UnknownRemoteError: Code<UNKNOWN>: Unknown Error
<bigjools> in the pserv log
<bigjools> it's the exception getting swallowed up
 * bigjools has dinner on table along with laptop and is getting dodgy looks from wife, I'll speak to you in 30m
<gmb> bigjools: That's one of the more annoying rpc warts; if it gets an error it can't handle it kind of throws its hands up in the air. allenap and I discussed adding some kind of catch-all error handling so that we always got something meaningful back from rpc calls, but I don't think he's had chance to look at that yet.
 * gmb -> travelling;
<bigjools> rvba: is there a bug about the excessive pserv logging?
<rvba> bigjools: I don't think so :)
<jtv> Ugh.  Trying to run in a branch, but it keeps saying the cluster controller isn't connected.
<smoser> blake_r, have we managed to make ipmi for power8 work ?
<smoser> at least for power on and power off
<blake_r> smoser: out of band ipmi works
<blake_r> smoser: i have used it
<smoser> with maas ?
<blake_r> smoser: inband ipmi for enlistment does not work
<smoser> i thougth there was an issue due to need to not specify a password
<blake_r> smoser: yeah you do get a wierd error if the password is incorrect
<blake_r> smoser: I had a machine with a broken ipmi
<smoser> blake_r, i think they all have broken ipmi
<blake_r> smoser: also if i didn't put the commands in the correct order for impi tool it failed, which I thought was really strange
<blake_r> smoser: i gregory, I was able to power it on and off, and use sol
<smoser> blake_r, i'm talking about with maas
<blake_r> smoser: its using impi tool and it doesn't require any special flags, so I don't know why it wouldn't work
<smoser> blake_r the issue with maas is that yo uhave to specify a password
<smoser> but you cannot specify a username
<smoser> and alsok do you happen to know why
<smoser>  out = out.decode('utf-8')
<smoser> is not the same as
<smoser>  out = out.decode()
<smoser> https://docs.python.org/3/library/stdtypes.html#bytes.decode
<smoser>  Default encoding is 'utf-8'.
<blake_r> how is it not the same if its 'utf-8'?
<smoser> i'm asking because you accepted a patch to curtin that does:
<smoser> -            out = out.decode()
<smoser> +            out = out.decode('utf-8')
<smoser> and claimed it fixed a bug
<blake_r> oh I see
<blake_r> hmm...
<blake_r> he said it fixed it for him
<smoser> :-(
<blake_r> the enforce='replace' would have been better
<smoser> power is a pita.
<blake_r> haha
<smoser> that node i was playing with yesterday (gregory)
<smoser> at some point started pxebooting
<smoser> but now its back to not
<blake_r> oh that is the same one I used
<smoser> well, now it just pxebooted and i told it ot install via d-i
<smoser> so, i'll jsut wait.
<smoser> i think that curtin must not have been getting the PReP set up correctly
<smoser> and that the time it worked for me was just piggy backed on a previous d-i instal
<blake_r> yeah saw your bug
<blake_r> ahh
<smoser> did you understand what i was saying about ipmi ?
<smoser> you specifically cannot pass '-U' to ipmitool
<blake_r> yeah
<blake_r> yeah thats an issue
<smoser> its a rare thing for me.
<blake_r> so that wont work with 1.6 unless you modify the template
<blake_r> make a bug for 1.7 so we can add that option
<smoser> but i have to say, that i'm reallyhappy with how well current (1.6) maas worked for me.
<smoser> and that i could do everythign i needed via cli.
<blake_r> great! 1.7 will be even better
<blake_r> 1.7 can do custom images, so you can deploy your powerkvm image!
<smoser> oh. one thing..
<smoser> can i say "wait for cluster to boot images"
<smoser> or check progress of it ?
<blake_r> you want to check on the cli if the cluster has boot images?
<blake_r> maas admin boot-images read cluster_uuid
<blake_r> if that returns images then your good
<blake_r> you could also parse the json to make sure it has the image your wanting
<smoser>  http://paste.ubuntu.com/8372856/
<smoser> that is what i have done to install maas into a container on kurhah
<smoser> suck
<smoser> so my maas doesn't seem to be answering dns for me
<smoser> how do i enable it ?
<smoser> my cluster is set to be "Manage DHCP and DNS	"
<smoser> but i dont see any maas dns service runngin
<smoser> and dont 'knwo how i'd tell it where the "upstream dns" is.
<blake_r> smoser: you want to set upstream_dns over cmdline?
<smoser> i dont know where i set that in the ui either
<smoser> but, yes. i'd prefer that on cmdline
<blake_r> smoser: maas admin maas set-config name=upstream_dns value=192.168.2.1
<smoser> eithe rway, it doesn't seem like dns is runing on that system. so i'm confused on that too
<blake_r> smoser: once you set the dns server it will restart dns
<smoser> ie, host ubuntu.com localhost
<blake_r> smoser: watch celery.log to see if any errors occur
<smoser> should'nt it have started the dns server when i crated a cluster that had managed dns ?
<blake_r> it should have, but it will restart it when the upstream_dns changes so you can see if an error occurs
<smoser> it seems functional now.
<KCR> Hello, all. I have a question. When installing Ubuntu and I select the MAAS installation, why does it keep shutting down after I enter my MAAS box's address?
<KCR> I'm entering it like so: http://172.16.13.5/MAAS
#maas 2014-09-19
<rvba> jtv1: it's in /etc/maas/templates/deployment-user-data/maas_configure_interfaces.py
<jtv1> rvba: great, thanks.  That's the expected location.
<jtv1> I just mis-typed it earlier.
<rvba> Ah, okay.
<jtv> rvba: can I impose on your Django knowledge?
<jtv> I'm trying to set a computed default value for a form field.
<jtv> When I clean the field in the form, it's always present and its cleaned_data value is never None.
<jtv> The django docs say that setting an "initial" value is not the way to do this, but they don't say what is.
<jtv> (Even setting a callable default on the model wouldn't do the trick, because the default needs to refer to the Node object itself)
<rvba> jtv: I don't understand why you're saying that the field is always present and that its cleaned_data value is never None.  Is that a result of something you've done?
<rvba> jtv: why can't you set your default value in the form's __init__?
<jtv> Could be.  When my clean_<field> method (on the form) looks for self.cleaned_data.get(<field>) it never gets None back.
<jtv> Set it in the form's __init__?  Do I have the instance at that point, when the form is creating a new object?
<rvba> No, unless you create it yourself manually, then *update* it when save() is called.
<rvba> So, you want the initial value to depend on a non-yet created object?
<rvba> I don't understand.
<jtv> This is NodeForm; all I really need is its NodeGroup.
<jtv> If I can get that, I can get the default value.
<rvba> Then presumably you want to pass the nodegroup to the form's __init__ and derive the default value from it.
<rvba> Same as what NodeGroupDefineForm does with 'status'.
<jtv> rvba: so... overriding save() looks like the only way to set a computed default with access to the object's properties..?
<rvba> jtv: yes, save() is where the object is created by the form.
<rvba> jtv: but surely the data you need (the nodegroup) is part of the data sent to the form?
<jtv> Probably, yes.  I'm more worried at this stage about how I'll know whether a value was submitted for my field.
<rvba> jtv: if no value was submitted for the field, cleaned_data should be set to the default value.
<rvba> cleaned_data.get(field_name) that is
<jtv> The default _model_ value?
<jtv> Well stupid question I guess,
<jtv> since there doesn't seem to be a default form value.
<jtv> I guess I'd have to make the model-level field default to None, but disallow nulls?
<rvba> Yes, I assume the default model value is there when the form gets validated.
<rvba> I don't think you need to make the model-level field default to None.
<jtv> Well it's a boolean field that can't be null, and I need a way to know whether a value was provided to the form...
<jtv> I get the impression that the model is the only level where I can provide a default.
<jtv> (Unless we count "initial" which the docs say won't do this.)
 * jtv eats for a bit
 * rvba â lunch
<jtv> Arrrrrgh!  My problem was in factory.make_NodeGroup accepting my new field but not passing it on!
<jtv> That's why my test failed: the default was always False, even if I explicitly set it to True.
<jtv> Question now is: at what point in all my experiments did the test start failing for that reason?
<jtv> Urgh.  That's enough for tonight.  Have a good weekend everyone.
#maas 2014-09-21
<failedinst> tried to install maas on virtual box servers and still can't get the boot images imported
<failedinst> i tried ti import then manually but then i cant contact de maas web ui
<failedinst> annyone got it?
<failedinst> i get now only error 500
<failedinst> I'll give it up...
<failedinst> will try again next weekend....
#maas 2015-09-14
<mup> Bug #1463378 changed: Downloaded di-initrd on trusty/amd64 overrides /etc/network/interfaces <canonical-bootstack> <MAAS:Expired> <https://launchpad.net/bugs/1463378>
<ubot5> Ubuntu bug 1463378 in MAAS "Downloaded di-initrd on trusty/amd64 overrides /etc/network/interfaces" [Undecided,Expired]
<james> ERROR 2015-09-14 13:53:59,385 maasserver Unable to get RPC connection for cluster 'Cluster master' (master
<Guest9421> getting above error while trying to creat the cluster interface
<Guest9421> any idea
<Guest9421> ?
<mup> Bug #1495555 opened: Libvirt should be a dependant package for maas install <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1495555>
<ubot5> Ubuntu bug 1495555 in MAAS "Libvirt should be a dependant package for maas install" [Undecided,New]
<mup> Bug #1495555 changed: Libvirt should be a dependant package for maas install <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1495555>
<ubot5> Ubuntu bug 1495555 in MAAS "Libvirt should be a dependant package for maas install" [Undecided,New]
<mup> Bug #1495555 opened: Libvirt should be a dependant package for maas install <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1495555>
<ubot5> Ubuntu bug 1495555 in MAAS "Libvirt should be a dependant package for maas install" [Undecided,New]
<mup> Bug #1495636 opened: no python3 bindings in package for apiclient <amd64> <apport-bug> <wily> <maas (Ubuntu):New> <https://launchpad.net/bugs/1495636>
<ubot5> Ubuntu bug 1495636 in maas (Ubuntu) "no python3 bindings in package for apiclient" [Undecided,New]
<mup> Bug #1495636 changed: no python3 bindings in package for apiclient <amd64> <apport-bug> <wily> <maas (Ubuntu):New> <https://launchpad.net/bugs/1495636>
<ubot5> Ubuntu bug 1495636 in maas (Ubuntu) "no python3 bindings in package for apiclient" [Undecided,New]
<mup> Bug #1495636 opened: no python3 bindings in package for apiclient <amd64> <apport-bug> <wily> <maas (Ubuntu):New> <https://launchpad.net/bugs/1495636>
<ubot5> Ubuntu bug 1495636 in maas (Ubuntu) "no python3 bindings in package for apiclient" [Undecided,New]
<mup> Bug #1495555 changed: Libvirt should be a dependant package for maas install <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1495555>
<ubot5> Ubuntu bug 1381000 in MAAS 1.8 "duplicate for #1495555 UI doesn't warn about missing power management tools" [Critical,Triaged]
<mup> Bug #1423592 changed: Only one place to declare the OS for the Machine <MAAS:Opinion> <https://launchpad.net/bugs/1423592>
<ubot5> Ubuntu bug 1423592 in MAAS "Only one place to declare the OS for the Machine" [Wishlist,Opinion]
#maas 2015-09-15
<mup> Bug #1495775 opened: API: node-interface link-subnet mode parameter is case sensitive <MAAS:New> <https://launchpad.net/bugs/1495775>
<ubot5> Ubuntu bug 1495775 in MAAS "API: node-interface link-subnet mode parameter is case sensitive" [Undecided,New]
<mup> Bug #1495775 changed: API: node-interface link-subnet mode parameter is case sensitive <MAAS:New> <https://launchpad.net/bugs/1495775>
<ubot5> Ubuntu bug 1495775 in MAAS "API: node-interface link-subnet mode parameter is case sensitive" [High,Triaged]
<mup> Bug #1495775 opened: API: node-interface link-subnet mode parameter is case sensitive <MAAS:New> <https://launchpad.net/bugs/1495775>
<ubot5> Ubuntu bug 1495775 in MAAS "API: node-interface link-subnet mode parameter is case sensitive" [High,Triaged]
<mup> Bug #1495779 opened: Unlinking a link_up subnet causes it to be replaced with another link_up subnet <MAAS:Triaged> <https://launchpad.net/bugs/1495779>
<ubot5> Ubuntu bug 1495779 in MAAS "Unlinking a link_up subnet causes it to be replaced with another link_up subnet" [Medium,Triaged]
<mup> Bug #1495779 changed: Unlinking a link_up subnet causes it to be replaced with another link_up subnet <MAAS:Triaged> <https://launchpad.net/bugs/1495779>
<ubot5> Ubuntu bug 1495779 in MAAS "Unlinking a link_up subnet causes it to be replaced with another link_up subnet" [Medium,Triaged]
<mup> Bug #1495779 opened: Unlinking a link_up subnet causes it to be replaced with another link_up subnet <MAAS:Triaged> <https://launchpad.net/bugs/1495779>
<ubot5> Ubuntu bug 1495779 in MAAS "Unlinking a link_up subnet causes it to be replaced with another link_up subnet" [Medium,Triaged]
<mup> Bug #1495845 opened: node-interfaces create-bond API specifies parents in an awkward way <MAAS:Triaged> <https://launchpad.net/bugs/1495845>
<mup> Bug #1495849 opened: 1.9: networking APIs need usability improvements <MAAS:Triaged> <https://launchpad.net/bugs/1495849>
<ubot5> Ubuntu bug 1495845 in MAAS "node-interfaces create-bond API specifies parents in an awkward way" [Medium,Triaged]
<ubot5> Ubuntu bug 1495849 in MAAS "1.9: networking APIs need usability improvements" [Medium,Triaged]
<mup> Bug #1495889 opened: StaticIPAddress object can't be deleted because its id attribute is set to None <networking> <MAAS:Triaged> <https://launchpad.net/bugs/1495889>
<ubot5> Ubuntu bug 1495889 in MAAS "StaticIPAddress object can't be deleted because its id attribute is set to None" [High,Triaged]
<mup> Bug #1495889 changed: StaticIPAddress object can't be deleted because its id attribute is set to None <networking> <MAAS:Triaged> <https://launchpad.net/bugs/1495889>
<ubot5> Ubuntu bug 1495889 in MAAS "StaticIPAddress object can't be deleted because its id attribute is set to None" [High,Triaged]
<mup> Bug #1495889 opened: StaticIPAddress object can't be deleted because its id attribute is set to None <networking> <MAAS:Triaged> <https://launchpad.net/bugs/1495889>
<ubot5> Ubuntu bug 1495889 in MAAS "StaticIPAddress object can't be deleted because its id attribute is set to None" [High,Triaged]
<mup> Bug #1495779 changed: Unlinking a link_up subnet causes it to be replaced with another link_up subnet <MAAS:Invalid> <https://launchpad.net/bugs/1495779>
<mup> Bug #1495779 opened: Unlinking a link_up subnet causes it to be replaced with another link_up subnet <MAAS:Invalid> <https://launchpad.net/bugs/1495779>
<mup> Bug #1495779 changed: Unlinking a link_up subnet causes it to be replaced with another link_up subnet <MAAS:Invalid> <https://launchpad.net/bugs/1495779>
<mup> Bug #1495998 opened: Maas allows changing of deployed node's name - maasserver.models.dhcplease.MultipleObjectsReturned: Got more than one item <oil> <MAAS:New> <https://launchpad.net/bugs/1495998>
<mup> Bug #1496097 opened: Unable to delete node due to maasserver_interface_ip_address violation <MAAS:Triaged by blake-rouse> <https://launchpad.net/bugs/1496097>
<mup> Bug #1496097 changed: Unable to delete node due to maasserver_interface_ip_address violation <MAAS:Triaged by blake-rouse> <https://launchpad.net/bugs/1496097>
<mup> Bug #1496097 opened: Unable to delete node due to maasserver_interface_ip_address violation <MAAS:Triaged by blake-rouse> <https://launchpad.net/bugs/1496097>
<mup> Bug #1496157 opened: Automatic Discovery Incorrect power type Moonshot  iLO - (ipmi) <MAAS:New> <https://launchpad.net/bugs/1496157>
<mup> Bug #1496157 changed: Automatic Discovery Incorrect power type Moonshot  iLO - (ipmi) <MAAS:Invalid> <https://launchpad.net/bugs/1496157>
<mup> Bug #1496157 opened: Automatic Discovery Incorrect power type Moonshot  iLO - (ipmi) <MAAS:Invalid> <https://launchpad.net/bugs/1496157>
<mup> Bug #1496157 changed: Automatic Discovery Incorrect power type Moonshot  iLO - (ipmi) <MAAS:Invalid> <https://launchpad.net/bugs/1496157>
#maas 2015-09-16
<ennoble> Is there a way to tell MaaS to install on a specific storage device (or at least storage device type) on the server?
<mup> Bug #1496339 opened: Problem installing fixture '.../src/maasserver/fixtures/dev_fixture.yaml <dev-environment> <MAAS:Triaged> <https://launchpad.net/bugs/1496339>
* allenap changed the topic of #maas to:  MAAS: Ubuntu's bare-metal provisioning tool | Docs: http://maas.ubuntu.com/ | Mailing list: https://launchpad.net/~maas-devel
<mup> Bug #1496339 changed: Problem installing fixture '.../src/maasserver/fixtures/dev_fixture.yaml <dev-environment> <MAAS:Triaged> <https://launchpad.net/bugs/1496339>
<mup> Bug #1496339 opened: Problem installing fixture '.../src/maasserver/fixtures/dev_fixture.yaml <dev-environment> <MAAS:Triaged> <https://launchpad.net/bugs/1496339>
<binoy> how to post in maas api
<binoy> using maas-client
<binoy> hi
<mup> Bug #1496360 opened: POST request using python-maas-client <MAAS:New> <https://launchpad.net/bugs/1496360>
<mup> Bug #1496360 changed: POST request using python-maas-client <MAAS:New> <https://launchpad.net/bugs/1496360>
<mup> Bug #1496360 opened: POST request using python-maas-client <MAAS:New> <https://launchpad.net/bugs/1496360>
<mup> Bug #1496360 changed: POST request using python-maas-client <MAAS:Invalid> <https://launchpad.net/bugs/1496360>
<binoy> https://bugs.launchpad.net/maas/+bug/1496360
<mup> Bug #1496360 opened: POST request using python-maas-client <MAAS:New> <https://launchpad.net/bugs/1496360>
<binoy_> https://bugs.launchpad.net/maas/+bug/1496360
<mup> Bug #1496360 changed: POST request using python-maas-client <MAAS:New> <https://launchpad.net/bugs/1496360>
<mup> Bug #1496360 opened: POST request using python-maas-client <MAAS:Invalid> <https://launchpad.net/bugs/1496360>
<David_Orange> Hello MAASters
<kiko> hello there!
<kiko> David_Orange, can I help?
<David_Orange> kiko: I go an issue with my MAAS. I Got 2 interfaces and the DHCP is on the second one
<David_Orange> The data source sent to my node is pointing to the ip of the fist interface, where can I change that ?
<kiko> David_Orange, can you explain a bit more -- 2 interfaces on a node or on the maas cluster controllers?
<David_Orange> kiko: sorry, My master have 2 interfaces, one for admin and the 2 second on for the provisioning of other nodes
<David_Orange> and when the node start the commisionning it receive a bad address:
<kiko> David_Orange, by master I assuming you mean the cluster controller? :)
<David_Orange> MAAS: {consumer_key: DnebRm9DqCDDDYPVJC, metadata_url: 'http://192.168.0.53/MAAS/metadata/',
<kiko> David_Orange, what version of MAAS, incidentally?
<David_Orange> yes
<David_Orange> the last one, I check
<kiko> please check with dpkg -l | grep maas
<David_Orange> 1.7.6
<kiko> thanks
<David_Orange> 1.7.6+bzr3376-0ubuntu2~15.04.1
<kiko> thanks
<kiko> okay. so you have a cluster controller with two interfaces. what have you configured in the clusters page?
<binoy_> https://bugs.launchpad.net/maas/+bug/1496360
<David_Orange> I check
<David_Orange> one interface configured on eth1
<David_Orange> but eth0 waas configured then removed
<kiko> okay
<kiko> so what you are seeing is that the node is getting the address for eth0 when commissioning?
<David_Orange> in the preseed of the node,
<David_Orange> http://pastebin.geany.org/u4dy9/
<David_Orange> the metadata_url should point to the other network (192.168.2.0)
<David_Orange> Am I clear enough ?
<David_Orange> kiko: I change the setting maas_url in the maas_cluster.conf and it seems to change te preseed, I  try a new commisioning
<kiko> David_Orange, I was going to say exactly that -- your maas_url may be wrong
<David_Orange> kiko: yes, and it works
<David_Orange> Have I missed a doc somewhere ?
<kiko> David_Orange, thanks very much. the maas_url being wrong is a visibility problem and there is a bug reported for it
<David_Orange> ok, thanks a lot for your time to help me
<mup> Bug #1496401 opened: Failure to grab the secret.lock <MAAS:Triaged> <https://launchpad.net/bugs/1496401>
<David_Orange> kiko, I continue my tests. Thanks !
<mup> Bug #1496401 changed: Failure to grab the secret.lock <MAAS:Triaged> <https://launchpad.net/bugs/1496401>
<mup> Bug #1496360 changed: POST request using python-maas-client <MAAS:Invalid> <https://launchpad.net/bugs/1496360>
<mup> Bug #1496401 opened: Failure to grab the secret.lock <MAAS:Triaged> <https://launchpad.net/bugs/1496401>
<mup> Bug #1496360 opened: POST request using python-maas-client <MAAS:Invalid> <https://launchpad.net/bugs/1496360>
<mup> Bug #1496360 changed: POST request using python-maas-client <MAAS:Invalid> <https://launchpad.net/bugs/1496360>
<kflavin> I'm trying to setup the region controller and cluster controller on separate servers.  I have two cluster controllers.  When I attempt to import images, I get an exception in the pserv.log.  When I dig a little further, I see it's a 500 error, caused by a database connection problem.
<kflavin> Here is the error that shows up in the apache logs: http://pastebin.com/iVJjUpRK
<kflavin> It looks like the cluster controller is trying to contact a database running locally, when it should be talking to the database on the region controller?
<kflavin> Did I miss something during setup?  The cluster controller appeared to add correctly to the region controller, and I can see it from the web UI.
<mup> Bug #1496469 opened: IBM Power8 will not PXE boot to MAAS 1.8 <blocks-hwcert> <MAAS:New> <https://launchpad.net/bugs/1496469>
<mup> Bug #1496469 changed: IBM Power8 will not PXE boot to MAAS 1.8 <blocks-hwcert> <MAAS:New> <https://launchpad.net/bugs/1496469>
<mup> Bug #1496469 opened: IBM Power8 will not PXE boot to MAAS 1.8 <blocks-hwcert> <MAAS:New> <https://launchpad.net/bugs/1496469>
<mup> Bug #1496562 opened: 1.9 doesn't set the dns-search option in the generate /etc/network/interfaces <networking> <curtin:Triaged> <MAAS:Triaged by blake-rouse> <https://launchpad.net/bugs/1496562>
#maas 2015-09-17
<mup> Bug #1496360 opened: POST request using python-maas-client <MAAS:Incomplete> <https://launchpad.net/bugs/1496360>
<binoy> https://bugs.launchpad.net/maas/+bug/1496360
<binoy> hi
<binoy> https://bugs.launchpad.net/maas/+bug/1496360
<binoy> how to implement post with data in maas api
<kiko> good morning
<mup> Bug #1496360 changed: POST request using python-maas-client <MAAS:Invalid> <https://launchpad.net/bugs/1496360>
<mup> Bug #1496961 opened: Ephemeral environment during curtin installation doesn't use proxy <MAAS:Confirmed> <https://launchpad.net/bugs/1496961>
<mup> Bug #1402042 changed: console= parameters need to be added before -- on kernel cmdline <verification-done> <curtin:Fix Committed> <MAAS:Fix Committed> <MAAS 1.7:Triaged> <MAAS 1.8:Fix Released> <MAAS trunk:Fix Committed> <curtin (Ubuntu):Fix Released> <debian-installer (Ubuntu):Fix Released>
<mup> <debian-installer-utils (Ubuntu):Fix Released> <maas (Ubuntu):Fix Released> <debian-installer-utils (Ubuntu Precise):Fix Released by mathieu-tl> <maas (Ubuntu Precise):Confirmed> <curtin (Ubuntu Trusty):Confirmed> <debian-installer (Ubuntu Trusty):Fix Released> <debian-installer-utils (Ubuntu
<mup> Trusty):Fix Released by mathieu-tl> <maas (Ubuntu Trusty):Confirmed> <curtin (Ubuntu Utopic):Won't Fix> <debian-installer (Ubuntu Utopic):Fix Released> <debian-installer-utils (Ubuntu Utopic):Fix Released by mathieu-tl> <maas (Ubuntu Utopic):Confirmed> <curtin (Ubuntu Vivid):Confirmed>
<mup> <debian-installer (Ubuntu Vivid):Fix Released> <debian-installer-utils (Ubuntu Vivid):Fix Released> <maas (Ubuntu Vivid):Confirmed> <curtin (Ubuntu Wily):Fix Released> <debian-installer (Ubuntu Wily):Fix Released> <debian-installer-utils (Ubuntu Wily):Fix Released> <maas (Ubuntu Wily):Fix Released>
<mup> <Debian:Fix Released> <https://launchpad.net/bugs/1402042>
<catbus1> blake_r: Hi, about the sles deploy, the installation output says it's finished, but MAAS reports failed deployment. I have seen this before, but the next time I deployed when it happened before, it worked.
<catbus1> blake_r: now I have re-deployed sles several times with consistent failed deployment result.
<catbus1> blake_r: what does MAAS do in the final stage when the node installation is finished?
<blake_r> catbus1: it needs to reboot and cloud-init talk to maas which looks like its not working
<catbus1> I have seen it working before. I am recommissioning the server to double check. We had several changes on the network interface configuration recently. But I remember we had recommissioned all server earlier after the last maas network change.
<catbus1> s/server/servers
<catbus1> blake_r: still the same.
<catbus1> blake_r: there wasn't much traffic on that network. the only other area where I think is a problem is we used to use 10G to provision bare metal, now we are using 1G.
<catbus1> we have no problem provisioning ubuntu server with maas, all the time.
<dannf> is there something that needs to be done to "activate" maas-dhcp other than installing it? my /etc/maas/dhcpd.conf just says "# DHCP server stopped and disabled."
#maas 2015-09-18
<ejat> openstack-dashboard timeout when i tried to login
<ejat> what should i do ?
<mup> Bug #1468726 changed: Retain page position on refresh <ui> <MAAS:Won't Fix> <https://launchpad.net/bugs/1468726>
<kiko> good morning
<mup> Bug #1497392 opened: maas text-mode "node-group-interface" bug fails with MAAS 1.8.2+bzr4041-0ubuntu1~trusty1 <MAAS:New> <https://launchpad.net/bugs/1497392>
<mup> Bug #1497392 changed: maas text-mode "node-group-interface" bug fails with MAAS 1.8.2+bzr4041-0ubuntu1~trusty1 <MAAS:New> <https://launchpad.net/bugs/1497392>
<mup> Bug #1497392 opened: maas text-mode "node-group-interface" bug fails with MAAS 1.8.2+bzr4041-0ubuntu1~trusty1 <MAAS:New> <https://launchpad.net/bugs/1497392>
<nodtkn> Howdy.  The ubuntu vivid root-tgz files are missing the python-yaml package that is required for me to juju add a newly installed node.  Does anyone know of documentation for modifying the root image.  Ideally I would like to mount it, add the python-yaml package, unmount it, and load it as a custom image in MAAS.
<mgz> nodtkn: can't you just add python-yaml in your cloud-config in your dependencies? using non-stock root images is generally a bad idea.
<mgz> also, juju doesn't depend on python-yaml.
<nodtkn> mgz: I have modified my preseed files to install python-yaml, but that adds to my installation time.  I am always installing a few things like build-essentials so I would rather do it in a custom image.
<nodtkn> mgz:  Are you sure about python-yaml not being required.  I was getting errors when I attempted to add vivid nodes and preinstalling python-yaml removed those erros.
<nodtkn> mgz:  It might have been that bootstrap was failing instead of add-machine.
<ennoble> Is there a way to have maas install on a specific type of media (e.g. hd vs. ssd  vs. nvme)?
<nodtkn> mgz:  My mistake it was a failure at juju deploy so I would have to log in to the host and run apt-get install python-yaml before I could deploy a service that used charmhelpers.
<mgz> nodtkn: yeah, you just want to fix the charm install hook it sounds like
<nodtkn> mgz: That would be nice, but I generally I think the ability to create a custom ubuntu image would be awesome.   I could modify it to run the latest kernel, update all of the packages (instead having to call apt-get upgrade), and install all of the common packages that are needed by my charms.
<roaksoax> /w/win 7
<kiko> nodtkn, yep, we agree -- this is something we've been thinking about how to automate and make easier
<nodtkn> kiko: I tried out the maas-image-builder I was thinking if it worked for centos I would attempt to modify it to work with ubuntu.
<ennoble> is there a way to control what media maas provisions the machines with when multiple storage types are connected?
#maas 2015-09-19
<mup> Bug #1497480 opened: curtin userdata fails if 'kernel' entry lacks 'mapping' key <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1497480>
<mup> Bug #1497480 changed: curtin userdata fails if 'kernel' entry lacks 'mapping' key <canonical-bootstack> <curtin:New> <https://launchpad.net/bugs/1497480>
<mup> Bug #1482589 changed: test_size_is_rounded_to_next_block is flaky <MAAS:Invalid> <https://launchpad.net/bugs/1482589>
<mup> Bug #1482589 opened: test_size_is_rounded_to_next_block is flaky <MAAS:Invalid> <https://launchpad.net/bugs/1482589>
<mup> Bug #1482589 changed: test_size_is_rounded_to_next_block is flaky <MAAS:Invalid> <https://launchpad.net/bugs/1482589>
<mup> Bug #1464281 changed: 1.8rc3: Incorrect IP Address label in UI (dynamic) under Network->IP for previous static IP address. Deployment gets static IP <oil> <MAAS:Invalid> <MAAS 1.8:Won't Fix> <https://launchpad.net/bugs/1464281>
<mup> Bug #1464281 opened: 1.8rc3: Incorrect IP Address label in UI (dynamic) under Network->IP for previous static IP address. Deployment gets static IP <oil> <MAAS:Invalid> <MAAS 1.8:Won't Fix> <https://launchpad.net/bugs/1464281>
<mup> Bug #1464281 changed: 1.8rc3: Incorrect IP Address label in UI (dynamic) under Network->IP for previous static IP address. Deployment gets static IP <oil> <MAAS:Invalid> <MAAS 1.8:Won't Fix> <https://launchpad.net/bugs/1464281>
<mup> Bug #1464281 opened: 1.8rc3: Incorrect IP Address label in UI (dynamic) under Network->IP for previous static IP address. Deployment gets static IP <oil> <MAAS:Invalid> <MAAS 1.8:Won't Fix> <https://launchpad.net/bugs/1464281>
<mup> Bug #1464281 changed: 1.8rc3: Incorrect IP Address label in UI (dynamic) under Network->IP for previous static IP address. Deployment gets static IP <oil> <MAAS:Invalid> <https://launchpad.net/bugs/1464281>
<mup> Bug #1469874 changed: MAAS 1.8 not allowed to edit node details in gui after upgrade <maas> <maas-gui> <MAAS:Invalid> <https://launchpad.net/bugs/1469874>
<nburtsev> Hello. Anyone knows if code that automatically detects nodegroup for node during enlistment is broken?
<nburtsev> because it tries to find a nodegroup from ip address of whever enlistment request came from, which supposedly is (or was) cluster controller, but it actually has 127.0.0.1 in that field
#maas 2016-09-19
<nirlevy> Exception in ev.run(): Traceback (most recent call last):   File "/usr/share/openstack/cloudinstall/ev.py", line 128, in run     self.loop.run()
<nirlevy> installing openstack auto pilot I am getting the following, any clues,Thanks.
<nirlevy> in addition, although I have defined the DNS in /etc/network/interfaces it assumes DNS is the host node itself.
<nirlevy> Hi all,
<nirlevy> I keep getting error "(network unreachable) resolving './DNSKEY/IN': 2001:7fd::1#53" trying to install MAAS autopilot, any suggestions?
<evidex> Could anyone provide an example of passing user_data when starting a node through the MAAS cli?
<evidex> Or it is something that's only possible via the 'deploy' REST api?
<brendand> evidex, the cli mirrors the api so it should be possible
<evidex> brendand: For the love of me, I can't find any documentation on how to actually do it via the CLI, nor does the command help text show it :/
<brendand> evidex, the parameter is 'user_data=', did you try that?
<brendand> maas maas machine deploy <system_id> user_data=<base64 encoded unicode>
<evidex> ^just figured it out as you replied, thank you
<evidex> Once you mentioned that the CLI mirrors the API it was pretty obvious
<evidex> Thanks!
<mup> Bug #1593344 changed: [2.0b8] Dropdown shadow's have disappeared and dropdown mixes with background <ux> <MAAS:Fix Released by ricgard> <https://launchpad.net/bugs/1593344>
<mup> Bug #1565731 changed: Rack controller details - change ânetworkâ title to âinterfacesâ  <ui> <MAAS:Fix Released by ricgard> <https://launchpad.net/bugs/1565731>
<mup> Bug #1565734 changed: Change node name button incorrect <ui> <MAAS:Fix Released by ricgard> <https://launchpad.net/bugs/1565734>
<mup> Bug #1625156 opened: [2.1] Inconsistent casing of DHCP on vlan page <MAAS:New> <https://launchpad.net/bugs/1625156>
<mup> Bug #1623599 changed: [2.1, vanilla] Settings page do not have separators for the config sections <ui> <ux> <vanilla> <MAAS:New> <https://launchpad.net/bugs/1623599>
<mup> Bug #1625195 opened: Xenial deployments fail after updating boot-source to âdailyâ instead of âreleasesâ <MAAS:New> <https://launchpad.net/bugs/1625195>
<mup> Bug #1625195 changed: Xenial deployments fail after updating boot-source to âdailyâ instead of âreleasesâ <MAAS:New> <https://launchpad.net/bugs/1625195>
<mup> Bug #1625195 opened: Xenial deployments fail after updating boot-source to âdailyâ instead of âreleasesâ <MAAS:New> <https://launchpad.net/bugs/1625195>
<mup> Bug #1625195 changed: Xenial deployments fail after updating boot-source to âdailyâ instead of âreleasesâ <MAAS:New> <https://launchpad.net/bugs/1625195>
<PCdude> hello all :)
<PCdude> I am looking for a way to make MAAS 1.9 a HA  setup, what are some good docs I can read? in the MAAS docs itself it is only provided for 2.0 and up, but I heard some stories that 1.9 is also possible, but how?
<roaksoax> PCdude: 1.9 doesn't support HA
<roaksoax> PCdude: it is only 2.0+
<PCdude> roaksoax: really? I heard that someone could at least make the PXE part HA, is that right?
<roaksoax> PCdude: we haven't done it
<roaksoax> PCdude: we don't support it either
<PCdude> roaksoax: well then probably bad informed :) , thanks for the reaction anyway, but MAAS 2.0+ can be setup fully HA?
<roaksoax> PCdude: yes, MAAS 2.0 is ha, yes
<PCdude> roaksoax: lets hope JUJU is coming out of beta soon, thats the only reason I am not using MAAS 2.0 ....
<roaksoax> yeah, although in some places we are alreading using juju 2.0
<PCdude> roaksoax: are u an employee for canonical?
<boomboomboom> anyone using maas 2.0 with cisco ucs c servers?  having issues with ipmi
<boomboomboom> it's activated in cimc but no luck.  tried xmlapi with no sucessess either
#maas 2016-09-20
<rock__> roaksoax:  Hi. I have MAAS 1.9.4 0n trusty. And 4 physical servers commissioned. Now I want to test our Openstack bundle on MAAS. On MAAS node I installed juju 2.0. And then I followed  https://jujucharms.com/docs/2.0/clouds-maas. MAAS cloud juju model bootstrapping failed. Issue details :  http://paste.openstack.org/show/581940/. Can anyone help me in this.
<rock__> roaksoax: Please help if you have any idea on this MAAS cloud bootstrapping.
<rock__> roaksoax: from MAAS UI: Events Info:  http://paste.openstack.org/show/582228/
<rock__> roaksoax: Console of the server https://imagebin.ca/v/2vj11ogqr5ud.
<rock__> roaksoax: That deploying server released . MAAS UI Events info:  MAAS UI: Events Info: http://paste.openstack.org/show/582231/. That server released.
<baldpope> rock__, not sure - but sounds identical to what I'm working on this week
<baldpope> kiko had pointed me to a different article, 1sec
<baldpope> https://insights.ubuntu.com/2015/11/08/deploying-openstack-on-maas-1-9-with-juju/
<baldpope> also, these are probably of decent value - https://insights.ubuntu.com/?s=maas+1.9
<rock__> baldpope: Thank you. But my issue is different right. Once juju bootstrap done. Next directly we deploy the OpenStack base bundle here. You have successful  [MAAS+openstack base] bundle setup?.
<baldpope> no, keep getting interrupted by other work/prod issues
<baldpope> but the 'plan' was to setup maas (done, bm server) and then be able to deploy/bootstrap openstack through maas
<baldpope> the original doc I was following I was told is not correct, by kiko
<baldpope> he pointed me to some of the articles I posted a moment ago
<baldpope> there's a at least 1 other person on the same path as you and I
<baldpope> and kiko and some of the other channel participants have been helpful
<baldpope> if you have questions, post and stay idle - someone will be along who can answer
<baldpope> are you attempting to deploy openstack through the juju charm?
<baldpope> side note - curious how you have your networking configured for the openstack servers
<baldpope> i have 5 boxes with a total of 7 nics, 1 ilom/ipmi , 2 on board, 4 via secondary nic
<baldpope> i had planned to put the 2 onboard into a lag, and use that as the networking for traffic, and then the 4 in a lag for disk sharing
<roaksoax> rock__: it seems you aborted the deployment
<roaksoax> or something aborted the deployment
<rock__> roaksoax: Yesterday, It worked fine. But today due some other issue I reconfigured everything. Then I tried 5 times to bootstrap the maas cloud. But it was giving the same issue. I reconfigured MAAS again. But facing the same issue. How can I resolve this. Do you have any idea? please help me.
<rock__> roaksoax: MAAS able to commission successfuly everytime. But curtin installation is aborting.
<roaksoax> rock__: what I see in the logs is the machine moves from Ready -> Deploying to Deploying -> Releasing -> Ready
<roaksoax> rock__: if it went through "Releasing" that means someone told MAAS to release the machine
<roaksoax> rock__: and that /may/ be juju
<rock__> baldpope: Yes. I am thinkng that might be a juju bootstrap timeout. I am not sure. But Yesterday when I was doing the same thing curtin installation moving fastly without taking much time. Nearly it was taking 30 min. But today curtin installation has taken 30 min. But not bootstrapped.
<rock__> roaksoax: sorry. previous message pointing you.
<rock__> roaksoax: So in this situation, any idea from your side?
<rock__> baldpope: I have taken 5 servers with 2 nics each. All are having IPMI connection.
<rock__> baldpope: On one server I installed VBox. On top of that I created one VM. In that VM I installed MAAS. In that server for, first nic I provided public network. Second nic I created as router. I done with port forwarding and masqurading.
<kenytux> hello everyone
<kenytux> I really want to ask a question!
<kiko> good morning
<baldpope> rock__, sounds nearly identical - only difference is I re-purposed an old dell 2950 to act as the maas head
<baldpope> kenytux, ask away - sup kiko
<kiko> kenytux, it's your lucky day, questions are allowed on tuesdays
<kenytux> you make happy
<kiko> we try
<baldpope> 0_q
<kenytux> thank you
<baldpope> kiko make happy make baldpope cry ;)
<kenytux> how can I deploy a debian distribution with MAAS 2.0 please?
<kenytux> There's a way?
<baldpope> kenytux, guessing you'd need to import a debian image?
<kenytux> yes
<baldpope> kenytux, found this after quick search -http://www.travnewmatic.com/2015/02/ubuntu-maas-maas-image-builder-centos-6.html
<roaksoax> kenytux: /win 4
<roaksoax> err
<roaksoax> kenytux: debain is not supported by defailt
<mup> Bug #1625636 opened: [2.1] bridge_all on allocate needs to bridge all unconfigured interfaces too <juju> <MAAS:Confirmed> <https://launchpad.net/bugs/1625636>
<kenytux> i've tried with image builder "maas-image-builder" on ubuntu 16.04/MAAS 2.0 failed at make step because of python version
<kenytux> is there clear steps should I do on iso file?
<kiko> kenytux, no clear steps unfortunately. we can help you with paid consulting, but the docs right now /are/ the source code for curtin
<kiko> I wish I had a better answer honestly and we are getting there
<kenytux> thank you very much!!!! ;)
<rock__> roaksoax: HI. I am trying to entire thing on MAAS 2.0. The node which is commissioning in MAAS 1.9 is not able to commission in MAAS 2.0. I mean not doing PXE boot to selected NIC. ERROR:  PXE-E51 ,  No DHCP (or) Proxy DHCP offers were received.
<rock__> roaksoax: Please help me in this. This is a network problem?
<kiko> rock__, maybe. the node is unable to get a DHCP response.
<kiko> rock__, have you enabled DHCP on the VLAN
<rock__> Kiko: How to enable in MAAS 2.0.? I gave DHCP and Static Ip ranges.
<rock__> Kiko: Yes. From MAAS2.0 UI, I observed   dhcpd, dhcpd6 not enabled. and rackd â Missing connections to 1 region controller(s).
<mup> Bug #1625663 opened: [2.1] CLI usage differs from actual command <ssh-import> <MAAS:Triaged> <https://launchpad.net/bugs/1625663>
<rock__> kiko: https://imagebin.ca/v/2vjhM0dTBu8E
<rock__> Kiko: please tell me how to enable DHCP in MAAS 2.0.
<mup> Bug #1625668 opened: [2.1] When trying to add SSH keys for a GH user that doesn't exist, there's no feedback <ssh-import> <MAAS:Triaged> <https://launchpad.net/bugs/1625668>
<nirlevy> Hi all, can someone exlain to me the DNS configuration in MAAS to be use by landscape install
<nirlevy> I believe I do not configure the private network correctly, once landscape is spawned it looks for DNS in the MAAS node, which should be somewhat configured/
<mup> Bug #1625668 changed: [2.1] When trying to add SSH keys for a GH user that doesn't exist, there's no feedback <ssh-import> <MAAS:Triaged> <https://launchpad.net/bugs/1625668>
<rock__> nirlevy: You are using MAAS 1.9 (or) MAAS 2.0?
<mup> Bug #1625668 opened: [2.1] When trying to add SSH keys for a GH user that doesn't exist, there's no feedback <ssh-import> <MAAS:Triaged> <https://launchpad.net/bugs/1625668>
<rock__> Kiko: From UI I enabled DHCP now. Thank you. Previouly I worked on MAAS 1.9.4. Present first time I am doing on MAAS 2.0
<nirlevy> kiko: MAAS 1.9
<nirlevy> MAAS Version 1.9.4+bzr4592-0ubuntu1 (trusty1) to be exact.
<nirlevy> which is the default for apt-get install maas  over ubuntu 14.04.5
<rock__> nirlevy: You got MAAS UI right?
<rock__> From MAAS UI, go to cluster there you will configure network interface. then modify "unmanaged" to "DHCP and DNS". Then mention static and dynamic ranges there.
<nirlevy> kiko, I have set clusters wrong previously, now I have public and private interfaces where private should be DHCP and DNS and public should be unmanaged.
<mup> Bug # changed: 1403257, 1452557, 1507724, 1512187, 1596522, 1597541, 1603590, 1607403, 1607980, 1609194, 1613701, 1613702, 1613704, 1615618, 1615686, 1616772,
<mup> 1616773, 1616962, 1617195, 1617591, 1617596, 1619202, 1620514, 1620903, 1621981, 1622770, 1623752, 1623753, 1624035, 1624154, 1624380, 1624516
<mup> Bug #1625671 opened: [2.1] Need better error message when trying to add SSH keys for LP/GH user that doesn't exist <ssh-import> <MAAS:Triaged> <https://launchpad.net/bugs/1625671>
<mup> Bug #1625674 opened: [2.1] No feedback when there are no keys to import from LP/GH <ssh-import> <MAAS:Triaged> <https://launchpad.net/bugs/1625674>
<mup> Bug #1625676 opened: [2.0, 2.1, UI] MAAS webui allows boot disk to be changed on an already deployed node <sts> <ui> <MAAS:Confirmed> <MAAS 2.0:New> <MAAS trunk:Confirmed> <https://launchpad.net/bugs/1625676>
<nirlevy> I do not get the DNS zone though
<mup> Bug #1625689 opened: default gateway cannot be set to fe80::/64 via web ui <MAAS:New> <https://launchpad.net/bugs/1625689>
<mup> Bug #1625707 opened: NTP servers on regions and racks do not run in orphan mode <ntp> <MAAS:Triaged> <https://launchpad.net/bugs/1625707>
<mup> Bug #1625709 opened: Rack controllers only sync NTP from region controllers, not externally <ntp> <MAAS:Triaged> <https://launchpad.net/bugs/1625709>
<mup> Bug #1625711 opened: Peer selection for NTP servers on region controllers is broken <ntp> <MAAS:Triaged> <https://launchpad.net/bugs/1625711>
<mup> Bug #1625714 opened: DHCP services on rack controllers only publishes NTP servers on rack controllers <ntp> <MAAS:Triaged> <https://launchpad.net/bugs/1625714>
<kkkkk> is there any requirements for conjure-up on 16.04?
<kkkkk> do i need unbuntu-desktop ?
<kiko> kkkkk, just apt-get install and go
<kkkkk> it's not working kiko
<kiko> kkkkk, that's not surprising, but without more information there's not much I can say! :)
<mup> Bug #1625809 opened: MAAS needs to detect and manage BMCs that are IPv6-only <maas-ipv6> <MAAS:New> <https://launchpad.net/bugs/1625809>
<mup> Bug #1625812 opened: [2.1] Error message is not user friendly <ssh-import> <MAAS:Triaged> <https://launchpad.net/bugs/1625812>
<kkkkk> kilo
<kkkkk> yaml.reader.ReaderError: unacceptable character #x0080: special characters are not allowed
<kkkkk>   in "<unicode string>", position 1971
<kkkkk>  i keep getting that error with conjure-up 2
<kiko> kkkkk, what are you deploying?
<kkkkk> i am trying to deploy openstack with maas 2
<kiko> mmcc, stokachu: any clue what this is?
<kiko> kkkkk, reads like a bug to me, though, maybe report it to launchpad?
 * kiko waves out for the night
<kkkkk> https://bugs.launchpad.net/ubuntu/+source/conjure-up/+bug/1625839
<mup> Bug #1625847 opened: IPv6 commissioning needs to aggregate /128 networks <maas-ipv6> <MAAS:New for lamont> <https://launchpad.net/bugs/1625847>
#maas 2016-09-21
<mup> Bug #1625910 opened: [2.1] MAAS doesn't have routing to BMC IP, but MAAS shows the power as ON <MAAS:New> <https://launchpad.net/bugs/1625910>
<sujeet_> Hi roaksoax
<sujeet_> Hi kiko
<NewJorg> Hello, is there a way to access the tags of a machine in commissioning? We have some nodes with hardware raids and want to configure the disks differently (RAID0 for every disk or RAID10 for all disks) depending on a tag.
<rock__> Hi. MAAS cloud juju bootstrap failed. Followed https://jujucharms.com/docs/2.0/clouds-maas I used MAAS 2.0 on Xenial(16.04). I am using all physical servers. I want to have [MAAS+Openstack base bundle] setup with our own bundle. But we are facing the issue while JUJU bootstrapping the MAAS cloud.
<rock__> Complete issue details: http://paste.openstack.org/show/582397/.  Please help me in resolving this.
<rock__> roaksoax: Can you please help me in this.
<kiko> lesseee
<kiko> NewJorg, it should be possible, yes. what does the machine query return to you?
<kiko> rock__, first, can you deploy Ubuntu manually to all of the nodes in your MAAS?
<rock__> kiko: Yes. I deployed and tried. working fine.
<baldpope> kiko, question on deploying ubuntu via maas - is it still iscsi root?
<baldpope> so I could use all local disks for something other than /
<rock__> kiko/roaksoax: So what I need to do here to resolve the issue. Am I need to change "curtin_userdata" script by putting some sleep before updating apt-get to reflect the change what we made through SSH into that bootstrapping node?
<kiko> roaksoax, hmm, what change you made through SSH?
<kiko> baldpope, it never was iscsi root, except for the ephemeral environment. does that make sense or should I explain?
<roaksoax> rock/win 4
<roaksoax> err
<roaksoax> rock__: as per kiko above, what change you made with SSH
<rock__> kiko: To avoid that Hash sum mismatch issue , http://paste.openstack.org/show/582398/
<rock__> roaksoax: I did the above change
<kiko> rock__, that change doesn't make sense to me
<kiko> rock__, why did you make it?
<baldpope> kiko, no, i got it - ty
<kiko> baldpope, HOWEVER, the caringo team has a set of patches proposed to us that allow you to do exactly that
<kiko> baldpope, i.e. deploy an OS that is a kernel and initrd only, and then use the local disks for object storage
<rock__> kiko/roaksoax:  why  i added info : http://paste.openstack.org/show/582400/.
<kiko> rock__, that error points to a wider problem
<kiko> rock__, is your local mirror not functioning properly?
<kiko> rock__, or do you have a proxy issue?
<NewJorg> kiko, what do you mean exactly with machine query?
<baldpope> kiko, please accept those changes ;)
<baldpope> that would be exactly what we'd want - use all the local disks for the object storage
<rock__> kiko/roaksoax: we got the same hash sum mismatch issue in our local systems , then we genarally used to add that. Local mirror working fine now.
<samek_> hi
<samek_> how can I debug adding a chassis ?
<samek_> we have a moonshot chassis and I want to add it
<samek_> All I get is Unable to find a rack controller with access to chassis X.X.X.X
<rock__> kiko/roaksoax: No . I don't have any proxy issue.
<rock__> kiko/roaksoax: I don't know what to do now. please tell me if you any ideas to resolve this issue.
<kiko> samek_, there is no rack controller that is active on that subnet
<kiko> rock__, your problem is not inside MAAS. it is outside MAAS.
<kiko> rock__, that apt-get update needs to pass without error. your network, proxy or mirror are broken.
<kiko> rock__, plug a laptop in. does the apt-get upgrade show the same error?
<samek_> kiko
<baldpope> rock__, did you define a proxy in maas?
<baldpope> if so, does your network allow the internal network to talk with the proxy?
<rock__> kiko:  sorry. Didn't get. Please tell me clearly.
<rock__> baldpope: Didn't define proxy.
<samba35> can some one please give me link to read how to /start using kind of stuff for maas ,i am on ubuntu 16.04.1 with maas 2
<baldpope> so in that case (I think - kiko, please chime in) the internal hosts are going to attempt direct network access - does the internal network have access to the public internet through your firewall?
<samek_> kiko It is accessible from the server where everything is on.
<rock__> baldpope: Yes.
<baldpope> hm
<baldpope> apologies - I didn't see the paste at openstack - network does not appear to be the issue, your getting out and package info back
<kiko> baldpope, it is either a network issue, or bad RAM/NIC
<kiko> rock__, can a laptop, plugged into the same network, using the same mirror, do an apt-get update successfully?
<baldpope> kiko, line 6/7 - wouldn't that imply a bad file received?
<rock__> kiko: $ sudo apt-get upgrade && sudo apt-get dist-upgrade  working fine.
<rock__> kiko: apt-get update also working fine.
<baldpope> rock__, but you need to prep by running update - that tells upgrade what to do
<baldpope> and based on your paste - update is failing
<rock__> kiko/baldpope: From MAAS conigured node , I am able to do apt-get update successfully.
<baldpope> i'm confused - where is apt-get update failing then?
<rock__> baldpope: On MAAS  slave nodes.
<baldpope> am I missing something or do your last 2 statements contradict each other?
<kiko> they do
<kiko> thanks baldpope :)
<rock__> koko/roaksoax/baldpope: when juju bootstrapping the MAAS cloud on one of MAAS Slave node I am getting apt-get issue.
<kiko> rock__, oh. you are saying that only during a juju bootstrap does the error happen
<kiko> hmmmmmm
<kiko> rock__, is the clock on these machines synchronized?
<rock__> kiko: please look at this once.  http://paste.openstack.org/show/582407/.
<rock__> kiko: I think machines are synchronized with the above result.
<rock__> Kiko/roaksoax: Exactly I found the issue. When we did juju bootstrap of MAAS cloud on one of MAAS slave node,
<rock__> kiko/roaksoax: I ssh into that bootstrapping node and run apt-get update . Then it was giving Hash sum mismatch issue. But after adding http://paste.openstack.org/show/582398/ in that maas slave node apt-get update going successfully.
<rock__> kiko/roaksoax: But While it was doing juju bootstrap, we added change is not reflecting immediately. Because curtin script is going very fast. without taking our changes it was giving issues.
<rock__> kiko/roaksoax: So can we modify curtin script to put delay before running apt-get update?
<rock__> kiko/roaksoax: Please tell me how to edit curtin script if we can.
<baldpope> rock__, why do you think you need to edit curtain?
<rock__> baldpope: whie running curtin script only right we got that issue.
<baldpope> but (as I understand it) curtain is just setting up your environment, and arguably you'd want to run an apt-get update as one of the first things, right?
<baldpope> so instead of skipping that step, lets figure out why it's failing
<rock__> baldpope: Just look at /etc/maas/preseeds/curtin_userdata
<rock__> baldpope: Curtin itself doing apt-get update . there it is failing
<rock__> baldpope: Curtin installation failed due to that apt-get update failure
<neith> anyone knows if I can deploy heat with autopilot or other penstac modules?
<neith> *Openstack
<rock__> kiko/roaksoax: Please give me the reply  .
<kiko> rock__, I have already told you what I can
<kiko> either it's bad at source (my #1 bet), goes bad over the wire, or goes bad upon reception.
<rock__> kiko: OK. Thank you for your support.
<rock__> roaksoax: How can I customize the curtin script?
<neith> kiko: Can I deploy the heat component with juju on an openstack autopilot deployment?
<rock__> roaksoax: cloud-init-output.log for my issue: http://paste.openstack.org/show/582417/. If you have any idea please help me.
<roaksoax> rock__: a problem with your mirror http://ubuntu.cs.utah.edu/ubuntu
<roaksoax> rock__: maybe your mirror has older packages than the ones in the Ubuntu image
<roaksoax> or similar
<lucas__> good day guys
<lucas__> anyone
<kiko> roaksoax, I've tried to tell rock__ that a few times, but was unable to communicate effectively :-/
<kiko> neith, you can't. I think we have juju charms for heat, though, and you can probably deploy manually -- it's not that much harder than using autopilot
<roaksoax> wom 12
<rock__> roaksoax: Thank you . Actually I tried with different mirrors . But I faced the same issue. OK. I will try to redeploy once again. Thanks .
<rock__> kiko:  No problem, You provide good info. Thank you.
<kiko> rock__, could your RAM or CPU or NIC be bad?
#maas 2016-09-22
<mup> Bug #1626334 opened: [2.0] Failures to release ESXi 6.0 VMs - Failed talking to node's BMC: <vCenter IP Address>:443 is not a VIM server <oil> <MAAS:New> <https://launchpad.net/bugs/1626334>
<jwitko> hey guys, I'm using maas 2.0 stable version (latest) and when issuesing GET /api/2.0/machines/{system_id}/ I am receiving different return types
<jwitko> sometimes I call it and receive a JSON return
<jwitko> and sometimes I receive a pickle file
<herb64> Hi all, having trouble with MAAS API in python script, MAAS version 2.0.0+bzr5189-0ubuntu1 / 16.04.1
<herb64> can do GET without problems, e.g. >> 'GET /machines/?mac_address=52:54:00:2e:77:93' returned status '200'
<herb64> And getting everything even with that filter fine
<herb64> But seems that I'm too dumb to get PUT working to change a hostname
<herb64> Docs say to use PUT /machines/<system_id>/
<herb64> And then parameters and values can be passed... But either I get errors, or Code 200 but my input is ignored
<herb64> Anybody who can provide a simple example on how to pass parameters correctly for the request?
<brendand> herb64, puts are a bit tricky, can i see your code?
<brendand> herb64, this is relevant to you: http://maas.ubuntu.com/docs/api.html?_ga=1.243576581.1468356320.1463157245#http-methods-and-parameter-passing
<herb64> I tried many combinations. some here
<herb64>     response = perform_API_request(MAAS_URL,                                    'PUT',                                    u'/machines/%s/?{"hostname": "%s"}' % (sysid, newname),                                    #'/machines/%s/?power_type=ipmi' % (sysid),                                    APIKEY)
<herb64> oops, not readable
<herb64> '/machines/%s/?{"hostname": "%s"}' % (sysid, newname)
<brendand> that won't work
<herb64> Tried many combinations, but nothing did work
<herb64> I checked that link already, but there's on syntax example.. I also did POST for commissioning successfully, it's just that PUT, I have problems with
<brendand> herb64, how did you do the post?
<herb64> The string for commissioning was 'POST','/machines/%s/?op=commission' % sysid,
<brendand> herb64, did you pass it any paramaters though?
<brendand> parameters
<brendand> that's the trick i think
<herb64> no, just as shown
<brendand> ah ok
<herb64> trying to change hostname again, now using simple string like this
<herb64> >> 'PUT /machines/4y3hby/?hostname=herbert' returned status '200'
<brendand> the documentation is not great unfortunately, it kind of assumes you have an in-depth knowledge of http apis
<herb64> Getting 200, but hostname part just ignored as it seems
<brendand> i am writing all my api code with pythons requests library, so i haven't tested this, but what should work is:
<herb64> Could not find any example string showing how to pass the parameters unfortunately
<brendand> params = {'param1': 'value1', ...}
<brendand> headers['Content-Type'] = 'multipart/form-data'
<brendand> http.request(uri=url, method='PUT', body=params, headers=headers)
<brendand> i.e. put the parameters in a dictionary and pass that in the 'body' argument
<brendand> and make sure to add 'Content-Type' = 'multipart/form-data' to the headers
<herb64> Ah, ok. I'll try to check that and the python requests library. Currently, I'm using the code as shown in https://maas.ubuntu.com/docs2.0/api_authentication.html
<herb64> Thanks, Brendan, for the hints, I'll go ahead with that
<brendand> i'll paste something using requests that i know for sure works
<brendand> http://paste.ubuntu.com/23215001/
<brendand> that's the same code i'm using so i'll be flabbergasted if it doesn't work :)
<brendand> except i forgot to import requests, so make sure to do that :)
<brendand> and oauth.oauth :P
<herb64> great, thanks for your help, I'll go for that
<herb64> Brendan, hostname change now works perfectly, thanks so much for your kind help
<brendand> herb64, delighted i could be of service :)
<mup> Bug #1626334 changed: [2.0] Failures to release ESXi 6.0 VMs - Failed talking to node's BMC: <vCenter IP Address>:443 is not a VIM server <oil> <MAAS:Invalid> <MAAS 2.0:Invalid> <MAAS trunk:Invalid> <https://launchpad.net/bugs/1626334>
<samba35> when i download any image from internet for maas  /pxe boot where that image is store on hardisk ?
<samba35> i am trying to configure 1st maas server on ubuntu 16.04.1 with  maas version 2
<samba35> where is maas logs are store ?
<brendand> samba35, /var/log/maas
<samba35> ok ,thanks
<samba35> can you please help me to understand maas boot ?
<brendand> samba35, if i can, sure
<samba35> this is my 1st maas server setup and i am trying to boot with pxe using kvm
<brendand> samba35, that's a common configuration :)
<brendand> samba35, so you installed maas on a kvm instance?
<samba35> i am getting noting to boot no such file or configuration
<brendand> samba35, probably you've missed some steps
<samba35> may be i am doing something wrong
<brendand> samba35, did you download the images and enable dhcp?
<samba35> i think i have download image as per gui
<samba35> can you please tell me how do i check that image is download and where it is store ?
<brendand> samba35, that's automatic so indeed it should be downloaded
<brendand> samba35, don't worry about that for now, if the ui is saying they are downloaded they probably are
<brendand> but you must enable dhcp
<samba35> yes dhcp is enable
<brendand> and is the node booting on the same subnet as the maas server?
<samba35> yes
<samba35> 192.168.50.129 is server which is client in a network but this is ubuntu server with maas
<brendand> samba35, in which network?
<samba35> when i start kvm pxe guest i am getting ip address but it say it could not get image or file
<brendand> is the maas installed also in a vm or on hardware?
<samba35> hardware
<samba35> please correct me i have installed ubuntu server and on top of ubuntu server i have install/configure maas is that correct ?
<brendand> roaksoax, should that configuration work? maas installed on the hw and vms pxe booting on the same hardware? usually i run my maas in another vm so as not to pollute my laptop
<brendand> so i haven't tried this way, at least in a while
<samba35> ok
<samba35> can i send you pm ?
<brendand> hold on
<samba35> brendand: do you have image store in it is /var/www/html/maas/images/ephemeral-v2/daily location ?
<roaksoax> brendand: i run MAAS on the hardware
<roaksoax> brendand: on a libvirt bridge
<roaksoax> brendand: maas being the gw for the machines
<roaksoax> brendand: libvirt configured NAT
<roaksoax> brendand: but disable dhcp on the libvirt network
<samba35> ok
<brendand> roaksoax, i guess that's it. i do have dhcp on my libvirt network, so i guess that only matters if you're running maas on the host
<roaksoax> brendand: even if you create MAAS on a VM, you still have to disable libvirt's DHCP
<roaksoax> brendand: to not badly interact with MAAS
<samba35> my ubuntu server is client on network , my ubuntu get ip address from dhcp server  still maas will work
<samba35> static ip assign to ubuntu
<brendand> samba35, i think that is fine
<samba35> ok ,thanks
<samba35> when gui say it has download images but i could not see any image on actual location you mention ,in that case what mistake i must be doing ?
<rock___> KIKO/ROAKSOAX:  Finally, I did juju bootstrap of MAAS cloud on one of MAAS node successfully. ubuntu mirror issue gone. Thank you guys.
<rock___> kiko/roaksoax: When I was doing MAAS on KVM machines, I used maas 2.0 and then also MAAS not able to detect harddisks of KVM virtual machines. I have taken KVM VMs disk type as VirtIO.
<kiko> rock___, what was the issue?
<rock___> kiko: xenial repo issue. we tried again and again .It worked.
<kiko> rock___, broken mirror
<rock___> kiko: Yes
<kiko> woot!
 * kiko high 5s baldpope
<samba35> images are downloaded but still same error
<samba35> i am using openvswitch is that a problem ?
<kiko> samba35, I'm lacking some context. what are you doing?
<samba35> i am trying to boot from pxe with kvm
<samba35> virt-manger using
<samba35> can you please tell me which type of network i have to select ?
<samba35> my ubuntu is 16.04.1 ,using maas version 2 (default come with apt)
<neith> kiko: the openstack-installer un multi mode is not subject to license , right?
<neith> kiko: does it provides a ceph installer?
<kiko> neith, yes, it installs our standard openstack
<kiko> neith, so conjure-up just drives charms, no licensing
<kiko> neith, openstack-install a) should not be used and b) deploys landscape, which comes with a free 10-node license
<kiko> our standard openstack includes ceph ftr
<neith> kiko: really? conjure-up is free and comes with ceph?
<kiko> neith, yes
<neith> kiko: great
<kiko> https://github.com/conjure-up/conjure-up/blob/master/LICENSE
<kiko> https://github.com/conjure-up/conjure-up/blob/6e43be2a2bb2b66bc74051fe20f5fb8204b865e7/docs/wireframes.txt
<kiko> neith, ^^
<kiko> if you need help just ask mmcc and stokachu
<neith> kiko: i'll try tomorrow, whats your timezone?
<kiko> neith, I'm in brazil so anything non-asia is fine
<roaksoax> /win/win 6
<neith> kiko: does Maas is required?
<neith> kiko: prefered?
<neith> with conjure up
<kiko> neith, well.. what are you deploying onto? if it's hardware, MAAS is required
<samba35> "network selection does not support pxe" how do i fix it ? i am getting this message with virt-manger while create pxe boot guest
<smgoller> Is there anything that integrates something like ansible with maas? l
<smgoller> or is this a scenario where i'm writing a script that interacts with maas to provision machines, then runs ansible to set them up?
<neith> kiko: bare metal yes
<kiko> neith, then you want MAAS for sure, and luckily you're in the right place
<kiko> smgoller, yes, there's something called maansible
<smgoller> kiko: haha, awesome :)
<kiko> smgoller, I have never used it, it was built by a team in the philippines so YMMV but it's at least something to look at
<smgoller> kiko, thanks!
<kiko> it's a great name
<neith> Maasible only seems to be a dynamic inventory tool for ansible
<kiko> ah
<neith> I'm sure I can hook ansible as a provisioner once a node is bootstrapped by maaq
<neith> Maas
<kiko> yes, that's easy
<lucio_> hi there, need help troubleshooting maas 2.0, nodes are failing to commission
<kiko> lucio_, okay, enable the "keep node running" checkbox and check /var/log for fun entries
<lucio_> hi kiko thanks, where can i find this keep node running checkbox?
<kiko> lucio_, when you click on "commission" on the UI?
<lucio_> you mean "Allow SSH access and prevent machine from powering off"
<lucio_> ?
<kiko> lucio_, yep
<lucio_> ok thank you it is running, how do I ssh into the node?
<kiko> lucio_, umm. I don't know how to answer that question :)
<kiko> you ssh into the node? :)
<lucio_> to ssh I would need a key and and ip address...
<brendand> lucio_, the ip address is on the node details page
<lucio_> ok
<lucio_> Hi Kiko, I think it is not booting up, I do not see any ip address in the node details, DHCP has not assigned one
<kiko> lucio_, see the console
<lucio_> server is far away, I do not have a way to see the console of the node, is it possible to see the console in the maas ui ?
<lucio_> in the log it says: powering on ...
<mup> Bug #1626654 opened: [2.0]  'Failed deployment: bootx64.efi' - rackd â Missing connections to 1 region controller(s). <oil> <MAAS:New> <https://launchpad.net/bugs/1626654>
<lucio_> the bug says only EFI nodes affected, mine have the BIOS in legacy mode, so this bug would not be the reason, I think
<lucio_> hi Kiko, ok so the node has failed to commission again, it does not have an ip address assigned, power is on, but it did not get the hardware details from the node
<kiko> lucio_, no PXE boot
<lucio_> how can I check if DHCP is working ok?
<lucio_> in the ui I see dhcpd is running under controller services
<lucio_> green checkbox on dhcpd
<lucio_> images are downloaded
<mup> Bug #1626669 opened: [2.1] Can't logout, create users and do other actions <MAAS:Triaged> <https://launchpad.net/bugs/1626669>
<lucio_> thanks for the suggestions, will come back later
<mup> Bug #1626680 opened: MAAS forces IPv6 address <canonical-is> <MAAS:New> <https://launchpad.net/bugs/1626680>
<mup> Bug #1581730 changed: [2.0b5] Commissioning / enlistment templates in /etc/maas/templates <MAAS:Fix Released> <https://launchpad.net/bugs/1581730>
<mup> Bug #1593856 changed: Need a way to surface a name for an api-key in logs <oil> <MAAS:Triaged> <https://launchpad.net/bugs/1593856>
<mup> Bug #1593856 opened: Need a way to surface a name for an api-key in logs <oil> <MAAS:Triaged> <https://launchpad.net/bugs/1593856>
<mup> Bug #1593856 changed: Need a way to surface a name for an api-key in logs <oil> <MAAS:Triaged> <https://launchpad.net/bugs/1593856>
<jwitko> hey guys, I'm using maas 2.0 stable version (latest) and when issuesing GET /api/2.0/machines/{system_id}/ I am receiving different return types at what seems to be random.  Most of the times its JSON but sometimes this returns a pickle file
<jwitko> It's the same exact API call, but it doesn't always return the same format of response
<kiko> jwitko, sounds like a bug
<mup> Bug #1626722 opened: DHPv6 addresses do not have netmasks: do not create /128 subnets for them <maas-ipv6> <MAAS:New> <https://launchpad.net/bugs/1626722>
<mup> Bug #1626727 opened: [2.1] You can define distribution or component for 'ubuntu archive' or 'ubuntu extra architectures' <MAAS:New> <https://launchpad.net/bugs/1626727>
<kiko> roaksoax, have we heard of this?
<kiko> jwitko, could we get a bug on https://launchpad.net/maas/+filebug
<roaksoax> jwitko: it should always return json
<roaksoax> jwitko: but if it returns pickle, yeah that's a bug
<roaksoax> jwitko: it may not always be sorted the same though
<jwitko> I'm creating a bug now
<jwitko> here is an example I just got
<jwitko> http://paste.ubuntu.com/23217500/plain/
<jwitko> that was the return from a GET to http://maas1.lab/MAAS/api/2.0/machines/4y3h7q/
<jwitko> hm, i am seeing errors in the MaaS logs... maybe this is something on my end
<roaksoax> jwitko: yeah that might as well be the case
<mup> Bug #1626734 opened: identical API calls returning different formatted responses <MAAS:New> <https://launchpad.net/bugs/1626734>
<jwitko> flushed the logs, going to see the errrors that happen now
<roaksoax> jwitko: blake resinded to your bug
<jwitko> roaksoax, so the request, when it returns a pickle object, is also returning "No JSON object could be decoded"
<mup> Bug #1626734 changed: identical API calls returning different formatted responses <MAAS:New> <https://launchpad.net/bugs/1626734>
<jwitko> ugh, nevermind the above, thats formatting
<jwitko> in my python script
<mup> Bug #1626734 opened: identical API calls returning different formatted responses <MAAS:New> <https://launchpad.net/bugs/1626734>
<mup> Bug #1626734 changed: identical API calls returning different formatted responses <MAAS:New> <https://launchpad.net/bugs/1626734>
<mup> Bug #1626748 opened: [2.1] maas admin discoveries scan API output shows rack controller ids instead of names <MAAS:New> <https://launchpad.net/bugs/1626748>
#maas 2016-09-23
<neith> on the http://conjure-up.io/ page, the is a typo: it's apt-get install not apt install ;)
<mup> Bug #1626942 opened: dhcpd.conf is not regenerated when ntp_external_only is modified <dhcp> <ntp> <MAAS:Triaged> <https://launchpad.net/bugs/1626942>
<Guest12953> what is the easiest way to force ubuntu 14.04.4 instead of the latest 14.04.5? Should I use a custom image for this as from the native image selection you can only select upto 14.04 LTS?
<neith> kiko how long is conjure-up with opentack maas deployment?
<stokachu> neith: it's apt install conjure-up for xenial
<neith> stokachu: I guess I autocorrected myself
<stokachu> you can still use apt-get but we prefer the shorter command
<neith> I understand
<neith> kiko, the installation is launched for more than an hour and a half and components are still in allocating state
<neith> I can't find the lofs
<neith> logs
<neith> and can't connect by ssh to nodes to check whats going on
<mup> Bug #1627016 changed: [2.1, rev5385] MAAS reports there are missing rack connections but no error logs <MAAS:New> <https://launchpad.net/bugs/1627016>
<mup> Bug #1627016 opened: [2.1] MAAS reports there are missing rack connections but no error logs <MAAS:New> <https://launchpad.net/bugs/1627016>
<mup> Bug #1627019 opened: [2.1, rev5385] NTP services on region/rack keep showing as ON/OFF constantly <MAAS:New> <https://launchpad.net/bugs/1627019>
<mup> Bug #1627038 opened: [2.1] SSH key import should use the specified HTTP proxy if one exists <MAAS:Triaged> <https://launchpad.net/bugs/1627038>
<mup> Bug #1627038 changed: [2.1] SSH key import should use the specified HTTP proxy if one exists <MAAS:Triaged> <https://launchpad.net/bugs/1627038>
<baldpope> good morning all - i see rock fixed/identified his issue - bad mirror - no cookie
<mup> Bug #1627038 opened: [2.1] SSH key import should use the specified HTTP proxy if one exists <MAAS:Triaged> <https://launchpad.net/bugs/1627038>
<mup> Bug #1627039 opened: [2.1] Discovery object and view doesn't set a flag when the device is the router <MAAS:Triaged> <https://launchpad.net/bugs/1627039>
<samba35> Thanks
<samba35> i was able to boot from maas 1st server client from pxe but i have many quastion lead by 1st pxe client boot with dedicated  machine (not kvm/pxe boot )
<samba35> how to ram is require to client machine ? ,i am boot with pxe ubuntu 16.04.1
<roaksoax> samba35: to be safe, I'd say at least 2GB rma
<samba35> ok ,Thanks
<samba35> roaksoax: i was able to boot pxe boot with maas but i am not able to boot with pxe /kvm i try bridge also
<samba35> what is default username and password for  maas client
<samba35> but thanks something move forward
<shubjero> samba35: a system deployed by maas? shouldnt be any l/p.. just your ssh key that gets injected
<samba35> sorry  ,
<samba35> do i have to create ssh key with keygen  ? or ?
<shubjero> Is it possible to create a common 'storage disk layout' template? I have two common sets of servers that have their disks partitioned up a certain way. How can I template this?
<roaksoax> samba35: http://maas.io/docs/manage-account#ssh-keys
<samba35> i am behind firewall ,is maas  deployment require which ports open ?
<samba35> ok i will br right back
<samba35> problem is i don't have  two monitors ,beg friends old system with 512mb ram (just cpu w/o monitor )
<samba35> i was getting blk_update_request:i/o error ,dev fd0 ,sector 0 is it because of firewall ?
<samba35> thats why i ask is maas depolyment use any ports ,so i can open those ports
<kiko> samba35, fd0?
<kiko> samba35, what version of MAAS is that?
<kiko> samba35, you will need to disable the floppy in the BIOS
<samba35> MAAS Version 2.0.0+bzr5189-0ubuntu1 (16.04.1)
<kiko> blake_r, didn't we fix that bug?
<kiko> anyway
<kiko> samba35, you have the floppy enabled in your BIOS but no physical floppy
<samba35> kiko: i think u rocks
<kiko> ah, I wish I did
<kiko> roaksoax, ^^
<samba35> as i told i have only 1 monitor system was giveing error thats why i disable all diskdrive and after that system boot quick but did not notice it was  floppy disk drive
<samba35> sorry but i had /have some stupid and basic quastion still i will go it with
<samba35> when  i boot my 1st client it start showing machine 1 at the same time there is options to add hardware and machine
<samba35> why they are there ?
<samba35> it  may sound stupid to you but for me its big task :)
<blake_r> kiko: we should ignore those device we fixed that bug
<samba35> what is device is ?
<samba35> that is 0 (zero )
<roaksoax> kiko: yes, but I dont think MAAS can deploy on a 512mb machine
<roaksoax> kiko: 512RAM
<roaksoax> the ephemeral environment needs more memory due to the dependencies installed in it
<kiko> blake_r, looks like the bug isn't fixed :-(
<blake_r> kiko: it might have came back but I know at a point it was fixed
<kiko> baldpope, btw I fixed the blog post that you tried to follow and had a snag. it was the use of literal "<" and ">" in the text :-)
<samba35> can u please tell url of blog ?
<kiko> http://insights.ubuntu.com/2016/01/23/maas-setup-deploying-openstack-on-maas-1-9-with-
<samba35> Thanks
<samba35> 404: page not found
<samba35> http://insights.ubuntu.com/author/kiko/
<samba35> thanks
<kiko> hmm
<kiko> http://insights.ubuntu.com/2016/01/23/maas-setup-deploying-openstack-on-maas-1-9-with-juju/
<kiko> sorry
<kiko> c-n-p snag
<samba35> ok,thanks
<shubjero> Is it possible to create a common 'storage disk layout' template? I have two common sets of servers that have their disks partitioned up a certain way. How can I template this?
<shubjero> For example, id like to be able to easily deploy servers that have 6 HDD's with a specific partition layout, and then deploy servers that have 2 HDD's with a different layout
<shubjero> is that something that can be done with maas?
<shubjero> I know I can configure the partition layouts for each individual node
<jwitko> Does the MaaS built-in proxy also do a cache?
<jwitko> like apt-cache
<kiko> jwitko, yes, it does
<jwitko> thanks kiko
<kiko> jwitko, it's explicitly configured to also cache debs
<kiko> shubjero, not at the moment, it is planned for 2.2. however, you can do it externally via the API
<samba35> Thanks ,bye its 12:30 am
<mup> Bug #1627160 opened: With external DHCP, MAAS may guess IPv6 subnet prefix lengths. <MAAS:New> <https://launchpad.net/bugs/1627160>
<shubjero> kiko: ok thanks!
<kkkkk> do you have any instruction for 16.04 kilo ?
#maas 2016-09-24
<spaok> does anyone know if there's a way you can juju bootstrap against a device in maas/juju 2.0?
<mup> Bug #1627160 changed: With external DHCP, MAAS may guess IPv6 subnet prefix lengths. <MAAS:Opinion> <https://launchpad.net/bugs/1627160>
<samba35> i add machine manully to maas server but it say   	"Commissioning" how long this process take ?
<samba35> i have added ssh key to client still it was asking for username and passwd ,username  and passwd i provided it say incorrect
<samba35> before adding machine maually ,maas server auto configure "new " system but i fail to understand how to make it ready ?
<samba35> sorry ,this is my 1st maas server deployment
<samba35> now client system has 2 gb ram
<samba35> :)
<samba35> :)
<samba35> ready
<samba35> no idea how it get deployed
<samba35> now its ready ,
<samba35> Storage :>>>
<samba35>     No storage information. Commissioning this node will gather the storage information.
<samba35>     Specify a storage device to be able to deploy this node.
<samba35>     Mount the root '/' filesystem to be able to deploy this node.
<samba35> do i have to wait till image is been download or do ihave to create storage to image to download ?
<samba35> in setting >>storage its FLAT LAYOUT
<samba35> when i try to depoly machine i am getting this message what it mean ?
<samba35> The deploy action for 1 node failed with error: {"storage": ["Specify a storage device to be able to deploy this node.", "Mount the root '/' filesystem to be able to deploy this node."]}
<samba35> can some one please help me to understand storage  layout on maas server ? ,which storage type i select (presently its flat )
<samba35> doesn it require new harddisk ? i have install maas server after installation of normal ubuntu 16.04.1 is that ok  ? or do i have to install new new maas server with maas option
<mup> Bug #1627362 changed: [2.1] expected string or bytes-like object <MAAS:New> <https://launchpad.net/bugs/1627362>
<mup> Bug #1627363 changed: [2.1] 'NoneType' object has no attribute 'external_dhcp' <MAAS:New> <https://launchpad.net/bugs/1627363>
<mup> Bug #1627362 opened: [2.1] expected string or bytes-like object <MAAS:New> <https://launchpad.net/bugs/1627362>
<mup> Bug #1627363 opened: [2.1] 'NoneType' object has no attribute 'external_dhcp' <MAAS:New> <https://launchpad.net/bugs/1627363>
<reptile> roaksoax: I thought the magic is by providing ssh access to provision new servers - in diffrent physical places
<roaksoax> reptile: no, that's Juju, but juju doesn't provision a machine, it orchestrates a service
<MrDan> hello
<MrDan> i have an issue with the pyvmomi certificates when I try to add VMware machines to MAAS 2
<MrDan> if i do an apt list i have pyvmomi 5.5
<MrDan> if I install latest pyvmomi via pip i get the 6.0 one
<MrDan> question us how do I make the pip one active?
<MrDan> if I try to apt remove pyvmomi, it remvoes all maas packages also
#maas 2016-09-25
<rockey> good evening lads.. i have some sort of situation with maas 2.0 on ubuntu xenial lts.. system drives is arranged in different orders, even on the same models with the same bios configurations
<rockey> when trying to boot after deployment is "almost finished, just the last bit left", i get [warn] no mbr magic shittyness, which right now drives me crazy
<rockey> i specify in maas that device with X size should be sda and should contain this specified partition setup, next device should be left alone without any partitions at all
<rockey> this is some sort of 50/50 scenario right now on about 10 hosts in my lab environment
<rockey> anyone had this problem before?
<mup> Bug #1627419 opened: [ipv6] ephemeral kernel fails to shutdown <MAAS:New> <https://launchpad.net/bugs/1627419>
<samba35> do i require local hardisk on client system for maas client deployment ?
<spaok> my guess is yes
<spaok> I think you need a root disk defined to deploy
<samba35> thanks ,
<spaok> rockey: what type of severs?
<spaok> servers even
<samba35> can i use sd card ?
<spaok> should, mine show up as disks
<spaok> can even software raid them
<samba35> if local hardisk is require then what is purpose of maas server ? just deploy installation ?
<spaok> maas is a provisioner
<spaok> like cobbler
<samba35> i am as a blind person judge elephant
<spaok> what are you trying to do?
<samba35> trying to deploy server with may be wtong idea that my diskless machine will act as a server ,and i can acess same server in cloud
<samba35> be wrong idea ....
<samba35> did u deploy maas server ?
<spaok> ya
<spaok> but maas is a tool
<samba35> with local harddisk
<spaok> ya, I run MAAS 1.9.3 in a KVM instance and the new MAAS 2.0 in a LXD container
<samba35> ok
<spaok> it's basically a PXE server
<spaok> you can do some fun things with it, but to me, at its core is a PXE server
<samba35> cool
<samba35> i am also trying same
<spaok> we use it to boot racks of servers, deploy the OS and trigger a puppet run
<samba35> what hardware is require /do u have
<spaok> you can probably run it on a raspberry pi if you wanted, but we use Dell R630's right now
<samba35> for maas ,lxd and juju 4 ram is ok ?
<spaok> well, are you doing multiple servers? or one?
<samba35> one
<spaok> if you use one server you can just use juju and the local provider for LXD
<spaok> no maas needed
<samba35> ic
<spaok> then juju will create containers
<samba35> ok
<spaok> see https://www.stgraber.org/2016/06/06/lxd-2-0-lxd-and-juju-1012/
<spaok> bootstrap against localhost will be juju lxd
<spaok> maas is more for when you have pools of servers you want to deploy apps to, it's possible to run everything on one server but it's a little tricky
<samba35> is it u r blog ?
<spaok> nope, just something I had open when I was testing stuff
<samba35> ok
<spaok> i'm trying the new 2.0 features
<samba35> for lxd it require its own bridge /interface ?
<spaok> ya
<samba35> like docker ?
<spaok> it will auto create it
<spaok> ya , basically the same concepts
<samba35> ok
<spaok> there's differences between docker and lxd, but networking wise out of the box they are basically the same
<samba35> brb
<samba35> sorry
<ComputerAdam-noo> hi
<ComputerAdam-noo> my rack controller had no dhcpd check mark, is that why im not getting my server to boot from pxe?
<ComputerAdam-noo>   dhcpd    dhcpd6
<spaok> ya probably
<spaok> go to networks
<spaok> click on the untagged vlan
<spaok> then take action -> enable dhcp
<spaok> took me a bit to figure that one also
<ComputerAdam-noo> thanks! should I turn off DHCP on my router?
<ComputerAdam-noo> first?
<spaok> probably a good idea
<spaok> think you can tell maas to use an external DHCP, but haven't tried it
<ComputerAdam-noo> yup so dhcp didnt turn on bacause of routers dhcp.. im just configuring this at home.
<spaok> it should turn on no matter what, just questionable about which DHCP would see the requests first
 * spaok would think
<ComputerAdam-noo> since I have an airport extreme and there is no way to turn off dhcp, i just turned it on the MAAS server and got my vmachine to boot w pxe
<spaok> if they bridged on the same machine then ya it should work ok
<samba35> can i use usb pendrive as a hardisk ? to deploy maas client ?
<spaok> if you mean a client that PXE boots against MAAS and uses USB pendrive it should
<samba35> for local storage /alternative to harddisk
<mup> Bug #1627441 opened: MAAS 2.0 - CentOS 7 deployment failed <MAAS:New> <https://launchpad.net/bugs/1627441>
<rockey> spaok: i found a solution, some fucker at the hardware place didnt follow instructions of puting right disk in the right place
<rockey> spaok: so sda was different due to motherboard hdd slot order
<echeadle> I just installed maas and I am trying to get things to work.  I wanted to turn on dhcp from the command line. I log into the node fine but when I try to use the maas $PROFILE node-groups command it tells me there is no command. What am i doing wrong?  I am reading from the 2.0 version of documentation.
 * D4RKS1D3 Hi
#maas 2017-09-18
<oyrogerg> Hi, is anyone around?
<oyrogerg> Just in case: I would like to have our maas-dhcp server listen on four interfaces.
<oyrogerg> I can make it briefly do that by adding them to /var/lib/maas/dhcpd-interfaces, but it quickly gets reverted
<oyrogerg> A dirty solution is to chattr +i /var/lib/maas/dhcpd-interfaces (!) so that /usr/lib/maas/maas-write-file fails to revert it, but I'd like to do it more cleanly if possible.
<oyrogerg> I put the question here https://askubuntu.com/questions/956892/how-do-i-get-maas-dhcp-to-listen-on-multiple-interfaces
<c06_> hi all
<c06_> anyone on?
<c06_> facing "Marking node failed: Power on for the node failed: Could not contact node's BMC: Connection timed out while performing power action.  Check BMC configuration and connectivity and try again."
<c06_> any suggestions?
<mwe1> c06: which BMC type?
<c06_> mwe1: ipmi
<mwe1> which hardware vendor?
<c06_> hp
<mwe1> have you checked the BMC variables (Nodes -> <select Node> -> Power?
<mwe1> is there any configurattion (IP address, etc.)?
<c06_> actually my machine got list as NEW state, and while doing commissioning getting the error
<mwe1> maas should detect the ipmi configuration during the commissioning task. Is IPMI already configured and accessibbe from the maas server?
<mwe1> AFAIK mass doesn't configure IPMI except adding a user (and activate IPMI over LAN)
<c06_> mwe1: we configured our maas server with nodes. unfortunately we lost the connectivity between maas and nodes. after that we are facing this issue
<c06_> mwe1: we removed the existing machine from maas and we restarted the nodes with PXE and the machine got into NEW state; while trying commission-> we are getting the above error
<mwe1> That means the machine is able to PxE-Boot via maas. After detecting (State 'NEW') the machine is automatically powered off by the PxE-bootet image. until now it seems to be fine. but...
<mwe1> Now MaaS has to start the machine to start the commission task. Because of not working IPMI MaaS isn't able to bootup the machine
<mwe1> look at the 'Power' configuration at the machine. Is everyting OK?
<c06_> mwe1: yes one sec i share whole logs may be that ll be help
<mwe1> If yes try to connect to the IPMI interface from the MaaS server. Is that working?
<mwe1> If Yes, look at the users-page of the IPMI-Interface. is there a user called 'maas'?
<c06_> give me a sec; i am checking...  error logs https://paste.linux.community/view/95553113
<mwe1> The logs of the commissioning-task would be great.
<c06_> mwe1: i think tat is the above log
<mwe1> --> Failed to change the boot order to PXE 10.3.18.26: /usr/sbin/ipmi-config: connection timeout
<mwe1> is the IP accessible from within the maas server?
<c06_> i am trying to 10.3.18.26. but its not accessable. any other command to check connectivity
<c06_> mwe1: becoz those IP are listing in MAAS dashbaord. !!!
<mwe1> als always: the network guys are resposible for your pain :D
<c06_> mwe1: oops morning its working fine. i will check with network people.. :(
<mwe1> what's the output of 'ping 10.3.18.26' (from within your maas server)
<c06_> mwe1: one sec 10.3.18.26 , 10.3.18.xx ip's are listing in subnet tab in MAAS dashboard
<mwe1> Do you have an ssh shell to your maas server?
<c06_> yes i have ping not working 100% packet loss
<mwe1> (at this point forget your dashboard ;-) )
<mwe1> ip route ?
<mwe1> (is there a default GW)
<c06_> mwe1:  its pinging;  deault gw changed and its in dummy interface. now i changed to my network and its pinging
<mwe1> cool! try to commision your machine, again
<c06_> ok ty i am trying and i ll ping once i got the result.. ty dude.. :)
<mwe1> GW to dummy interface looks funny.
<mwe1> You're welcome
<c06_> mwe1: we are first time trying MAAS so only..
<Guest14056> #roaksoax
<Guest14056> @roaksoax: Last week I was checking with you on uploading custom images in MAAS. You mentioned that currently MAAS does not support it, but there could be a workaround by modifying index.json
<Guest14056> I looked at the file and it is GPG encrypted
<Guest14056> any idea if I need to go non-secure way then you will I need to modify things?
<v92> hi, do you have any idea what issue can be when I have two A records for host but only one is valid ?
<v92> zone.maas:exp-imf-a-7 30 IN A 192.168.0.153
<v92> zone.maas:exp-imf-a-7 30 IN A 192.168.0.165
<v92> 192.168.0.165 is not allocated to host exp-imf-a-7
<v92> only 0.153
<mwe1> c06_: did it work?
<c06_> mwe1: Node failed to be commissioned, because of the following error: No rack controllers can access the BMC of node: maas
<c06_> i am searching in online so i forgot to ping
<c06_> mwe1: i configured dpkg-reconfigure maas-region-controller and maas-rack-controller to my maas node ip but still same error
<mwe1> but pinging from maas server (ssh) to the BMC is still working?  'ping 10.3.18.26'
<mwe1> maybe network-manager has reconfigured your gateway.
<c06_> yes ping is working to gateway.
<c06_> i think nodes are in shutdown state so ping to that particular node not working
<mwe1> ping to BMC should work in shutdown state also :D
<mwe1> that's the funktion of BMCs ;-)
<c06_> mwe1: serious oops its not working..
<c06_> mwe1: i think as you told previously some admin people maybe played with network.. :(
<mwe1> as always: It's a network related issue :-)
<c06_> ok mwe1 ty for your suggestion i ll check with admin team :-D
<mwe1> It might be possible that your maas-server is changing the gateway entries from time to time.
<c06_> mwe1: my maas-server i didnt configure related to 10.3.18.x ip
<mwe1> So when you change it manually it will be reconfigured after a short timeperiod.
<c06_> **under subnet tab
<mwe1> Isn't it your default gateway that is changed?
<c06_> yes i changed in my maas machine after from maas server able to ping gateway(BMC-ipmi)
<mwe1> try setting your default gateway manually, again and test the ping.
<mwe1> if it works the commissioning should work also.
<c06_> i think in maas server some network configuration changes
<c06_> **changed.. from other machine able to ping to BMC(10.3.18.x).. oops i got into mess i think
<mwe1> what's the output of 'ip route'
<mwe1> (at the maas server)
<c06_> mwe1: https://paste.linux.community/view/12fcd22c
<mwe1> whith this configuration your BMC is pingable?
<c06_> its pinging to gateway but not going to other BMC
<mwe1> are you able to login to your gateway?
<c06_> am not having credential for that gateway
<mwe1> Than you have to contact your network-admins, I think :-(
<c06_> ok i think so i will try
<mwe1> forwarding from 192.168.0.0/24 to 10.3.18.0/24 via 192.168.0.254 has to work in order to install your maas setup.
<mwe1> that's your missing point, I think.
<mwe1> good luck
<mwe1> I have to leave for today.
<c06_> thanks four time and suggestion
<mwe1> You're welcome.
<c06_> thanks dude.. if possible tomorrow i ll ping
<c06_> have a nice day.. :)
<mwe1> cu
<c06_> :)
<mup> Bug # changed: 1532047, 1621175, 1642298, 1676992, 1681801, 1684094, 1686246, 1688066, 1702703, 1703035, 1707850, 1708512, 1711414, 1711700, 1711714, 1712422, 1712423, 1712450, 1714273, 1715634
<mup> Bug #1717669 changed: Ephemeral boot has broken DNS <MAAS:New> <https://launchpad.net/bugs/1717669>
<mup> Bug #1689557 changed: replace iscsi usage in ephemeral image with rooturl <MAAS:Fix Released by ltrager> <maas-images:Fix Released by ltrager> <https://launchpad.net/bugs/1689557>
<mup> Bug #1717983 opened: replacement of isc-dhcp-client with with systemd-networkd for dhclient needs integration <amd64> <apparmor> <apport-bug> <artful> <avahi (Ubuntu):New> <cloud-init (Ubuntu):New> <controlaula (Ubuntu):New> <ddclient (Ubuntu):New> <dracut (Ubuntu):New> <ifupdown (Ubuntu):New>
<mup> <ifupdown2 (Ubuntu):New> <initramfs-tools (Ubuntu):New> <isc-dhcp (Ubuntu):New> <libguestfs (Ubuntu):New> <maas (Ubuntu):New> <madwimax (Ubuntu):New> <netscript-2.4 (Ubuntu):New> <network-manager (Ubuntu):New> <ntp (Ubuntu):New> <openresolv (Ubuntu):New> <resolvconf (Ubuntu):New> <samba
<mup> (Ubuntu):New> <sendmail (Ubuntu):New> <ubuntu-meta (Ubuntu):New> <walinuxagent (Ubuntu):New> <whereami (Ubuntu):New> <wicd (Ubuntu):New> <wifi-radar (Ubuntu):New> <https://launchpad.net/bugs/1717983>
<mup> Bug #1717612 changed: MAAS uses region IP address for default DNS server, but DNS is provided by rack controllers <cdo-qa> <cdo-qa-blocker> <foundations-engine> <MAAS:Invalid> <https://launchpad.net/bugs/1717612>
<mup> Bug #1718016 opened: MAAS failed to respond to POST'd deploy request but still deployed node <cdo-qa> <cdo-qa-blocker> <MAAS:New> <https://launchpad.net/bugs/1718016>
<mup> Bug #1718016 changed: MAAS failed to respond to POST'd deploy request but still deployed node <cdo-qa> <cdo-qa-blocker> <MAAS:New> <https://launchpad.net/bugs/1718016>
<mup> Bug #1718016 opened: MAAS failed to respond to POST'd deploy request but still deployed node <cdo-qa> <cdo-qa-blocker> <MAAS:New> <https://launchpad.net/bugs/1718016>
<mup> Bug #1718039 opened: regiond logs errors when rackd not installed <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1718039>
<mup> Bug #1718039 changed: regiond logs errors when rackd not installed <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1718039>
<mup> Bug #1718039 opened: regiond logs errors when rackd not installed <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1718039>
<mup> Bug #1718039 changed: regiond logs errors when rackd not installed <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1718039>
<mup> Bug #1718044 opened: [2.2] Failed to process node status messages - twisted.internet.defer.QueueOverflow <MAAS:New> <https://launchpad.net/bugs/1718044>
<mup> Bug #1718046 opened: [2.2, HA] could not serialize access due to concurrent update <MAAS:New> <MAAS 2.2:New> <https://launchpad.net/bugs/1718046>
<mup> Bug #1718048 opened: [2.3] Traceback when no available machine matches constraints <MAAS:Triaged> <https://launchpad.net/bugs/1718048>
<mup> Bug #1718048 changed: [2.3] Traceback when no available machine matches constraints <cdo-qa> <foundations-engine> <MAAS:Invalid> <https://launchpad.net/bugs/1718048>
#maas 2017-09-19
<mup> Bug #1705152 changed: Getting mDNS observation process failed error in regiond.log and commisioning not completing indefinitely <MAAS:Expired> <https://launchpad.net/bugs/1705152>
<mup> Bug #1705152 opened: Getting mDNS observation process failed error in regiond.log and commisioning not completing indefinitely <MAAS:Expired> <https://launchpad.net/bugs/1705152>
<mup> Bug #1705152 changed: Getting mDNS observation process failed error in regiond.log and commisioning not completing indefinitely <MAAS:Expired> <https://launchpad.net/bugs/1705152>
<mup> Bug #1718122 opened: [2.3.0~alpha3] Lingering beacon-monitor/observe-beacons processes after stopping rackd/regiond <MAAS:New> <https://launchpad.net/bugs/1718122>
<mup> Bug #1718122 changed: [2.3.0~alpha3] Lingering beacon-monitor/observe-beacons processes after stopping rackd/regiond <MAAS:New> <https://launchpad.net/bugs/1718122>
<mup> Bug #1718122 opened: [2.3.0~alpha3] Lingering beacon-monitor/observe-beacons processes after stopping rackd/regiond <MAAS:New> <https://launchpad.net/bugs/1718122>
<Guest52914> @roaksoax
<Guest52914> #roaksoax
<BlackDex> Hello there, is it possible for maas to use a local hosted mirror for packages? So, say that i want to use maas and install an ubuntu 16.04 instance, but i don't have internet access. Could i use a local mirror running on my laptop or something instead of the default repo?
<BlackDex> I need to provide the ubuntu image via a custom source also in that case :)
<BlackDex> But my main consern are the packages which need to be installed and updated during the maas provisioning
<roaksoax> BlackDex: that's a fairly common scenario
<roaksoax> BlackDex: in the settings page there's a 'package repositories' tab
<roaksoax> where you can change your mirrors
<roaksoax> to use your custom ones
<mup> Bug #1718209 opened: PXE configuration for dhcpv6 is wrong <MAAS:New> <https://launchpad.net/bugs/1718209>
<mup> Bug #1705594 opened: [2.2] rackd errors after fresh install <cdo-qa> <cdo-qa-blocker> <MAAS:New> <https://launchpad.net/bugs/1705594>
<mup> Bug #1718270 opened: [2.3] MAAS improperly determines the version of rack-controller-only installs <MAAS:Triaged by mpontillo> <https://launchpad.net/bugs/1718270>
<mup> Bug #1718294 opened: [packaging] dpkg-reconfigure for region controller refers to an incorrect network topology assumption <MAAS:New> <https://launchpad.net/bugs/1718294>
<mup> Bug #1718294 changed: [packaging] dpkg-reconfigure for region controller refers to an incorrect network topology assumption <MAAS:New> <https://launchpad.net/bugs/1718294>
<mup> Bug #1718294 opened: [packaging] dpkg-reconfigure for region controller refers to an incorrect network topology assumption <MAAS:New> <https://launchpad.net/bugs/1718294>
#maas 2017-09-20
<elmo_> hi guys.
<elmo_> question
<elmo_> is there a way
<elmo_> to get MAAS serving DHCP for a VLAN without having to create a new nic inside the maas server but rather relying on cisco/router DHCP Helper?
<BlackDex> roaksoax: thx, i will lookin to that :)
<weergave> hallo
<mup> Bug #1718517 opened: [2.3] Errors while post-processing commissioning output should not cause commissioning to time out <MAAS:Triaged> <https://launchpad.net/bugs/1718517>
#maas 2017-09-21
<mup> Bug #1718561 opened: MAAS backup and restore documentation omits permission preservation <doc> <MAAS:New> <https://launchpad.net/bugs/1718561>
<mup> Bug #1718686 opened: [2.3, master] Machine lists shows green checks on components even when no tests have been run <MAAS:Triaged by ltrager> <https://launchpad.net/bugs/1718686>
<mup> Bug #1718686 changed: [2.3, master] Machine lists shows green checks on components even when no tests have been run <MAAS:Triaged by ltrager> <https://launchpad.net/bugs/1718686>
<mup> Bug #1718686 opened: [2.3, master] Machine lists shows green checks on components even when no tests have been run <MAAS:Triaged by ltrager> <https://launchpad.net/bugs/1718686>
<mup> Bug #1718706 opened: [2.3, tgt] When not using tgt, MAAS shouldn't be managing tgt <MAAS:Triaged> <https://launchpad.net/bugs/1718706>
<mup> Bug #1718776 opened: [ui] Tooltips missing from the machines listing page <ui> <MAAS:New> <https://launchpad.net/bugs/1718776>
<mup> Bug #1718776 changed: [ui] Tooltips missing from the machines listing page <ui> <MAAS:New> <https://launchpad.net/bugs/1718776>
<mup> Bug #1718776 opened: [ui] Tooltips missing from the machines listing page <ui> <MAAS:New> <https://launchpad.net/bugs/1718776>
<mup> Bug #1718779 opened: 00-maas-06-get-fruid-api-data fails to run on controller <MAAS:Triaged> <https://launchpad.net/bugs/1718779>
#maas 2017-09-22
<jose-phillips> Hi
<jose-phillips> i have a question i already have fuel . but im thinking to switch to maas someone can explain me how openstack upgrades works in maas?
<roaksoax> jose-phillips: maas is not tied to openstack itself. MAAS will, however, deploy the underlying hardware for you
<roaksoax> jose-phillips: if you are to use juju, then juju would hande the openstack upgrade for you
<jose-phillips> and then what is the difference between ubuntu openstack and juju ?
<jose-phillips> juju is like a bootstrapper?
<roaksoax> jose-phillips: juju is the modeling system
<roaksoax> jose-phillips: juju models your infrastructure, and orchestrates it
<roaksoax> jose-phillips: s/infrastructure/service
<roaksoax> jose-phillips: you can use juju to model,deploy,manage ubuntu openstack
<jose-phillips> got it
<mup> Bug #1719015 opened: $TTL in zone definition is not updated <dns> <internal> <sts> <MAAS:Triaged> <https://launchpad.net/bugs/1719015>
<jamesbenson> jose-phillips: but juju can also orchestrate/deploy other services like k8s, etc.
#maas 2019-09-16
<mup> Bug #1844159 opened: MaaS does not set XSS Protection Headers  <MAAS:New> <https://launchpad.net/bugs/1844159>
<mup> Bug #1844159 changed: MaaS does not set XSS Protection Headers  <MAAS:New> <https://launchpad.net/bugs/1844159>
<mup> Bug #1844159 opened: MaaS does not set XSS Protection Headers  <MAAS:New> <https://launchpad.net/bugs/1844159>
<mup> Bug #1844162 opened: Instructions missing in MaaS manual for disabling the reverse proxy running on port 8000/3128  <MAAS:New> <https://launchpad.net/bugs/1844162>
<mup> Bug #1844162 changed: Instructions missing in MaaS manual for disabling the reverse proxy running on port 8000/3128  <MAAS:New> <https://launchpad.net/bugs/1844162>
<mup> Bug #1844162 opened: Instructions missing in MaaS manual for disabling the reverse proxy running on port 8000/3128  <MAAS:New> <https://launchpad.net/bugs/1844162>
#maas 2019-09-17
<mup> Bug #1844282 opened: MAAS web UI should degrade more gracefully when Javascript is turned off <MAAS:New> <https://launchpad.net/bugs/1844282>
<mup> Bug #1844282 changed: MAAS web UI should degrade more gracefully when Javascript is turned off <MAAS:New> <https://launchpad.net/bugs/1844282>
<mup> Bug #1844282 opened: MAAS web UI should degrade more gracefully when Javascript is turned off <MAAS:New> <https://launchpad.net/bugs/1844282>
<mup> Bug #1844437 opened: [2.6, UI] Setting manual power type doesn't allow saving <MAAS:New> <https://launchpad.net/bugs/1844437>
#maas 2019-09-18
<mup> Bug #1843641 opened: [RFE] Expose valid filesystem types via API <MAAS:New> <https://launchpad.net/bugs/1843641>
<mup> Bug #1841166 changed: Unable to deploy Eoan on i386 bare-metal <i386> <MAAS:Invalid> <ubuntu-kernel-tests:Invalid> <maas (Ubuntu):Invalid> <https://launchpad.net/bugs/1841166>
<mup> Bug #1841166 changed: Unable to deploy Eoan on i386 bare-metal <i386> <MAAS:Invalid> <ubuntu-kernel-tests:Invalid> <maas (Ubuntu):Invalid> <https://launchpad.net/bugs/1841166>
<mup> Bug #1841166 opened: Unable to deploy Eoan on i386 bare-metal <i386> <MAAS:Invalid> <ubuntu-kernel-tests:Invalid> <maas (Ubuntu):Invalid> <https://launchpad.net/bugs/1841166>
<mup> Bug #1841166 changed: Unable to deploy Eoan on i386 bare-metal <i386> <MAAS:Invalid> <ubuntu-kernel-tests:Invalid> <maas (Ubuntu):Invalid> <https://launchpad.net/bugs/1841166>
<mup> Bug #1844541 opened: [2.6] Deploying Windows images on a region controller results in "Permission denied: /etc/maas/rackd.conf" <MAAS:Triaged by blake-rouse> <https://launchpad.net/bugs/1844541>
<mup> Bug #1844544 opened: multiple gateways with ipv6 and routing-policy <MAAS:New> <https://launchpad.net/bugs/1844544>
<mup> Bug #1844577 opened: Documentation for installing maas from source <MAAS:New> <https://launchpad.net/bugs/1844577>
#maas 2019-09-19
<mup> Bug # changed: 1053507, 1313937, 1316394, 1341699, 1353495, 1393949, 1418181, 1461233, 1464320, 1489380, 1491403, 1500454, 1547277, 1556085, 1556188, 1558000, 1567199, 1569960, 1595996, 1606281, 1607345, 1611726, 1612620, 1612668, 1613215, 1616552, 1620012, 1620946, 1621062, 1621610, 1621647,
<mup> 1630681, 1633555, 1634294, 1636933, 1637256, 1638453, 1638600, 1639219, 1640201, 1643403, 1646571, 1650592, 1651252, 1651274, 1653805, 1657520, 1658808, 1658990, 1659311, 1659392, 1660439, 1660498, 1660883, 1661672, 1663569, 1663614, 1664558, 1666521, 1668315, 1668329, 1668650, 1670886, 1671453,
<mup> 1671756, 1672088, 1673433, 1674818, 1677203, 1677369, 1677940, 1679844, 1680266, 1680398, 1681777, 1681789, 1688013, 1692607, 1696285, 1697949, 1700795, 1701256, 1705212, 1705418, 1706423, 1708679, 1712096, 1712602, 1712917, 1714580, 1716784, 1717511, 1718706, 1719669, 1723955, 1729638, 1729840,
<mup> 1729904, 1732743, 1732788, 1732927, 1732942, 1748034, 1787417, 1787467, 1789426, 1798676, 1799871, 1812275, 1816451, 1820184
<mup> Bug # changed: 1681780, 1682163, 1683741, 1683758, 1683826, 1683844, 1683849, 1683856, 1683863, 1688117, 1703673, 1716894, 1721270, 1722538, 1723232, 1727394, 1733411, 1734391, 1737357, 1737436, 1737821, 1738183, 1741279, 1741351, 1741913, 1742299, 1745198, 1747084, 1747458, 1748538, 1748542,
<mup> 1750604, 1750688, 1754304, 1754335, 1756016, 1756821, 1757262, 1759085, 1759086, 1759911, 1760770, 1760880, 1760961, 1761257, 1761342, 1761640, 1761802, 1770072, 1771110, 1771457, 1771547, 1771897, 1773384, 1773405, 1773442, 1773455, 1774266, 1774665, 1776056, 1776619, 1777169, 1777719, 1781464,
<mup> 1782007, 1787617, 1789710, 1791185, 1792038, 1792166, 1797223, 1797950, 1797986
<mup> Bug # opened: 1053507, 1313937, 1316394, 1341699, 1353495, 1393949, 1418181, 1461233, 1464320, 1489380, 1491403, 1500454, 1547277, 1556085, 1556188, 1558000, 1567199, 1569960, 1595996, 1606281, 1607345, 1611726, 1612620, 1612668, 1613215, 1616552, 1620012, 1620946, 1621062, 1621610, 1621647,
<mup> 1630681, 1633555, 1634294, 1636933, 1637256, 1638453, 1638600, 1639219, 1640201, 1643403, 1646571, 1650592, 1651252, 1651274, 1653805, 1657520, 1658808, 1658990, 1659311, 1659392, 1660439, 1660498, 1660883, 1661672, 1663569, 1663614, 1664558, 1666521, 1668315, 1668329, 1668650, 1670886, 1671453,
<mup> 1671756, 1672088, 1673433, 1674818, 1677203, 1677369, 1677940, 1679844, 1680266, 1680398, 1681777, 1681780, 1681789, 1682163, 1683741, 1683758, 1683826, 1683844, 1683849, 1683856, 1683863, 1688013, 1688117, 1692607, 1696285, 1697949, 1700795, 1701256, 1703673, 1705212, 1705418, 1706423, 1708679,
<mup> 1712096, 1712602, 1712917, 1714580, 1716784, 1716894, 1717511, 1718706, 1719669, 1721270, 1722538, 1723232, 1723955, 1727394, 1729638, 1729840, 1729904, 1732743, 1732788, 1732927, 1732942, 1733411, 1734391, 1737357, 1737436, 1737821, 1738183, 1741279, 1741351, 1741913, 1742299, 1745198, 1747084,
<mup> 1747458, 1748034, 1748538, 1748542, 1750604, 1750688, 1754304, 1754335, 1756016, 1756821, 1757262, 1759085, 1759086, 1759911, 1760770, 1760880, 1760961, 1761257, 1761342, 1761640, 1761802, 1770072, 1771110, 1771457, 1771547, 1771897, 1773384, 1773405, 1773442, 1773455, 1774266, 1774665, 1776056,
<mup> 1776619, 1777169, 1777719, 1781464, 1782007, 1787417, 1787467, 1787617, 1789426, 1789710, 1791185, 1792038, 1792166, 1797223, 1797950, 1797986, 1798676, 1799871, 1812275, 1816451, 1820184
<mup> Bug # changed: 944325, 1053507, 1272019, 1280456, 1298777, 1302299, 1313937, 1316394, 1326486, 1341699, 1353495, 1382663, 1389799, 1389804, 1393484, 1393944, 1393949, 1401976, 1401987, 1402705, 1415112, 1418158, 1418181, 1420768, 1420895, 1423590, 1430424, 1433627, 1435504, 1436528, 1437007,
<mup> 1437443, 1439751, 1443673, 1445574, 1461233, 1464320, 1489380, 1491403, 1500454, 1547277, 1556085, 1556188, 1558000, 1567199, 1569960, 1595996, 1606281, 1607345, 1611726, 1612620, 1612668, 1613215, 1616552, 1620012, 1620946, 1621062, 1621610, 1621647, 1630681, 1633555, 1634294, 1636933, 1637256,
<mup> 1638453, 1638600, 1639219, 1640201, 1643403, 1646571, 1650592, 1651252, 1651274, 1653805, 1657520, 1658808, 1658990, 1659311, 1659392, 1660370, 1660439, 1660440, 1660498, 1660589, 1660812, 1660883, 1661254, 1661583, 1661672, 1661879, 1662274, 1663008, 1663387, 1663569, 1663614, 1664424, 1664558,
<mup> 1664882, 1665316, 1665680, 1666343, 1666478, 1666521, 1668315, 1668329, 1668650, 1668880, 1670886, 1671242, 1671320, 1671415, 1671453, 1671520, 1671756, 1672088, 1672370, 1673087, 1673433, 1674747, 1674818, 1674866, 1676330, 1676864, 1676911, 1677203, 1677369, 1677444, 1677940, 1678215, 1679844,
<mup> 1680266, 1680398, 1680537, 1680812, 1680990, 1681777, 1681780, 1681789, 1682163, 1682317, 1682823, 1683741, 1683758, 1683826, 1683844, 1683849, 1683856, 1683863, 1685108, 1686248, 1686412, 1688013, 1688117, 1690459, 1691203, 1692607, 1696285, 1697949, 1699833, 1699855, 1700592, 1700795, 1701256,
<mup> 1702332, 1702754, 1703661, 1703673, 1705212, 1705418, 1705473, 1706423, 1708679, 1710096, 1711395, 1712096, 1712602, 1712917, 1713118, 1714106, 1714533, 1714580, 1715501, 1715876, 1716784, 1716894, 1717348, 1717511, 1718706, 1719316, 1719669, 1719978, 1721106, 1721270, 1721831, 1722531, 1722532,
<mup> 1722538, 1722851, 1723232, 1723955, 1723978, 1724005, 1724007, 1724618, 1724973, 1727394, 1727417, 1727900, 1729638, 1729840, 1729904, 1730965, 1731017, 1732224, 1732594, 1732743, 1732788, 1732927, 1732942, 1733411, 1734391, 1735838, 1737357, 1737436, 1737821, 1738183, 1741279, 1741351, 1741913,
<mup> 1742299, 1745198, 1747084, 1747458, 1748034, 1748538, 1748542, 1750604, 1750688, 1754304, 1754335, 1756016, 1756357, 1756821, 1757262, 1758860, 1759081, 1759082, 1759085, 1759086, 1759092, 1759557, 1759911, 1760770, 1760879, 1760880, 1760961, 1761257, 1761262, 1761342, 1761640, 1761802, 1761804,
<mup> 1766334, 1768736, 1768899, 1770072, 1770743, 1771110, 1771457, 1771465, 1771547, 1771711, 1771897, 1773117, 1773384, 1773405, 1773422, 1773442, 1773455, 1774266, 1774665, 1775210, 1775430, 1776056, 1776137, 1776619, 1777169, 1777443, 1777719, 1778488, 1779716, 1781241, 1781464, 1782007, 1782220,
<mup> 1782413, 1785014, 1786114, 1786147, 1787417, 1787467, 1787617, 1787960, 1788862, 1789426, 1789710, 1790055, 1790632, 1791006, 1791185, 1792038, 1792094, 1792166, 1793310, 1794289, 1794853, 1796003, 1796395, 1796416, 1796418, 1797223, 1797950, 1797986, 1798676, 1798864, 1799871, 1799999, 1803195,
<mup> 1804015, 1805477, 1805784, 1805811, 1806756, 1808876, 1809017, 1809463, 1809939, 1810980, 1811223, 1812141, 1812275, 1812846, 1813021, 1813379, 1813381, 1815083, 1816451, 1820184
<mup> Bug # opened: 1737357, 1786114, 1788862, 1796395
<mup> Bug #1750688 opened: [enhacement] Disable Intel firmware embedded LLDP agent before collecting LLDP data <cpe-onsite> <MAAS:New> <https://launchpad.net/bugs/1750688>
<mup> Bug #1773405 opened: [2.x] MAAS uses 0 for untagged vlan's vid <foundations-engine> <internal> <networking> <MAAS:New> <https://launchpad.net/bugs/1773405>
<mup> Bug #1676911 opened: MAAS should have a re-deploy action <MAAS:Confirmed> <https://launchpad.net/bugs/1676911>
<mup> Bug #1805477 opened: [docs] MAAS documentation is unclear regarding proxied node traffic <MAAS:Confirmed for jsseidel> <https://launchpad.net/bugs/1805477>
<mup> Bug #1815083 opened: MAAS Tag Edit link on Machine Summary doesn't let me edit tags <ui> <MAAS:Confirmed> <https://launchpad.net/bugs/1815083>
<mup> Bug #1676911 changed: MAAS should have a re-deploy action <MAAS:Confirmed> <https://launchpad.net/bugs/1676911>
<mup> Bug #1805477 changed: [docs] MAAS documentation is unclear regarding proxied node traffic <MAAS:New for jsseidel> <https://launchpad.net/bugs/1805477>
<mup> Bug #1815083 changed: MAAS Tag Edit link on Machine Summary doesn't let me edit tags <ui> <MAAS:Confirmed> <https://launchpad.net/bugs/1815083>
<mup> Bug # opened: 1664882, 1676911, 1724973, 1732743, 1805477, 1815083
<mup> Bug # changed: 1686887, 1690882, 1727721, 1728004, 1730018, 1734980, 1741923, 1743515, 1746831, 1749870, 1750714, 1754041, 1754045, 1758997, 1759275, 1761322, 1761359, 1764440, 1765816, 1766707, 1770413, 1770431, 1770623, 1782009, 1785724, 1786566, 1786799, 1794080, 1796160, 1797597, 1798132,
<mup> 1798385, 1800573, 1801752, 1802174, 1802505, 1803201
<mup> Bug # opened: 1686887, 1690882, 1727721, 1728004, 1730018, 1734980, 1741923, 1743515, 1746831, 1749870, 1750714, 1754041, 1754045, 1758997, 1759275, 1761322, 1761359, 1764440, 1765816, 1766707, 1770413, 1770431, 1770623, 1782009, 1785724, 1786566, 1786799, 1794080, 1796160, 1797597, 1798132,
<mup> 1798385, 1800573, 1801752, 1802174, 1802505, 1803201
<mup> Bug # changed: 1457671, 1460816, 1462498, 1468945, 1478107, 1485139, 1488649, 1498224, 1504865, 1517180, 1522933, 1542982, 1551799, 1555703, 1570374, 1570391, 1579758, 1579909, 1590546, 1598116, 1599955, 1600121, 1605278, 1610381, 1610954, 1611984, 1612689, 1614619, 1621072, 1628060, 1628118,
<mup> 1629106, 1630757, 1631062, 1631129, 1632498, 1632759, 1633271, 1635298, 1636602, 1637203, 1639054, 1639090, 1641913, 1643595, 1644345, 1648723, 1650562, 1650566, 1651455, 1654515, 1654929, 1655440, 1671201, 1672839, 1674714, 1686887, 1687769, 1690882, 1690883, 1695937, 1695994, 1696108, 1696272,
<mup> 1698767, 1698895, 1699622, 1700180, 1701400, 1701701, 1703231, 1703712, 1703895, 1704176, 1704993, 1706700, 1708289, 1708529, 1710310, 1712406, 1712695, 1713788, 1717269, 1719440, 1719473, 1720242, 1721523, 1721869, 1722090, 1722526, 1727397, 1727721, 1727754, 1727884, 1728004, 1730018, 1730456,
<mup> 1732920, 1733945, 1734980, 1735311, 1736832, 1740935, 1741525, 1741527, 1741923, 1743515, 1744562, 1746831, 1747688, 1749794, 1749870, 1750714, 1750914, 1753667, 1754041, 1754045, 1754484, 1758997, 1759275, 1761322, 1761359, 1764440, 1765816, 1766707, 1770413, 1770431, 1770623, 1782009, 1785724,
<mup> 1786566, 1786799, 1794080, 1796160, 1797597, 1798132, 1798385, 1798671, 1799579, 1800573, 1801752, 1802174, 1802214, 1802307, 1802505, 1803201, 1807820, 1808860, 1811013, 1815380, 1815630, 1815801, 1815930, 1816188, 1817615, 1817725, 1817806, 1818272, 1818989, 1820967, 1821323, 1821324, 1821325
<mup> Bug # changed: 975468, 1118815, 1335175, 1336816, 1387381, 1396740, 1400833, 1443671, 1472626, 1506143, 1535698, 1565979, 1580396, 1588093, 1591336, 1682189, 1683786, 1683811, 1683864, 1684070, 1684140, 1686464, 1814787, 1815084, 1815784, 1818003, 1820194, 1820753, 1821310
<mup> Bug # changed: 1389412, 1402697, 1470604, 1489149, 1518226, 1569683, 1588161, 1602477, 1608629, 1610250, 1621901, 1628333, 1628547, 1629499, 1629972, 1631113, 1632808, 1635107, 1636601, 1637412, 1639769, 1646133, 1650554, 1650575, 1650580, 1650648, 1652294, 1652297, 1652300, 1652304, 1652318,
<mup> 1652321, 1655164, 1655638, 1659383, 1659642, 1659692, 1660810, 1661969, 1666448, 1729474, 1731188, 1731935, 1744606, 1755903, 1764322, 1796175, 1812901, 1821329, 1821331, 1821332, 1841585
<mup> Bug # opened: 1517180, 1700180, 1735311, 1747688, 1794080, 1802505
<mup> Bug # opened: 1472626, 1610250, 1630757, 1631129, 1639054, 1810980, 1815084
<mup> Bug # changed: 1472626, 1610250, 1630757, 1631129, 1639054, 1810980, 1815084
<mup> Bug # opened: 1472626, 1610250, 1630757, 1631129, 1639054, 1793310, 1810980, 1815084
<mup> Bug #1610250 changed: [enhancement] MAAS needs a reboot option for nodes <hwcert-server> <wishlist> <MAAS:Invalid> <https://launchpad.net/bugs/1610250>
<roaksoax> wom 2
<mup> Bug #1820967 opened: MAAS failing to commission HP ProLiant DL385 G7 (AMD Opteron 6172) <MAAS:New> <https://launchpad.net/bugs/1820967>
<Zwift> If I'm trying to update a machine's interface vlan id, is the endpoint call: :put  nodes/{sys_id}/interfaces/{interface id}   op: 'update', vlan: {vlan id}?
<Zwift> The return I get is: Unrecognised signature: method=PUT op=update
<mup> Bug # opened: 1353495, 1460816, 1470604, 1591336, 1699833, 1699855, 1702754, 1708679, 1713118, 1733945, 1747458, 1754484, 1761262, 1766334, 1773422, 1815930, 1817615
<killcity> hey all, i have a dumb question. if i want to deploy a bunch of nodes that i plan on trigger ansible jobs against (post os install) how can i effectively divide them into separate roles in maas? would that be by resource pool?
<killcity> basically, we install the os and then trigger a playbook run via tower-cli once the box is up, which then adds the node to the awx inventory and into the specific groups depending on purpose.
<killcity> we are doing this with stacki and want to move over to maas.
<killcity> but stacki has the concept of carts, boxes and pallets. trying to understand how that translates into maas.
<killcity> thx
<killcity> i saw cloud-init and curtain support, but was unsure as to how we would classify each type of node for their final intended purpose.
<mup> Bug #1844734 opened: blacklist nic <feature> <MAAS:New> <https://launchpad.net/bugs/1844734>
<mup> Bug #1844734 changed: blacklist nic <feature> <MAAS:New> <https://launchpad.net/bugs/1844734>
<mup> Bug #1844734 opened: blacklist nic <feature> <MAAS:New> <https://launchpad.net/bugs/1844734>
<mup> Bug #1844734 changed: blacklist nic <feature> <MAAS:New> <https://launchpad.net/bugs/1844734>
<mup> Bug #1844734 opened: blacklist nic <feature> <MAAS:New> <https://launchpad.net/bugs/1844734>
#maas 2019-09-20
<mup> Bug #1841136 changed: [UI] "Save changes" button disabled when configuring "Manual" power type <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1841136>
<mup> Bug #1844437 changed: [2.6, UI] Setting manual power type doesn't allow saving <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1844437>
<mup> Bug #1841136 opened: [UI] "Save changes" button disabled when configuring "Manual" power type <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1841136>
<mup> Bug #1844437 opened: [2.6, UI] Setting manual power type doesn't allow saving <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1844437>
<mup> Bug #1841136 changed: [UI] "Save changes" button disabled when configuring "Manual" power type <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1841136>
<mup> Bug #1844437 changed: [2.6, UI] Setting manual power type doesn't allow saving <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1844437>
<mup> Bug #1820967 changed: MAAS failing to commission HP ProLiant DL385 G7 (AMD Opteron 6172) <MAAS:Invalid> <linux (Ubuntu):New> <https://launchpad.net/bugs/1820967>
<mup> Bug #1764322 opened: [UI] allow users to set owner data for a node <MAAS:Triaged> <https://launchpad.net/bugs/1764322>
<mup> Bug #1795903 changed: [2.5b2, backend]  could not fork new process for connection: Cannot allocate memory <MAAS:Fix Released> <https://launchpad.net/bugs/1795903>
<mup> Bug #1795903 opened: [2.5b2, backend]  could not fork new process for connection: Cannot allocate memory <MAAS:Fix Released> <https://launchpad.net/bugs/1795903>
<mup> Bug #1795903 changed: [2.5b2, backend]  could not fork new process for connection: Cannot allocate memory <MAAS:Fix Released> <https://launchpad.net/bugs/1795903>
<mup> Bug #1795903 opened: [2.5b2, backend]  could not fork new process for connection: Cannot allocate memory <MAAS:Fix Released> <https://launchpad.net/bugs/1795903>
<mup> Bug #1795903 changed: [2.5b2, backend]  could not fork new process for connection: Cannot allocate memory <MAAS:Fix Released> <https://launchpad.net/bugs/1795903>
<mup> Bug #1759946 changed: [2.3+, UI] Changing a subnet's fabric/vlan doesn't automatically update the interface model <MAAS:Won't Fix> <https://launchpad.net/bugs/1759946>
<mup> Bug #1796006 changed: [model, enhacement] VM's inside a MAAS deployed KVM host (pod) should be modeled as a node with a parent <MAAS:Invalid by mpontillo> <https://launchpad.net/bugs/1796006>
<mup> Bug #1759946 opened: [2.3+, UI] Changing a subnet's fabric/vlan doesn't automatically update the interface model <MAAS:Won't Fix> <https://launchpad.net/bugs/1759946>
<mup> Bug #1796006 opened: [model, enhacement] VM's inside a MAAS deployed KVM host (pod) should be modeled as a node with a parent <MAAS:Invalid by mpontillo> <https://launchpad.net/bugs/1796006>
<mup> Bug # changed: 1675981, 1685457, 1702567, 1727419, 1759946, 1796006
<mup> Bug #1628067 changed: [2.1, FUJ] Please update FUJ text to match latest copy doc chages <MAAS:Fix Released by andreserl> <https://launchpad.net/bugs/1628067>
<mup> Bug #1675495 changed: [2.x] Release of a new LTS should not break MAAS commissioning <MAAS:Fix Released> <https://launchpad.net/bugs/1675495>
<mup> Bug # opened: 1628067, 1675495, 1675981, 1685457, 1702567, 1727419
<mup> Bug # changed: 1628067, 1675495, 1675981, 1685457, 1702567, 1727419
<mup> Bug # opened: 1628067, 1675495, 1675981, 1685457, 1702567, 1727419
<mup> Bug # changed: 1628067, 1675495, 1675981, 1685457, 1702567, 1727419
<mup> Bug #1584926 changed: Provide API to get node statistics, including node count by status <MAAS:Fix Released> <https://launchpad.net/bugs/1584926>
<mup> Bug #1798471 changed: [2.5, ESXi] Always enable SSH on ESXi deployments or provide an option to do so <esxi> <track> <MAAS:Won't Fix> <https://launchpad.net/bugs/1798471>
<mup> Bug #1839811 changed: MAAS release node API calls, option to avoid transitioning to "Ready" <sts> <MAAS:Invalid> <https://launchpad.net/bugs/1839811>
<mup> Bug #1838247 opened: apt remove maas-region-controller causes broken DB state <MAAS:Triaged> <maas (Ubuntu):New> <https://launchpad.net/bugs/1838247>
<mup> Bug #1810796 changed: Unexpected APC power control configuration behavior <auto-sanity> <maas> <opm-priority> <taipei-lab> <MAAS:Invalid> <OEM Priority Project:Incomplete by taihsiangho> <https://launchpad.net/bugs/1810796>
<mup> Bug #1810796 opened: Unexpected APC power control configuration behavior <auto-sanity> <maas> <opm-priority> <taipei-lab> <MAAS:Invalid> <OEM Priority Project:Incomplete by taihsiangho> <https://launchpad.net/bugs/1810796>
<mup> Bug #1810796 changed: Unexpected APC power control configuration behavior <auto-sanity> <maas> <opm-priority> <taipei-lab> <MAAS:Invalid> <OEM Priority Project:Incomplete by taihsiangho> <https://launchpad.net/bugs/1810796>
<mup> Bug # changed: 1733945, 1747458, 1810955, 1826566, 1832908
<mup> Bug # opened: 1733945, 1747458, 1810955, 1826566, 1832908
<mup> Bug # changed: 1733945, 1747458, 1810955, 1826566, 1832908
<mup> Bug # opened: 1733945, 1747458, 1810955, 1826566, 1832908
<mup> Bug # changed: 1460816, 1517180, 1631129, 1733945, 1743595, 1747458, 1753486, 1810955, 1810980, 1812898, 1826566, 1826813, 1826942, 1832908, 1833046
<mup> Bug # changed: 1754484, 1815930, 1827324, 1832957, 1833432
<mup> Bug # changed: 1699855, 1761262, 1766334, 1828898
<mup> Bug #1702754 changed: No way to add a node as admin user without starting commissioning <cdo-qa> <internal> <MAAS:Invalid> <https://launchpad.net/bugs/1702754>
<mup> Bug #1713118 changed: [2.x] Provide curtin version as part of MAAS 'version' api <cdoqa> <MAAS:Invalid> <https://launchpad.net/bugs/1713118>
<mup> Bug #1827015 changed: MAAS wrongly reports cannot reach PowerEdge R630 BMC during machine create and fails to commission node later on <cpe-onsite> <MAAS:Invalid> <https://launchpad.net/bugs/1827015>
<mup> Bug #1839170 changed: Add support for IPMI system event logs <MAAS:Invalid> <https://launchpad.net/bugs/1839170>
<mup> Bug #1470604 changed: [enhancement] MAAS doesn't automatically discover SOL console settings <oil> <wishlist> <MAAS:Invalid> <https://launchpad.net/bugs/1470604>
<mup> Bug #1584949 changed: [feature] Provide Ubuntu desktop images for MAAS <MAAS:Invalid> <https://launchpad.net/bugs/1584949>
<mup> Bug #1820307 changed: http error 409 instead of 503 <juju:Incomplete> <MAAS:Invalid> <https://launchpad.net/bugs/1820307>
<mup> Bug # opened: 1470604, 1584949, 1820307, 1839170
<mup> Bug # changed: 1470604, 1584949, 1820307, 1839170
<mup> Bug # opened: 1470604, 1584949, 1820307, 1839170
<mup> Bug # changed: 1470604, 1584949, 1770982, 1773422, 1820307, 1839170
<mup> Bug #1844793 opened: Add WS API for user password change <websocket-api> <MAAS:New> <https://launchpad.net/bugs/1844793>
<mup> Bug #1844795 opened: Add WS API for register_url, register_secret <websocket-api> <MAAS:New> <https://launchpad.net/bugs/1844795>
<mup> Bug #1844796 opened: Remove CSRF protection from CSRF endpoint <MAAS:New for blake-rouse> <https://launchpad.net/bugs/1844796>
<mup> Bug #1786114 changed: [feature] nvme namespace CRUD and discovery support <curtin:Triaged> <MAAS:Invalid> <https://launchpad.net/bugs/1786114>
<mup> Bug #1835423 changed: No power status data for KVM <MAAS:Invalid> <https://launchpad.net/bugs/1835423>
<mup> Bug #1835423 opened: No power status data for KVM <MAAS:Invalid> <https://launchpad.net/bugs/1835423>
<mup> Bug #1835423 changed: No power status data for KVM <MAAS:Invalid> <https://launchpad.net/bugs/1835423>
<mup> Bug #1788862 changed: [feature] add support for enabling discard on a bcache device <cpe-onsite> <curtin:Triaged> <MAAS:Invalid> <https://launchpad.net/bugs/1788862>
<mup> Bug #1832034 changed: MaaS complains that xenial is the default commissioning image when it isn't <MAAS:Invalid> <https://launchpad.net/bugs/1832034>
<mup> Bug #1788862 opened: [feature] add support for enabling discard on a bcache device <cpe-onsite> <curtin:Triaged> <MAAS:Invalid> <https://launchpad.net/bugs/1788862>
<mup> Bug #1832034 opened: MaaS complains that xenial is the default commissioning image when it isn't <MAAS:Invalid> <https://launchpad.net/bugs/1832034>
<mup> Bug #1835423 opened: No power status data for KVM <MAAS:Invalid> <https://launchpad.net/bugs/1835423>
<mup> Bug # changed: 1788822, 1788862, 1793310, 1832034, 1832737, 1835423
<danboid> I presume I can (manually) swap netplan.io for ifupdown on my MAAS nodes if I need to?
<danboid> Running 18.04
<danboid> I know I can d that with a normal 18.04 install, but maybe some extra config is required if its a MAAS box?
<danboid> I have not been able to get juju bootstrap to finish successfully when using a netplan bridge so I'm going to try with ifupdown instead
<Ludw> Hi Huys, I'm not familiar with API yet and I try to log in with Postman. From what I understand API key in maas is divided this way : '<key>', '<secret>', '<consumer_key>
<Ludw> But in postman when I want to create my auth token is asks me for "Consumer  key - Consumer secret - Accesstoken - Token Secret"
<Ludw> I think I've tried all possibilities and no one is working
<Ludw> It's all good, was of course a bad settings issue ð
<danboid> Ludw, Sometimes you need to come rant on IRC or send an email to your workmates before the answer reveals itself
<danboid> Happens ALL THE TIME with me :)
<Ludw> hehe yes exactly
<Ludw> I'm still working on creating the token
<Ludw> actually the API key into MAAS dashboard is already a token ? Or it is 2 different things and I have to use this key the first time to create a token that I will use later for every request ?
<Ludw> The only thing I can do so far with the first key is to get API version
<Ludw> If I want go print my commission script I get a : User is not allowed access to this API.
<Ludw> I found this which solved my problem : https://github.com/CanonicalLtd/maas-docs/issues/647
<danboid> I've had several attempts now and it seems it is not possible to use ifupdown on a MAAS node running 18.04
<danboid> I presume I'll have to use 16.04 if I want to use ifupdown
<Ludw> why don't you want to use netplan ?
<danboid> I've not been able to create a bridge that works with juju bootstrap
