[00:00] <bigjools> hack the api source that deals with maas-enlist
[00:00] <bigjools> log the request there
[00:00] <roaksoax> bigjools: this is not maas-enlist btw
[00:00] <roaksoax> this is maas0singla
[00:00] <roaksoax> maas-signal
[00:00] <bigjools> yeah
[00:00] <bigjools> that hits metadata service IIRC?
[00:01] <roaksoax> yeah
[00:29] <bigjools> roaksoax: any luck?
[00:31] <kurt_> Any ideas why tags aren't working? http://pastebin.ubuntu.com/6207405/
[00:32] <roaksoax> bigjools: nope
[00:32] <roaksoax> bigjools: i gave up
[00:32] <bigjools> roaksoax: urgh
[00:32] <bigjools> roaksoax: I'll see if we can extend that logging to the metadata api
[00:33] <bigjools> roaksoax: but surely a logger.info() hack will show you the data we need
[00:33] <roaksoax> bigjools: i uploaded the paclage to experimwntal ppa
[00:33] <roaksoax> that includes the
[00:33] <roaksoax> moonshotbstudd
[00:33] <roaksoax> stuff
[00:33] <roaksoax> anyway i gotta go
[00:33] <roaksoax> will be back later
[00:33] <bigjools> roaksoax: ok
[00:34] <bigjools> kurt_: are you sure the system id is right
[00:34] <kurt_> I'll pastebin
[00:37] <kurt_> bigjools: good call.  I'm working with two different test systems. Thanks
[00:37] <stokachu> im still having issues getting the maas instance to power off/start a node via virsh
[00:38] <stokachu> ive tested that i can virsh --connect qemu+ssh://ubuntu@10.x.x.x/system from the maas instance and can see the nodes
[00:38] <stokachu> and starting/stopping from there works
[00:39] <stokachu> ssh keys are deployed from maas instance to host as well
[00:39] <stokachu> keys are added to my preferences
[00:42] <smoser> stokachu, is your problem that maas can't power the nodes on?
[00:42] <stokachu> smoser: yea
[00:42] <smoser> are yo usure ?
[00:42] <stokachu> smoser: i click start node from the UI and nothing happens
[00:42] <stokachu> if i use virsh from maas instance i can start it there
[00:42] <stokachu> ive looked through all the logs and don't actually see where it attempts to power the node on
[00:43] <smoser> you can do that as the 'maas' user ?
[00:43] <stokachu> smoser: yea running virsh --connect qemu+ssh://ubuntu@10.x.x.x/system from the maas instance works
[00:43] <smoser> no
[00:43] <smoser> as the maas user
[00:44] <smoser> sudo -Hu maas virsh --connect ...
[00:44] <stokachu> lemme try
[00:44] <smoser> in saucy the virsh.template is /etc/maas/templates/power/virsh.template
[00:44] <smoser> it might be elsewhere on raring.
[00:44] <stokachu> it prompts for a password so i dont have ssh keys copied for that user
[00:45] <smoser> right. so 2 options then.
[00:45] <smoser> a.) get the maas user able to connect without prompt
[00:46] <smoser> b.) change that template file in issue_virsh_command() to do sudo -Hu someuser
[00:46] <smoser> and make someuser able to connect
[00:46] <stokachu> ok, and where in the logs could i find errors like this?
[00:46] <stokachu> like where it seems to be waiting on input
[00:47] <stokachu> is that a celery thing?
[00:47] <smoser> i dont know where you'd see logs liek this. probably would be in cluster-controller.
[00:47] <smoser> it may be that its just still blocked int hat script
[00:47] <smoser> and there *is* no long
[00:47] <smoser> no log
[00:48] <smoser> fwiw, http://bazaar.launchpad.net/~virtual-maasers/charms/precise/virtual-maas/trunk/view/head:/scripts/setup-maas
[00:48] <smoser> see line 230 there. thats how we hacked it. 229 -> 243
[00:49] <stokachu> ah ok
[00:50] <smoser> but you shoudl prbably be able to get the maas user able to ssh itself like that
[00:50] <stokachu> smoser: yea i need to set a shell for the maas user and all that
[00:50] <smoser> right.
[00:51] <stokachu> ok lemme do that now and see
[00:56] <stokachu> smoser: http://askubuntu.com/questions/292061/how-to-configure-maas-to-be-able-to-boot-virtual-machines found this as well
[00:56] <stokachu> maybe we should add that into the official docs for maas on libvirt
[00:57] <smoser> that is a well written answer.
[00:58] <stokachu> thats the way i just did it and it worked
[02:06] <smoser> roaksoax, bigjools ... is there a way to create a non-admin user non-interactively ?
[02:06] <smoser>  i guess i can just create admin and the drop staff or something.
[02:07] <bigjools> smoser: don't think there is
[02:07] <roaksoax> no idea
[03:36] <roaksoax> bigjools: any luck?
[03:36] <bigjools> roaksoax: well I was waiting for you to implement my suggestion
[03:37] <roaksoax> bigjools: lol what's your suggestion again?
[03:37] <bigjools> logger.info() in the relevant API call
[03:37] <bigjools> dump the request
[03:37] <bigjools> either that or you just tcpdump
[03:39] <roaksoax> bigjools: well unfortunately i lost access to the environment
[03:39] <roaksoax> so i guess nothing will get done today
[03:39] <bigjools> damn
[03:39] <bigjools> well we can reproduce elsewhere
[03:39] <roaksoax> bigjools: yeah
[03:39] <roaksoax> bigjools: one with ipmi
[03:39] <bigjools> at least if it's not reproducible it's a little less urgent
[03:39] <roaksoax> smoser: do we have anything available?
[03:57] <roaksoax> bigjools: do we have somewhere to reproduce this?
[03:57] <bigjools> roaksoax: qa lab?
[03:57] <bigjools> garage maas?
[03:57] <roaksoax> bigjools: garage maas is a no
[04:00] <roaksoax> bigjools: i have an idea
[04:00] <roaksoax> will try to reproduce locally faking ipmi discovery
[04:05] <bigjools> roaksoax: we need an SRU for python-tx-tftp (0.1~bzr31-0ubuntu8)
[04:05] <bigjools> for precise
[04:05] <roaksoax> bigjools: cloud archive
[04:05] <bigjools> is it in there already?
[04:05] <roaksoax> should be yes
[04:05] <bigjools> and is this the excuse for not doing SRUs now? :)
[04:06] <roaksoax> bigjools: not, but the reason of the cloud-archive is we want to avoid the headaches of sru's right?
[04:07] <bigjools> I thought it was to get around changes that were not SRUable
[04:07] <bigjools> that said, I don't know if that tftp one is or not
[04:08] <roaksoax> bigjools: probably
[04:08] <roaksoax> well let's think about it post release
[04:12] <bigjools> yeah, better time :)
[04:26] <kurt_> bigjools: why can't maas-cli support multiple value pairs for tags? i.e. maas-cli maas tag nodes cntrlr-node, quantum-node OR cntrl-node quantum-node etc.
[04:27] <roaksoax> bigjools: reproduced locally
[04:27] <roaksoax> bigjools: so how can I see logs again?
[04:27] <bigjools> roaksoax: good, yet bad :(
[04:27] <bigjools> roaksoax: edit the maas-signal function to log the request
[04:30] <roaksoax> bigjools:  payload = geturl(url, creds=creds, headers=headers, data=data) >
[04:30] <roaksoax> ?
[04:30] <bigjools> kurt_: because it wasn't implemented that way I guess
[04:30] <kurt_> doesn't it make sense to do that?
[04:30] <bigjools> roaksoax: hang on
[04:30] <bigjools> kurt_: probably, but it is what it is
[04:31] <kurt_> too much to ask for an enhancement?
[04:31] <bigjools> feel free to file a bug
[04:31] <kurt_> ok dokey
[04:31] <bigjools> not sure if/when it would get looked at
[04:31] <bigjools> but the source is open.... ;)
[04:31] <kurt_> i'm almost certain there are bigger fish
[04:31] <kurt_> :)
[04:32] <bigjools> I can agree there
[04:33] <kurt_> about your question about how to detect VMWare, I was going to respond in email.  But since you are here…how is kvm detected?
[04:33] <roaksoax> bigjools: i think we could log where we receive the mparticular request
[04:34] <roaksoax> on the metadata server side
[04:34] <bigjools> roaksoax: I am making you a patch
[04:34] <roaksoax> ok
[04:34] <kurt_> bigjools: never mind.  I just added info to the bug.
[04:36] <bigjools> roaksoax: untested, but: http://pastebin.com/zVdmRAPD
[04:41] <roaksoax> bigjools: nothing logged :/
[04:41] <bigjools> !
[04:41] <bigjools> restarted apache?
[04:41] <roaksoax> did that
[04:41] <roaksoax> restarting machine
[04:41] <bigjools> wtf
[04:52] <bigjools> roaksoax: https://bugs.launchpad.net/maas/+bug/1232154
[04:52] <bigjools> something is screwed
[04:52] <bigjools> try using print() instead of logger
[04:52] <roaksoax> yeah is saw a few MP's related to loggers
[04:54] <roaksoax> bigjools: ok so tomorrow i'll confirm this bug is in trunk without the moonshot stuff
[04:54] <roaksoax> bigjools: but this really shouldn't be affected by mnoonshot
[04:54] <roaksoax> bigjools: lp:~andreserl/maas/moonshot_enablement
[04:54] <bigjools> yeah
[04:54] <bigjools> I agree
[04:55] <bigjools> roaksoax: having said that, the daily tests in the QA lab would have been blowing up
[04:56] <roaksoax> bigjools: yeah/ I'm wondering if it is because enlistment works, then commissioning for some reason keeps the same credentials
[04:56] <roaksoax> i'll debug this tomorrow though
[04:59] <bigjools> roaksoax: it's possible that is exactly what is happening
[04:59] <bigjools> a bug was fixed where something was getting overwritten unnecessarily IIRC
[04:59] <roaksoax> maybe that's related
[04:59] <roaksoax> we'll see
[05:04] <roaksoax> bigjools: so it seems the mparameters are not being passed
[05:04] <roaksoax>     raise MAASAPIBadRequest("power_type %s, power_params %s" % (power_type, power_parameters))
[05:04] <roaksoax> MAASAPIBadRequest: power_type ipmi, power_params None
[05:05] <bigjools> roaksoax: where is that code?
[05:06] <roaksoax> bigjools: api.py
[05:06] <roaksoax> store_node_xyz
[05:06] <roaksoax> maasserver/api.py
[05:06] <roaksoax> store_node_power_parameters
[05:06] <bigjools> so maas-signal is broken?
[05:07] <roaksoax> bigjools: maybe! i'll debug this tomorrow against the latest trunk (without my enablement branch)
[05:08] <bigjools> ok
[05:09] <roaksoax> bigjools: ok
[05:09] <roaksoax> i know what the issue is
[05:09]  * roaksoax is blind
[05:09] <roaksoax> roaksoax: params["power_parameters"] = json.dumps(power_parms)
[05:09] <roaksoax> that's what was missing :(
[05:09] <bigjools> roaksoax: missing where?
[05:09] <roaksoax> bigjools: in my enablement branch :)
[05:09] <bigjools> roaksoax: lol
[05:09] <bigjools> sorry for laughing :)
[05:10] <bigjools> roaksoax: TESTS!
[05:10] <roaksoax> bigjools: yeah I haven't gotten to that part yet
[05:10] <bigjools> can you see why we are anal about tests? :)
[05:12] <roaksoax> bigjools: lol
[05:12] <roaksoax> bigjools: anyway, sorry for the noise
[05:12]  * roaksoax bed
[05:12] <bigjools> roaksoax: sleep well!
[05:12] <roaksoax> 2 more months till vacation
[05:12] <roaksoax> yaaaaaaaay
[05:14] <bigjools> :)
[10:30] <mgz> how does the maas api versioning work?
[10:30] <mgz> bug 1236734 mentiones that ip_addresses doesn't exist in the raring maas, can I not check that based on maas version somehow?
[10:34] <bbcmicrocomputer> be great if someone could take a look at bug 1236786
[10:34] <bbcmicrocomputer> it breaks the install CD currently
[10:47] <rvba> roaksoax: hi, could you please have a look at bug 1236786?
[13:19] <roaksoax> rvba: there's really no information for me to figure out what's wrong on that bug, I'd need logs
[13:20] <roaksoax> smoser: bug #1236786
[13:20] <roaksoax> bbcmicrocomputer: ^^
[13:21] <rvba> roaksoax: thanks for looking into it.
[13:58] <roaksoax> smoser: ok so the fix for the apache2 thing works in saucy
[13:58] <roaksoax> i have not tested packaging
[13:58] <roaksoax> in precise
[13:58] <roaksoax> but saucy works
[14:14] <roaksoax> rvba: around?
[14:15] <rvba> roaksoax: yes
[14:15] <roaksoax> rvba: so any updates on the maas-import-ephemerals stuff?
[14:16] <rvba> roaksoax: well, yes; making progress but it's not yet done.  Julian wanted Jeroen to make a few changes to the migration stuff…  sorry I can't be more precise than that.
[14:17] <roaksoax> rvba: so there's no way we will have something for today ig uess then?
[14:17] <rvba> roaksoax: no, not today.  Hopefully tomorrow.
[14:17] <roaksoax> rvba: alright.. tomorrow is really our last day to upload stuff
[14:17] <roaksoax> smoser: ^^
[14:46] <bbcmicrocomputer> roaksoax: added syslog with debug mode to bug 1236786
[14:51] <roaksoax> bbcmicrocomputer: what's the workaround you had?
[14:53] <bbcmicrocomputer> roaksoax: I was mounting securityfs on /target/sys/kernel/security, then installing, but in the preseed/late_command option
[14:53] <bbcmicrocomputer> roaksoax: although you can't use that here
[14:53] <roaksoax> bbcmicrocomputer: right cause judging from the logs... it doesn't really tell me what's failing exactly
[14:54] <roaksoax> bbcmicrocomputer: can you try this though?
[14:54] <roaksoax> bbcmicrocomputer: http://paste.ubuntu.com/6209648/
[14:55] <roaksoax> bbcmicrocomputer: that should probably deal with it
[14:55] <roaksoax> since invoke-rc.d is denied execution (which is expected) maybe that's causing the failure
[14:55] <bbcmicrocomputer> yeah it's not obvious, 'Warning: unable to find a suitable fs in /proc/mounts, is it mounted?' comes from apparmor_parser inside maas-dhcp postinst I believe
[14:55] <bbcmicrocomputer> which returns exit status of 1
[14:56] <roaksoax> bbcmicrocomputer: righ
[14:56] <bbcmicrocomputer> then we would just run preseed/late_command as 'in-target sh -c \"mount -t securityfs none /sys/kernel/security; apt-get -y install maas-dhcp"'
[14:57] <bbcmicrocomputer> and that would work
[14:57] <roaksoax> bbcmicrocomputer: right, so have you looked at any other package that can be installed during the installed that uses apparmor_parser?
[14:58] <bbcmicrocomputer> roaksoax: nope
[14:58] <roaksoax> bbcmicrocomputer: because i'm pretty sure there are other packages that are installed during the installer that install an apparmor profiel
[14:58] <roaksoax> so i don't think that would be a cause of issues
[14:58] <bbcmicrocomputer> ok
[14:59] <roaksoax> bbcmicrocomputer: let me see what's happening in that postinst though
[14:59] <bbcmicrocomputer> ok, thanks
[15:10] <roaksoax> bbcmicrocomputer: taking for ever to download the latest ISO
[15:10] <roaksoax> bbcmicrocomputer: is it possible for you to quickly edit the postinst script
[15:10] <roaksoax> bbcmicrocomputer: before it gets run and add a set -x ?
[15:10] <roaksoax> so it outputs what's actually doing?
[15:11] <bbcmicrocomputer> roaksoax: sure, I figure something
[15:11] <roaksoax> bbcmicrocomputer: thank you!
[15:34] <roaksoax> bbcmicrocomputer: so I'm pretty sure this would avoid the issue on the cd install: http://paste.ubuntu.com/6209795/
[15:35] <roaksoax> bbcmicrocomputer: but dunno what the effect would be
[15:36] <bbcmicrocomputer> roaksoax: I can try, I'm just collecting the previous output :)
[15:37] <bbcmicrocomputer> roaksoax: the install cycle takes 10 mins on my machine :(
[15:38] <roaksoax> boomer
[15:42] <roaksoax> bbcmicrocomputer: that seems to be the correct fix. bind9 for example does this: debian/bind9.postinst:        apparmor_parser -r "$APP_PROFILE" || true
[15:42] <roaksoax> bbcmicrocomputer: so adding the|| true would allow this to work on CD isntall
[15:44] <bbcmicrocomputer> roaksoax: yep
[15:44] <bbcmicrocomputer> roaksoax: I'll try
[15:44] <roaksoax> just confirmed the theory with jdstrand
[15:44] <roaksoax> so I'll make the fix
[15:45] <bbcmicrocomputer> roaksoax: I've added the output to the ticket
[15:45] <bbcmicrocomputer> debug output, which gives up on that line, yes
[15:49] <roaksoax> bbcmicrocomputer: ok, i just tested it
[15:49] <roaksoax> bbcmicrocomputer: it works
[15:49] <bbcmicrocomputer> roaksoax: cool
[15:54] <bbcmicrocomputer> roaksoax: how long will it take for that fixed package to make it into the archive?
[15:55] <roaksoax> bbcmicrocomputer: tomorrow
[15:55] <roaksoax> bbcmicrocomputer: i'm not gonna upload anything until the final changes to trunk land
[15:55] <bbcmicrocomputer> roaksoax: ok, cool, thanks
[16:09] <stokachu> does maas utilize fast-path installation yet?
[16:09] <stokachu> i see python-curtin
[16:09] <stokachu> but there aren't any preseed template defined for it
[16:15] <stokachu> i see curtin and curtin_userdata should i just extend userdata to contain post_Scripts?
[18:51] <stokachu> has curtin/xinstall been tested with preseed_xinstall+generic?
[18:51] <stokachu> so far its not picking up the preseeds
[19:17] <roaksoax> stokachu: yes it has
[19:18] <stokachu> roaksoax: i see where curtin_userdata has a spot for late_commands
[19:18] <stokachu> but i dont see how preseed_xinstall is coming into play
[19:18] <roaksoax> stokachu: it does, i haven't test it
[19:18] <roaksoax> stokachu: preseed_xinstall is only a "preview"
[19:18] <stokachu> so whats the format of curtin_userdata if i wanted to add multiple commands
[19:19] <roaksoax> stokachu: you'd need to check with smoser :) I haven't got that far just yet
[19:19] <stokachu> roaksoax: http://paste.ubuntu.com/6210689/
[19:19] <stokachu> ok
[19:23] <roaksoax> stokachu: but judging for the pb, i'd say something like: http://pastebin.ubuntu.com/6210707/
[19:24] <stokachu> roaksoax: gotcha trying that now
[19:26] <stokachu> hmm tried something like http://paste.ubuntu.com/6210716/ and it didn't work.. ill just wait for smoser to come back
[19:27] <smoser> stokachu, here.
[19:27] <stokachu> :)
[19:27] <smoser> you rad too far
[19:27] <smoser> preseed_xinstall is not invovled period.
[19:27] <stokachu> that was from the docs on maas.ubuntu.com
[19:27] <stokachu> http://maas.ubuntu.com/docs/development/preseeds.html
[19:28] <smoser> k. docs suck.
[19:28] <stokachu> smoser: so ive been messing with curtin_userdata
[19:28] <stokachu> http://paste.ubuntu.com/6210716/ trying to get late_commands to work
[19:28] <stokachu> fastpath installs and it's definately fast
[19:28] <stokachu> 12 seconds
[19:29] <smoser> right. so curtin_userdata is what you'd modify.
[19:29] <smoser> what do you need to do
[19:29] <stokachu> http://paste.ubuntu.com/6210716/ check that snippet
[19:29] <stokachu> just want to download and run a shells cript in the late command
[19:32] <stokachu> i was using http://bazaar.launchpad.net/~curtin-dev/curtin/trunk/view/head:/doc/topics/overview.rst as a reference
[19:33] <smoser> stokachu, right. thts not unreasonable.
[19:33] <stokachu> smoser: is my config correct with the late_commands?
[19:35] <smoser> stokachu, yeah, its not unreasonable.
[19:35] <smoser> http://paste.ubuntu.com/6210737/
[19:35] <smoser> might work also
[19:36] <stokachu> smoser: nice let me try that
[19:36] <smoser> you're just replacing the builtin "configure network" command
[19:36] <smoser> which is
[19:36] <smoser> 'network_commands': {'builtin': ['curtin', 'net-meta', 'auto']}
[19:36] <smoser> stokachu, are you getting installs ?
[19:37] <smoser> your 12 seconds doesn't seem reasonble.
[19:37] <stokachu> smoser: so it installs and i can ssh to it
[19:37] <stokachu> and i create a file to make sure it is destroyed on new node installs and its gone
[19:37] <smoser> wow.
[19:37] <smoser> well thats fast!
[19:37] <stokachu> the logs indicate that its pulling the curtin images
[19:38] <stokachu> dude its super fast... 25minutes using the old way, 12 seconds using curtin
[19:38] <stokachu> keep in mind this is in a kvm though
[19:38] <smoser> yeah.
[19:38] <stokachu> so bare metal may be different
[19:38] <smoser> and with unsafeio also
[19:38] <stokachu> yea
[19:38] <smoser> still i hadn't seen that fast.
[19:38] <stokachu> :)
[19:39] <stokachu> trying the install now to see if the network gets picked up
[19:39] <smoser> the goal is for when maas knows about networking is for it to do basically what i told you to do there.
[19:40] <stokachu> smoser: http://imgur.com/ytjNstd
[19:40] <smoser> and it didn't land in saucy, but the goal was/is also to have a 'user-install-data' snippet.
[19:40] <smoser> that can be provided to maas.
[19:40] <stokachu> ah ok
[19:40] <smoser> and it goes in as a config to curtin
[19:40] <smoser> so you'd no thave to be able to modify the preseed, and could change your mind on every install.
[19:40] <stokachu> thats awesome
[19:40] <stokachu> the install didn't pick up the vlansetup script i have though :(
[19:41] <smoser> you should configure console output on your vms.
[19:41] <smoser> hm..
[19:42] <smoser> serial console output log to a file
[19:42] <smoser> is what i meant.
[19:42] <stokachu> http://paste.ubuntu.com/6210772/ thats my script
[19:42] <smoser> so you dont have ot deal with crappy vnc for watching
[19:42] <stokachu> smoser: yea i am going to set that up today as well
[19:42] <smoser> oh. well, fwiw, what i gave you above was not to be executed.
[19:42] <smoser> just to be downloaded.
[19:42] <stokachu> ah
[19:43] <smoser> that would be what you have in /etc/network/interfaces
[19:43] <smoser> :)
[19:43] <stokachu> ahh
[19:43] <stokachu> is $OUTPUT_INTERFACES defined or should i change that to /etc/network/interfaces?
[19:44] <smoser> OUTPUT_INTERFACES should be defined by curtin when it executes the command.
[19:44] <stokachu> ok
[19:46] <smoser> to execute, something like:
[19:46] <smoser>  mine: ['sh', '-c', 'wget "$1" -O - | sh', '--', 'http://192.168.122.206/vlansetup']
[19:46] <stokachu> smoser: thanks ill try that
[19:46] <smoser> but you'll have to change your script so that it writes to $OUTPUT_INTERFACES
[19:46] <smoser> or
[19:47] <smoser> yeah, you'll have ot do that reasonably. writing to /target/etc/network/interfaces wont work
[19:47] <smoser> for 2 reasons
[19:47] <smoser> a.) i dont think it will be mounted at target
[19:47] <smoser> b.) the i think it'd get copied over. (or might fail later if there i sno OUTPUT_INTERFACES)
[19:48] <stokachu> ok thats cool, ill mess around with it some more today and see what i can come up with
[19:48] <stokachu> at least this gets me in the right spot for curtin
[19:48] <stokachu> smoser: thanks :)
[19:48] <smoser> no, clearly your devcycle is pretty fast here.
[19:48] <smoser> now.
[19:49] <smoser> but if you want, you can use curtin trunk there is a 'launch' that will boot kvm install to a disk and stop
[19:49] <stokachu> smoser: niceee that would be handy
[19:49] <smoser> but it doesn't reboot yet :)
[19:50] <stokachu> thats ok it would still easier
[19:50] <smoser> see doc/devel/README.txt
[19:50] <smoser> and feel free to add a '--then-boot-it-dummy' flag
[19:51] <roaksoax> smoser: when are we going to have saucy images?
[19:51] <stokachu> cool ill check that out today too
[19:51] <smoser> roaksoax, saucy images ephemeral ?
[19:51] <smoser> they're there.
[19:51] <roaksoax> smoser: released?
[19:52] <roaksoax> smoser: or daily's?
[19:53] <smoser> http://paste.ubuntu.com/6210816/
[19:53] <roaksoax> smoser: cool thanks
[19:53] <roaksoax> smoser: btw... so we need to decide what to do with the moonshot and maas-enlist and ipmitool
[20:08] <stokachu> in my /etc/network/interfaces file after a node start i see ## This file is generated by cloud-initramfs-dyn-netconf
[20:08] <stokachu> could that be overriding my customizations?
[20:20] <lifeless> ooh dynamic network confic
[20:20] <lifeless> smoser: ^ is that new ?
[20:29] <smoser> lifeless, /etc/network/interfaces.d is new in saucy.
[20:29] <smoser> that config there is for 'curtin' which is the "fast path installer" in saucy.
[20:32] <lifeless> https://git.openstack.org/cgit/openstack/diskimage-builder/tree/elements/dhcp-all-interfaces
[20:32] <lifeless> is a related thing we did
[20:33] <smoser> yeah, curtin does that too.
[20:33] <smoser> its kind of garbage though
[20:33] <smoser> as dhcp eth0
[20:33] <smoser> then wait some length of time
[20:33] <smoser> which might be to short
[20:33] <smoser> kinda sucks.
[20:34] <lifeless> yeah
[20:34] <smoser> http://bazaar.launchpad.net/~curtin-dev/curtin/trunk/view/head:/curtin/net/__init__.py
[20:34] <smoser> 'is_connected'  at least is sane.
[20:40] <smoser> stokachu, progress ?
[20:41] <stokachu> smoser: everytime i boot the node it just seems like /etc/network/interfaces is unchanged
[20:41] <stokachu> i changed the script to output a interfaces file
[20:41] <stokachu> and i added a config_hook
[20:41] <smoser> hm..
[20:41] <smoser> i'll play some
[20:41] <stokachu> http://paste.ubuntu.com/6211001/
[20:41] <stokachu> thats what i have so far
[20:42] <stokachu> http://paste.ubuntu.com/6211003/ thats my interfaces file
[20:44] <smoser> hm..
[20:44] <stokachu> am i supposed to copy the /etc/network/interfaces file in the config_hook?
[20:45] <stokachu> docs suggest that unless told so it just keeps the interfaces file in memory
[20:46] <smoser> curtin shoudl copy OUTPUT_INTERFACES to the target /etc/network/interfaces
[20:46] <stokachu> automatically right?
[20:46] <smoser> right.
[20:46] <stokachu> hmmm
[20:47] <stokachu> smoser: could it be and then getting overwritten by cloud-initramfs-dyn-netconf?
[20:49] <smoser> it shouldn't. that only wirtes /run/interfaces
[20:49] <smoser> right?
[20:49] <stokachu> it added the comment in /etc/network/interfaces
[20:56] <smoser> hm..
[20:57] <smoser> actually, no.
[20:57] <smoser> that came from the ephemeral image boot
[20:57] <smoser> and was the copied to OUTPUT_INTERFACES and then copied back in i think.
[20:58] <stokachu> so that would've been earlier in the install right?
[20:58] <smoser> let me see.
[20:59] <smoser> ok.
[20:59] <smoser> so wrt http://paste.ubuntu.com/6211001/
[20:59] <smoser> i'm not sure why netowrk_commands wouldn' twork.
[21:00] <stokachu> ok
[21:00] <smoser> config_hook is wrong if thats what doc says
[21:00] <stokachu> smoser: it wasn't really clear to me how to use it
[21:01] <stokachu> config_hook: {{TARGET_MP}}/opt/curtin/config-hook
[21:01] <stokachu> but then it talks about helpers
[21:01] <stokachu> so wasn't sure the syntax
[21:02] <smoser> yeah, so that probalby just rong
[21:06] <smoser> you should be able to do:
[21:06] <smoser> hook_commands:
[21:07] <smoser>  myhook: [sh, -c, 'something']
[21:07] <smoser> ['curtin in-target echo "8021q" >> /etc/modules']
[21:07] <smoser> is probably wrong though
[21:07] <stokachu> ok, i didnt see any documentation for hook_commands
[21:07] <smoser> htat will try to execute a program called 'curtin in-target echo "8021q" >> /etc/modules'
[21:07] <stokachu> there is final_commands
[21:07] <smoser> stokachu, documentation lags a bit.
[21:07] <stokachu> ok
[21:08] <smoser> final_commands replaced by late_commands.
[21:08] <stokachu> gotcha
[21:15] <smoser> stokachu, i'm sorry that doc is behind.
[21:16] <smoser> i have a system set up and i'll try to figure out a working ocnfig to do what you want.
[21:16] <stokachu> smoser: thats ok, i plan on submitting MP's
[21:16] <stokachu> smoser: i'd appreciate it, ill be hacking away at it in parallel
[21:17] <stokachu> smoser: fwiw i tested the hook_commands and didn't see "8021q" added in /etc/modules
[21:17] <smoser> well, see above.
[21:17] <smoser> it wouldnt work like that.
[21:17] <smoser> it should have failed
[21:18] <smoser> 'curtin in-target echo "8021q" >> /etc/modules'
[21:18] <smoser> not: ['curtin in-target echo "8021q" >> /etc/modules']
[21:18] <stokachu> ok
[21:18] <smoser> the first i think will get invoked under 'sh' as a convenience
[21:18] <smoser> but if the value is an array
[21:18] <smoser> then it will invoke it with execve
[21:19] <smoser> which is going to try to run 'curtin in-target echo....' as a program in the PATH.
[21:19] <smoser> ie, not with sh.
[21:19] <stokachu> ah ok
[21:20] <smoser> stokachu, i'm out for a bit. i'll be back in sometime later.
[21:21] <stokachu> smoser: no worries
[21:21] <stokachu> thanks again