[01:24] <stokachu> roaksoax: i think i know whats wrong, maas relies on python-curtin
[01:24] <stokachu> but thats no where in the archive
[01:27] <stokachu> smoser, roaksoax: python-curtin only exists in saucy atm
[01:28] <stokachu> i believe thats why the archive is failing
[01:56] <AskUbuntu> region controller does not know whether any boot images have been imported | http://askubuntu.com/q/353426
[01:59] <Byro> hi
[01:59] <Byro> I'm stuck with maas configuration...
[01:59] <Byro> I posted a question on askubuntu
[01:59] <Byro> http://askubuntu.com/questions/353426/region-controller-does-not-know-whether-any-boot-images-have-been-imported
[01:59] <Byro> I'd really appreciate it if somebody could take a look
[02:01] <Byro> anybody around?
[02:18] <dpb1> hi Byro, I ran into something like this recently
[02:18] <dpb1> Byro: the script stalls there forever?
[02:18] <dpb1> how long did you wait?
[02:19] <dpb1> Byro: I hit this issue: https://bugs.launchpad.net/maas/+bug/1212434
[02:23] <jtv> dpb1: we landed a fix for that in the development codebase...  Which packages are you using?  Daily?
[02:23] <jtv> The script really can't stall forever, but the downloads can take a long time.  You can tweak the RELEASES and ARCHES settings to eliminate downloads you don't need.
[02:23] <dpb1> jtv: ya, I'm past the issue, I was just replying to Byro up there.
[02:24] <jtv> Ah OK
[02:24] <dpb1> Byro, see jtv's question ^
[02:24] <jtv> We're just in the process of re-doing those download scripts, especially the one for the commissioning images.
[02:25] <dpb1> jtv: ya, I was reading about that a couple days ago.  makes sense, given maas is useless if they don't work. :)
[02:28]  * jtv ponders people carrying USB sticks around
[02:28] <jtv> Yes, pretty much.  :)
[02:29] <jtv> Now, as far as the maas-import-pxe-files script is concerned, if you're running a reasonably recent version of the package, you could just run the latest upstream version.  No big changes.
[02:30] <jtv> But it calls the maas-import-ephemerals script, which is a wholly different beast and AFAIK will still break if downloads fail.
[02:35] <dpb1> jtv: ya, I had a bug about that oo
[02:35] <dpb1> too
[02:37] <jtv> I need to step out for some time...  But if it's something I can help with, please explain here and I'll get back to it!
[02:37] <jtv> (Or if appropriate of course, just file a Launchpad bug :)
[02:37] <dpb1> jtv: oh, it's the same bug I think.  in the comments. :)
[02:37] <dpb1> jtv: cheers. :)
[07:12] <gnuoy> hi, I have a newly created maas and I'm finding that commissioning is failing most of the time. when a node fails commissioning it never seems to come up on the network and the remote serial connection shows it loading initrd.img for ~1 minute and then reports it failed and prompts to press a key to continue to nothing else. I'd like pass console=ttyS1,38400 to the kernel which I'm hoping will give me more info
[07:12] <gnuoy> how would I go about doing that ?
[07:15] <rvba> Hi gnuoy, right now, you need some manually hackery to do that.  If you find maas' kernel_opts.py file, you could change compose_arch_opts() to return the parameter you want. (Don't forget to 'sudo service apache2 restart' for the modification to take effect.)
[07:15] <gnuoy> rvba, perfect, thank you
[07:15] <rvba> welcome
[07:38] <AskUbuntu> Build And Host my web application on my own private cloud | http://askubuntu.com/q/353508
[09:22] <gnuoy> fwiw turns out my issues was Bug#1155556
[09:42] <tych0> bug 1155556
[13:42] <rvba> roaksoax: Hi Andres.  I'm seeing something weird with the package that is in Saucy right now: when I install the package with other stuff, the installation breaks: see http://paste.ubuntu.com/6192266/
[13:42] <rvba> roaksoax: any idea what might be wrong?
[14:27] <roaksoax> rvba: ill check in a bit
[14:27] <rvba> Thanks.
[15:18] <rvba> roaksoax: also, but it's really not urgent, I'd be happy if you could have a look at the power-related bugs recently filed: https://bugs.launchpad.net/maas/+bugs?field.tag=power
[15:24] <roaksoax> rvba: when did you experience the install issue?
[15:24] <rvba> roaksoax: just now
[15:24] <roaksoax> rvba: 3 of those appeared yesterday
[15:25] <roaksoax> rvba: two of which we cant do anything
[15:25] <roaksoax> rvba: and anotherone is on your side of things
[15:26] <roaksoax> rvba: bug #1234910
[15:26] <roaksoax> rvba: is something I had asked before
[15:26] <roaksoax> and i was told "you cannot update power parameters individually"
[15:26] <rvba> roaksoax: right, I need to look into that… would you mind adding comments on the others and maybe marking them invalid (if we can't do anything).
[15:27] <rvba> roaksoax: that's a bit bizarre, because we can update the power parameters individually; maybe I'm missing something here.
[15:29] <roaksoax> rvba: no, if i have pwoer_user and power_pass set, and then I update power_user to something else, power_pass resets to default, which is ''
[15:29] <roaksoax> rvso you pretty much have to update all the power parameters if you dont want them reset
[15:30] <rvba> roaksoax: I see; well, yes, they basically behave as one piece of information.
[15:30] <roaksoax> exatly
[15:30] <roaksoax> rvba: so if a user changes A on the webui
[15:30] <rvba> roaksoax: but the script manipulating the power parameters can workaround this.
[15:31] <roaksoax> rvba: and then goes to the CLI to change B
[15:31] <roaksoax> then A gets reset
[15:31] <roaksoax> and shouldn't be that way
[15:31] <roaksoax> the particular case here was
[15:31] <roaksoax> machine enlisted, authentication was changed by the user to LAN_@_0
[15:31] <roaksoax> and then on commissioning, since commissioning doesn't touch authentication method nor changes it
[15:31] <roaksoax> it gets reset
[15:32] <roaksoax> because commissioning only updates power_user, power_pass, power_address
[15:32] <roaksoax> hence the power_type (i think is the variable) gets reset
[15:32] <roaksoax> so the correct is to not reset other parameters when updating some
[15:33] <roaksoax> rvba: ok just did a clean maas install without any issues...
[15:34] <rvba> roaksoax: we have two fields: power_type and power_parameters.  They should be independent from one another.  I'll look into this.
[15:34] <rvba> roaksoax: did you install other packages with the same "apt-get install" command?
[15:34] <rvba> That's when the problem happens.
[15:35] <roaksoax> i'll re-try
[15:35] <rvba> roaksoax: try sudo apt-get install -y maas python-nose python-testtools juju python-zmq
[15:37] <rvba> roaksoax: also, I don't understand why installing maas installs maas-dns, it's supposed to be optional IIRC.
[15:38] <roaksoax> rvba: not anymore
[15:38] <roaksoax> rvba: maas-dns and maas-dhcp are now default
[15:38] <rvba> roaksoax: ah ok… I don't have a problem with that but I suspect this change caused the problem I'm seeing.
[15:39] <roaksoax> rvba: uhmmm maybe not cause I had my system and had been upgrading it without any issues
[15:39] <roaksoax> rvba: where were you installing maas from though?
[15:39] <roaksoax> in precise? saucy?
[15:39] <rvba> roaksoax: saucy
[15:39] <rvba> roaksoax: just the version in the archive
[15:43] <roaksoax> rvba: ok testing your command now
[15:43] <roaksoax> stokachu: ping
[15:45] <stokachu> roaksoax: pong
[15:46] <roaksoax> stokachu: so what was your issue installing from the cloud archive again?
[15:46] <roaksoax> rvba: ok, know what the issue is
[15:46] <roaksoax> rvba: maas-dns uses the 'maas' command
[15:46] <stokachu> roaksoax: python-curtin is required and it doesn't exist in the cloud-tools archive
[15:46] <smoser> stokachu, i'm fixing.
[15:46] <roaksoax> stokachu: k thanks
[15:47] <stokachu> smoser: cool thanks
[15:47] <smoser> python-curtin *is* availalbe
[15:47] <smoser> its (source=djorm-ext-pgarray ) python-djorm-ext-pgarray that was not
[15:47] <rvba> roaksoax: I'm wondering why the installation doesn't fail when one installs only maas.
[15:47] <smoser> i had failed to copy from -next to -staging.
[15:47] <smoser> just did that now,
[15:47] <stokachu> ah ok
[15:47] <smoser> and then i'll push through -propsed and -updates
[15:47] <roaksoax> rvba: yeah that's weird
[15:48] <roaksoax> rvba: but anyway, maas-dns cannot be a dependency of maas-region-controller
[15:49] <rvba> roaksoax: Right.
[15:50] <roaksoax> rvba: which causes an issue because there would be no way to install it automatically
[15:51] <roaksoax> and gets unseeded
[15:53] <roaksoax> rvba: btw.. i just noticed that maas-dns depends on maas-dhcp, that's not needed... is it?
[15:53] <rvba> roaksoax: I don't see why we would have such a dependency…
[15:54] <rvba> roaksoax: hum, hang on…
[15:54] <smoser> stokachu, if you want to just get past this...
[15:54] <smoser> grab the binary deb from https://launchpad.net/~ubuntu-cloud-archive-private/+archive/cloud-tools-proposed/+packages
[15:54] <smoser> wait. wrong link
[15:54] <stokachu> smoser: yea thats what i did
[15:54] <smoser> ah. ok.
[15:54] <smoser> form -next is probably bettre.
[15:55] <rvba> roaksoax: if you want the dns stuff to work you have to let maas control the dhcp.  So the dependency actually makes sense.
[15:56] <smoser> stokachu, and thank you for being willing to be a guinea pig. tryin gthis really helps.
[15:56] <stokachu> smoser: not a problem at all :D
[15:57] <roaksoax> rvba: right, but that's why the cluster controller is the one that provides dhcp isn't it?
[15:57] <roaksoax> rvba: so in a multi environment maas, the dhcp server on the region (which is being installed by maas-dns)
[15:58] <roaksoax> does really work
[15:58] <roaksoax> and it is just installed for nothing
[15:58] <rvba> roaksoax: yeah, you're right.
[15:58] <roaksoax> rvba: i think i'd rather leave it as is
[15:59] <roaksoax> rvba: being so late in the cycle
[15:59] <roaksoax> we don't want to break anything
[15:59] <rvba> Sounds sensible.
[16:01] <roaksoax> rvba: i just uploaded maas_1.4+bzr1656+dfsg-0ubuntu2~ppa1 to ppa:maas-maintainers/experimental
[16:01] <roaksoax> rvba: so we can test the multi package install
[16:01] <roaksoax> and see if we experience the same issue
[16:02] <rvba> roaksoax: ok… well, the test will be easy.
[16:02] <roaksoax> indeed
[16:06] <rvba> roaksoax: arg, the package in the archive takes precedence… is there a trick to force your package to be installed?  I know how to specify that a particular version must be used for one package, but if it's more than one package, it becomes tedious.
[16:11] <roaksoax> rvba: that cant be
[16:11] <roaksoax> rvba: the one in ppa has higher version
[16:11] <roaksoax> it might have not been released yet
[16:12] <rvba> roaksoax: you're right, it's not published yet.
[16:12] <roaksoax> rvba: it is built but not released yet
[16:12] <roaksoax> yep
[16:21] <roaksoax> rvba: published now
[16:25] <roaksoax> rvba: so what script will replce import_ephemerals?
[16:25] <roaksoax> i mean what config file?
[16:25] <rvba> gnuoy: As I said on the bug, I found out the feature to add custom kernel params is already there.  Sorry for the confusion, I'm so used to hack things manually that I sometimes forget about the user-facing features ;)
[16:25] <rvba> roaksoax: the pserv config file.
[16:26] <roaksoax> rvba: hold on, the pserv config file will include the config for importing ephemeral images?
[16:26] <rvba> roaksoax: yes
[16:26] <roaksoax> why?
[16:26] <roaksoax> the ephemeral and import-pxe files
[16:26] <roaksoax> should have its own separate config
[16:26] <roaksoax> from the pserv service
[16:26] <rvba> why?
[16:26] <roaksoax> these are scripts
[16:26] <roaksoax> that should be possible to run
[16:26] <roaksoax> byt the user
[16:26] <roaksoax> itself
[16:26] <roaksoax> smoser: ^^
[16:27] <rvba> Having a common config is not a problem for that.
[16:28] <roaksoax> rvba: well, I see things differently but as long as maas-import-ephemerals is not a script limited to a maas daemon and the user *can* run it
[16:29] <roaksoax> then pserv.yaml could be used as a config source
[16:29] <rvba> That's the plan.
[16:29] <rvba> (Note that we're still working on it)
[16:29] <roaksoax> but given that it is a "external" script, it should have its own config
[16:30] <rvba> roaksoax: hum, it makes sense… I'll talk to jtv (who is doing this work) about it, see what he thinks.
[16:30] <rvba> roaksoax: your package installed correctly
[16:30] <rvba> roaksoax: I'm calling it a day.  See you next week.
[16:30] <roaksoax> rvba: so AFAIK, is it is place din pserv.yaml, in order for the script to actually catch the config, wouldn't we have to restart maas-pserv all the time too?
[16:30] <roaksoax> because AFAIK the config gets loaded on pserv, and maas-import-ephemerals would obtain the config from there
[16:30] <rvba> roaksoax: well, no.
[16:31] <roaksoax> so if we change the config, then we would need to restart pserv
[16:31] <roaksoax> rvba: alrigh! thanks for testing!
[16:31] <rvba> I don't think so, the script is still run "as a script".
[16:31] <rvba> But I'll check.
[16:31] <rvba> Like I said, this is still WIP.
[16:32] <roaksoax> rvba: ok! thanks!
[16:32] <roaksoax> let's catch up on monday then
[16:32] <rvba> Okay.
[16:37] <smoser> roaksoax, i agree that the user should be able to run theset things
[17:01] <smoser> stokachu, 'apt-get install maas' should work on proposed or updates now
[17:01] <smoser> (i just tested)
[17:12] <roaksoax> smoser: i did a new upload to archive that is sitting waiting for approval
[17:12] <roaksoax> it is just a packaging change though
[17:22] <smoser> rvba, roaksoax so does the import-ephemerals run regularly ?
[17:22] <smoser> it really needs to. same with import-pxe-files
[17:25] <roaksoax> smoser: it should
[17:25] <smoser> and can we boot saucy now ?
[17:26] <smoser> cause thats also moderately important :)
[17:34] <smoser> roaksoax, did you fix http://paste.ubuntu.com/6193171/
[17:34] <smoser> ?
[17:35] <smoser> is that what your upload fixed?
[17:44] <stokachu> smoser: ok ill test it now
[17:44] <stokachu> thanks for the quick response
[17:45] <roaksoax> let me see
[17:45] <roaksoax> smoser: yeah that's the one i fixed
[17:45] <smoser> stokachu, see above. it wont work :)
[17:45] <smoser> but a couple more poushes. and we might get ther.e
[17:46] <stokachu> ah lol ok cool
[17:46] <stokachu> ive got a few ansible playbooks setup so i can switch between saucy and precise
[17:59]  * roaksoax lunch
[18:26] <stokachu> smoser, roaksoax: also lxc in the cloud-tools archive wont work unless running the lts-raring hardware enablement kernel i believe
[18:26] <stokachu> not by default anyway unless there is a way to disable namespaces in lxc config
[18:26]  * stokachu hasn't checked
[18:26] <smoser> stokachu, what do you mean "work" ?
[18:27] <smoser> current lxc works fine on precise.
[18:27] <stokachu> lxc version 1.0?
[18:28] <stokachu> from a default install of lxc from cloud-tools archive it won't start a container
[18:28] <stokachu> spawns errors like 'get_cgroup" failed
[18:56] <ppetraki> hey, how do I grab the power_parameters for a given node from the CLI?
[18:57] <ppetraki> I'm trying to back up  a maas
[18:57] <ppetraki> also, https://code.launchpad.net/~peter-petrakis/maas/maas/+merge/189407
[18:58] <stokachu> ppetraki: maas-cli maas nodes -h
[18:58] <stokachu> should give you an idea of what you can pull from it
[18:59] <stokachu> ppetraki: http://maas.ubuntu.com/docs/maascli.html#node
[19:01] <ppetraki> stokachu, yeah, tried that: maas-cli maas node  read node-eccf979e-2d23-11e3-9b02-525400052fb9 power_parameters_power_id
[19:01] <ppetraki> u'power_parameters_power_id' is not a name=value pair
[19:01] <stokachu> read only takes system_id
[19:04] <ppetraki> right, it doesn't return enough information: http://pastebin.ubuntu.com/6193532/
[19:04] <stokachu> what does power_parameters_power_id refer too
[19:04] <stokachu> the virsh stuff?
[19:04] <ppetraki> in this case it's for virsh
[19:05] <ppetraki> but I'm really targeting this towards ipmi
[19:05] <ppetraki> should still work though
[19:05] <stokachu> ppetraki: they dont show user/pass there either
[19:05] <stokachu> i wonder if the id is under the same umbrella
[19:05] <ppetraki> that would suck
[19:05] <stokachu> let me look at the source and see if there are any comments
[19:06] <ppetraki> we show it in plain text in the gui, the cli is authenticated, but I can't get the same level of data back
[19:06] <ppetraki> thanks
[19:06] <stokachu> ppetraki: yea could just be an oversight
[19:07] <stokachu> ppetraki: probably should file a bug to have the api expose that
[19:07] <ppetraki> stokachu, ok, will do
[19:07] <ppetraki> I'll try and hack my existing instances to expose those fields so I can back it all up
[19:31] <ppetraki> stokachu, https://bugs.launchpad.net/maas/+bug/1235421
[19:32] <stokachu> ppetraki: thanks
[19:58] <Nik_> Hi. I'm having an issue with maas tags trying to identify machines that have more than 4 disks.. not sure if anytone is available who can help?
[19:59] <Nik_> "definition": "count(//node[starts-with(@id,\"disk\") and @class=\"disk\"]) >= 4"
[19:59] <Nik_> xmlstarlet sel -T -t -v 'count(//node[starts-with(@id,"disk") and @class="disk"]) >= 4' /tmp/lshw.xml
[20:00] <Nik_> utput is "true"
[20:00] <Nik_> but node doesn't get tagged
[20:00] <Nik_> some do, but not that particular one
[21:24] <AskUbuntu> Maas out of sync with lshw | http://askubuntu.com/q/353814