[01:04] <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.
[01:05] <smoser> you can poke around and see the issue, but basically, the following "should work" to get enlist the kvm node:
[01:05] <smoser>  xkvm --netdev maasbr0,macaddr=:01 --    -drive file=system-01.img,if=virtio -curses
[01:09] <roaksoax> smoser: you should made that availoable on a wikipage :)
[01:09] <smoser> ?
[01:10] <roaksoax> smoser: how you got MAAS working on canonicastack for it to enlist, dpeloy, etc
[01:11] <smoser> http://bazaar.launchpad.net/~smoser/maas/maas-pkg-test/view/head:/maas-ephemeral-test-quantal.txt
[01:11] <smoser> that is clsoe.
[01:11] <smoser> thats basically what i'm doing
[01:11] <smoser> and that has the maas server on the instance not in any sort of container.
[01:11] <smoser> i'd like to make it so that the maas server is in a lxc container.
[01:12] <smoser> i'll improve on that a bit more tomorrow.
[01:12] <roaksoax> awesome!
[01:14] <smoser> its pretty close.
[01:14] <smoser> and i hope to hvae some quantal images at least available that would work
[01:15] <smoser> the biggest hting i'm waiting on now for quantal is bug 643289
[01:15] <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
[01:15] <smoser> i have all the fixes i need collected at https://launchpad.net/~smoser/+archive/ephermal-fixes
[01:15] <smoser> but the mountall i'm wwaiting on slangasek for
[01:16] <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)
[01:16] <smoser> good night.
[01:17] <roaksoax> ack
[01:17] <roaksoax> night scoot
[02:17] <jtv> smoser: got no access to 10.55.60.130.
=== 50UABNR34 is now known as wallyworld
=== wallyworld is now known as Guest48627
[13:07] <mgz> so, what I was doing before lunch,
[13:08] <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?
[13:08] <mgz> the overhead of reverting a change, creating a new migration, applying that, then removing both is a bit pointless for test data
[13:09] <rvba> mgz: you can always rm -rf db && make sampledata
[13:10] <mgz> rvba: thanks, just what I was after
[13:10] <rvba> np
[13:28] <smoser> what daemon runs the tftp server?
[13:28] <roaksoax> smoser: pserv
[13:28] <roaksoax> maas-pserv
[13:30] <smoser> do you know what interfaces it binds to?
[13:31] <roaksoax> smoser: i think is the one with the address of MAAS_DEFAULT_URL
[13:31] <roaksoax> allenap: ^^
[13:32] <smoser> what is 'maas-dhcp/maas-dhcp-ip:' result in ?
[13:32] <smoser> the debconf value (that i added) ?
[13:34]  * allenap thinks
[13:34] <roaksoax> smoser: you mean maas-dhcp-addr?
[13:34] <roaksoax> smoser: tftp is different from dhcp
[13:35] <jtv> ¾ different in fact!
[13:35] <allenap> smoser, roaksoax: It listens on all interfaces, afaict.
[13:35] <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
[13:35] <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.
[13:36] <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
[13:36] <jtv> I see.  Wish I'd known!
[13:37] <roaksoax> rvba: idk if you saw but I uploaded the branch that adds the distro_series support. So we can start adding tests :)
[13:37] <smoser> jtv, https://bugs.launchpad.net/maas/+bug/1047061
[13:37] <ubot5> Ubuntu bug 1047061 in MAAS "dhcpd.conf next-server set to 127.0.0.1" [Critical,Fix released]
[13:37] <jtv> smoser: is that the one you were talking about?
[13:37] <jtv> The configuration problem you ran into?
[13:37] <smoser> see comment 1 there. that is what i was running into in https://bugs.launchpad.net/maas/+bug/1051626
[13:37] <ubot5> Ubuntu bug 1051626 in MAAS "tftp import broken" [Critical,Confirmed]
[13:38] <smoser> right.
[13:38] <rvba> roaksoax: I've seen that indeed :).  As promised I'll give you a hand with the tests.
[13:38] <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.
[13:38] <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.
[13:39] <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.”
[13:39] <smoser> roaksoax, shoot. i did mean addr, but i was preseeding ip.
[13:39] <smoser> hm.. one way or another that is busted, but it should have done better.
[13:40] <smoser> jtv, but who cares what serves dhcp?
[13:40] <smoser> other than next server.
[13:40] <smoser> it seems broken that you're requiring both interface to listen too and ip address.
[13:40] <jtv> Good question.  I'm about as confused about this as you are.
[13:41] <roaksoax> jtv: right makes sense
[13:41] <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.
[13:41] <roaksoax> smoser: liston to would be basically on what interfaces to listen DHCP requests, and ip address is the "next-server" isn't it?
[13:42] <jtv> No
[13:42] <jtv> Ah
[13:42] <smoser> roaksoax, i thought the same thing as you.
[13:42] <jtv> I think maybe it should be, but isn't yet.
[13:42] <rvba> next_server = get_maas_facing_server_address()
[13:42] <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
[13:42] <rvba> I don't see where that 'ip' is used in the code really… so I'm confused as well.
[13:42] <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.
[13:43] <smoser> can i suggest that people actually try to use code they write?
[13:43] <smoser> rather than just assuming that if tests pass it works?
[13:43] <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.
[13:43] <rvba> jtv: that's what Julian had in mind indeed… but where is this used?
[13:43] <jtv> Scott knows the details.
[13:44] <jtv> smoser: feel free to send hardware.  :)
[13:44] <smoser> jtv, canonistack works fine.
[13:44] <smoser> and a single system is all you need to test the vast majority of this.
[13:44] <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.  :(
[13:45] <smoser> you have to bounce thorugh chinstrap
[13:45] <smoser> (i did say that)
[13:45] <jtv> What a coincidence.
[13:45] <jtv> Because when you said that I actually did that.
[13:45] <jtv> Did I mention that it didn't work?
[13:46] <smoser> i dont have the instance any more , but i assume that your credentials weren't geting through.
[13:46] <smoser> i 'ssh-import-id jtv'
[13:46] <jtv> Well… maybe this was after you let the instance go.
[13:46] <jtv> Or it was taken from you, or whatever happened.
[13:47] <smoser> nah. that was this morning. maybe 30 minutes ago.
[13:47] <smoser> https://wiki.canonical.com/InformationInfrastructure/IS/CanonicalOpenstack?action=show&redirect=CanoniStack
[13:47] <jtv> Or evening, as we like to call it.  ;)
[13:47] <smoser> that is an *extremely* useful resource.
[13:47] <jtv> Thanks.  Maybe I'll play with it tomorrow.
[13:47] <smoser> you should set it up.
[13:47] <smoser> note, even EC2 or HP cloud can also test this tuff.
[13:47] <smoser> the real value of canonistack is that you can get nested virtualization.
[13:48] <jtv> That is nice, yes.
[13:48] <smoser> there are no public clouds to my knowledge that have nested virt support.
[13:49] <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.
[13:51] <jtv> Good thing I spotted it!
[13:52] <smoser> this is why we have instances.
[13:53] <smoser> and virtualization
[13:54] <smoser> ok. i re-purposed bug 1051626
[13:54] <ubot5> Launchpad bug 1051626 in MAAS "next-server written wrong" [Critical,Confirmed] https://launchpad.net/bugs/1051626
[13:54] <smoser> i did'nt follow all of what you all were saying above
[14:07] <smoser> what do we need to do to make dhcp actually funciton.
[14:14] <smoser> rvba, how can i ask maas what its server ip is?
[14:14] <smoser> the one it is listening to
[14:14] <smoser> (and is currently getting written aas 'next-server')
[14:15] <rvba> smoser: get_maas_facing_server_address()
[14:15] <smoser> anyway other htan python?
[14:16] <rvba> smoser: get_maas_facing_server_address extracts it from settings.DEFAULT_MAAS_URL.
[14:21] <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 "^>>>"
[14:21] <smoser> 10.55.60.130
[14:25] <roaksoax> Daviey: so you want me to ditch ipmitool in favor of freeipmi within MAAS right?
[14:27] <roaksoax> allenap: can you point me to the package and upstream of the package you wanted me to upload?
[14:28] <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.
[14:28] <roaksoax> cool
=== matsubara-afk is now known as matsubara
[14:41] <Daviey> roaksoax: I think it should be considered
[14:41] <Daviey> :)
[14:42] <roaksoax> Daviey: i don't mind changing it if necessary
[14:43] <roaksoax> Daviey: it will require a few changes but it is possible
[14:48] <Daviey> roaksoax: ideally, we'd support both IMO
[14:48] <roaksoax> Daviey: do we want to MIR ipmitool and freeipmi ?
[14:49] <roaksoax> Daviey: not that is is simply to power on/off machines nothing else
[14:49] <roaksoax> s/not/note
[14:49] <Daviey> roaksoax: JUST MIR'ing freeipmi seems more sensible IMO.
[14:49] <Daviey> It's a more active and safer project IMO.
[14:50] <Daviey> roaksoax: Yeah, so we don't have to worry about kernel integration
[14:50] <roaksoax> k
[14:52] <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
[14:53] <Daviey> roaksoax: For the MIR?
[14:53] <roaksoax> Daviey: worry about kernel integration --> we only need 1 binary
[14:53] <roaksoax> Daviey: but either way, i'll look into it
[14:54] <Daviey> roaksoax: right,i mean we are MIR'ing the whole shebang
[14:58] <roaksoax> indeed
=== cmagina is now known as cmagina_away
[16:43] <roaksoax> Daviey: bug #1052056 could you please ack?
[16:43] <ubot5> Launchpad bug 1052056 in freeipmi (Ubuntu) "[FFe] [MIR] freeipmi" [Undecided,New] https://launchpad.net/bugs/1052056
[17:47] <guimaluf> I would like to make maas node more sofisticated default settings. the most convinient way is going through cobbler and kickstart files?:
[17:49] <smoser> guimaluf, well, the going forward way is to basically allow cloud-init to handle that for you.
[17:50] <smoser> but currently, you'd have to write your own api tool to launch an instance with user-data.
[17:50] <guimaluf> smoser, is cloud-init a script?
[17:50] <smoser> https://help.ubuntu.com/community/CloudInit
[17:51] <guimaluf> smoser, exactly, i'm trying to cutomize via maas.pressed file and maybe puppet. but isn't enough
[17:51] <smoser> why "isnt enough?"
[17:51] <smoser> s/?"/"?/
[17:54] <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...
[17:54] <smoser> ah. yeah. i remmber. the only way you can accomplish that is via customization of the preseed.
[17:54] <guimaluf> I know puppet and preseed is enough. I just can find the way...
[17:55] <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!
[17:56] <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 :/
[17:58] <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
[17:58] <smoser> you're using maas on 12.04 ?
[17:58] <guimaluf> I would like to know how maas deal with that...
[17:58] <guimaluf> yep
[17:59] <guimaluf> I thought the clock syncronization issue would be the only problem getting ssh-keys, but isnt the only one.
[18:03] <smoser> well, the clock issue will most deifnitely block you
[18:03] <smoser> b
[18:03] <smoser> ut there are other issues potentially to
[18:03] <smoser> for some reason your installed node is not able to reach the maas metadata service
[18:03] <smoser> possibly routing
[18:04] <guimaluf> hmmmm make sense... the metadata service is 169.254.169.254? may I should create a iptables rule for that...
[18:06] <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?
[18:10] <smoser> maas has its own metadata service. 169.254.169.254 is the openstack metadata service.
[18:12] <guimaluf> and how can I know wich is the address?
[18:12] <guimaluf> I think this is happening cause my dhcp-server isnt the maas server
[18:13] <guimaluf> so I need to put a rule on firewall to redirect metadata server to my maas server right?
[18:14] <roaksoax> guimaluf: check that MAAS_DEFAULT_URL has the correct address in /etc/maas/maas_local_settings.py
[18:15] <Daviey> roaksoax: Forwarded to jdstrand
[18:16] <roaksoax> Daviey: k thanks!
[18:16] <guimaluf> roaksoax, is correct
[18:40] <smoser> guimaluf, and the nodes need to be able to get to the MAAS_DEFAULT_URL
[18:40] <guimaluf> they are.
[18:40] <guimaluf> they can do the PXE boot, ping, ssh, etc.
[18:52] <smoser> well, then the next thing is to get into a node and run the cloud-init maas datasource
[18:54] <smoser> there is a file in /etc/cloud/cloud.cfg.d/ with content in it for the acl.
[18:54] <smoser> you can run that and it should show errors also.
[18:55] <guimaluf> do you mean run this command? # cloud-init maas datasource
[18:55] <guimaluf> root@node-782bcb77e1d4:~# cloud-init maas datasource
[18:55] <guimaluf> bad command maas. use one of ('start', 'start-local')
[18:56] <smoser> no. sorry.
[18:57] <smoser> python /usr/share/pyshared/cloudinit/sources/DataSourceMAAS.py
=== cmagina_away is now known as cmagina
[19:01] <roaksoax> smoser: will you make quantal images available for commissioning/enlistment?
[19:02] <smoser> working on that right now. they dont work
[19:02] <smoser> :)
[19:02] <smoser> biggest thing i'm waiting on is mountall
[19:02] <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
[19:02] <smoser> https://launchpad.net/~smoser/+archive/ephermal-fixes
[19:03] <smoser> maas is actually ok.
[19:03] <roaksoax> k ;)
[19:03] <smoser> i'll upload openiscsi today
[19:04] <roaksoax> Daviey: sill around?
[19:04] <roaksoax> smoser: ok cool!
[19:04] <Daviey> roaksoax: i am
[19:04] <roaksoax> Daviey: where did you published the squashfs image? :)
[19:05] <roaksoax> publish*
[19:06] <Daviey> roaksoax: I haven't.. i manually exposed it via cp'ing it to a place on cdimage
[19:06] <roaksoax> Daviey: is it still exposed? Are we going to keep exposing it?
[19:07] <roaksoax> Daviey: or should I just use the mini.iso?
[19:07] <Daviey> mini.iso doesn't ship the squashfs :)
[19:07] <roaksoax> ah i thought it did
[19:08] <roaksoax> Daviey: in that case, I think it would make sense to make the iamge available somewhere in cdimage
[19:08] <roaksoax> Daviey: that way we wont have to download the whole ISO
[19:11] <Daviey> hmm
[19:12] <Daviey> http://cdimage.ubuntu.com/ubuntu-server/daily/current/quantal-server-amd64.squashfs
[19:12] <Daviey> It's only 61M
[19:12] <Daviey> roaksoax: That is temp' do not expect it to be there tomorrow
[19:12] <roaksoax> Daviey: ok cool thanks
[19:23] <roaksoax> smoser: do you think it would be a good idea to change wget on maas-import-pxe-files to rsync instead?
[19:27] <smoser> roaksoax, no.
[19:27] <smoser> for what, specifically?
[19:27] <roaksoax> maas-import-pxe-files
[19:27] <smoser> what files
[19:27] <roaksoax> to donwload the required files
[19:27] <roaksoax> initrd.gz
[19:27] <roaksoax> linux
[19:27] <roaksoax> etc
[19:27] <roaksoax> etc
[19:27] <smoser> url? example?
[19:27] <smoser> why would that be superior to wget
[19:28] <roaksoax> smoser: http://paste.ubuntu.com/1211666/
[19:28] <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
[19:30] <smoser> is that stuff available via rsync ?
[19:30] <smoser> i dont think its really that big of a deal.
[19:30] <roaksoax> smoser: yeah
[19:31] <smoser> you're looking at, what, 100M there?
[19:31] <smoser> at max.
[19:31] <smoser> actually.
[19:31] <smoser> no.
[19:31] <smoser> we do not want rsync
[19:31] <smoser> due to it being less proxyable
[19:31] <roaksoax> ok
[19:32] <smoser> ie, you get the resume for all practicle purposes for free if you set http_proxy
[19:33] <smoser> now, for the lcoud-images, we coudl/should make those resume better.
[19:34] <roaksoax> right
[19:34] <roaksoax> i'm also trying to avoid the fact of having to download those files each time
[19:34] <smoser> use a proxy, silly.
[19:35] <roaksoax> lol will have to
[19:50] <roaksoax> smoser: did you make any change to the boot process to display the kernel parameters on enlistment/commissioning?
[19:52] <smoser> yes.
[19:53] <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)
[19:53] <roaksoax> nor during commissioning
[19:53] <smoser> its going to ttyS0
[19:54] <smoser> which i think is actually more correct in this environment.
[19:55] <smoser> roaksoax, do you agree?
[19:55] <roaksoax> smoser: i have no say on this, It doesn't really matter to me
[19:55] <roaksoax> smoser: so yes, whichever you think is best, I agree
[19:55] <smoser> well, console is almost certainly not being logged as text in any reasonable manner
[19:56] <smoser> console as in 'tty1' (video console)
[19:56] <smoser> ttyS0 might be.
[19:57] <roaksoax> yeah i agree that's probably the best place
[20:01] <smoser> roaksoax, i just built a quantal image
[20:01] <smoser> using my ppa i pointed at
[20:01] <smoser> and have enlisted 3 systems
[20:01] <smoser> whoowhoo!
[20:02] <smoser> using the daily ppa of maas from this morning.
[20:02] <roaksoax> smoser: awesome!
[20:03]  * roaksoax brb
[20:06] <smoser> roaksoax, hm.
[20:06] <smoser> can't i somehow deploy a node from the ui?
[20:07] <roaksoax> smoser yes you can
[20:07] <smoser> hm..
[20:07] <roaksoax> smoser not quantal though
[20:07] <smoser> oh. ok.
[20:07] <smoser> wait
[20:08] <roaksoax> smoser but you wont be able to release it nir delete it if you do so
[20:08] <smoser> roaksoax: ssh -L 10080:localhost:80 10.55.63.64
[20:09] <smoser> tell me if what you see on http://localhost:10080/MAAS for 'node-525400123403' is other than expected
[20:13] <roaksoax>   smoser brb xhsnging locstiond
[20:14] <smoser> k
[20:46] <roaksoax> smoser: sorry about that
[20:47] <smoser> no worries
[20:48] <roaksoax> smoser: what is it that you wanted me to look at?
[20:48] <smoser> well, one of those nodes is commissedon
[20:48] <smoser> how would you push a button to install it?
[20:49] <roaksoax> smoser: you can't start it? or it can't commission? or you need it to commission?
[20:49] <roaksoax> smoser: or the button is there but it is greyed out?
[20:50] <roaksoax> smoser: if you add a node from the WebUI there's no start button IIRC
[20:51] <smoser> the start button is greyed out
[20:52] <smoser> (you can look at the ui with the ssh above)
[20:52] <roaksoax> smoser: did you add an SSH key?
[20:54] <roaksoax> smoser: i think you need to add an ssh key in order for it to allow you to start the machine
[20:54] <smoser> roaksoax, no i did not add ssh key
[21:17] <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?
[21:35] <matsubara> smoser, hi there
[21:36] <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?
[21:37] <roaksoax> smoser: so I guess you figured by now that you need to add an ssh key in order to start them
=== cmagina is now known as cmagina_away
[23:59] <smoser> matsubara, nothing should be waiting on eth1. and the image hasn't changed (unless you're using 'daily', which would have taken configuration).
[23:59] <smoser> you could be hitting a bug i supposed could exist.