=== freeflying_away is now known as freeflying [01:24] roaksoax: i think i know whats wrong, maas relies on python-curtin [01:24] but thats no where in the archive [01:27] smoser, roaksoax: python-curtin only exists in saucy atm [01:28] i believe thats why the archive is failing [01:56] region controller does not know whether any boot images have been imported | http://askubuntu.com/q/353426 [01:59] hi [01:59] I'm stuck with maas configuration... [01:59] I posted a question on askubuntu [01:59] http://askubuntu.com/questions/353426/region-controller-does-not-know-whether-any-boot-images-have-been-imported [01:59] I'd really appreciate it if somebody could take a look [02:01] anybody around? [02:18] hi Byro, I ran into something like this recently [02:18] Byro: the script stalls there forever? [02:18] how long did you wait? [02:19] Byro: I hit this issue: https://bugs.launchpad.net/maas/+bug/1212434 [02:19] Ubuntu bug 1212434 in MAAS "maas-import-pxe-files breaks on 404" [Critical,Fix committed] [02:23] dpb1: we landed a fix for that in the development codebase... Which packages are you using? Daily? [02:23] 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] jtv: ya, I'm past the issue, I was just replying to Byro up there. [02:24] Ah OK [02:24] Byro, see jtv's question ^ [02:24] We're just in the process of re-doing those download scripts, especially the one for the commissioning images. [02:25] 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] Yes, pretty much. :) [02:29] 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] But it calls the maas-import-ephemerals script, which is a wholly different beast and AFAIK will still break if downloads fail. [02:35] jtv: ya, I had a bug about that oo [02:35] too [02:37] 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] (Or if appropriate of course, just file a Launchpad bug :) [02:37] jtv: oh, it's the same bug I think. in the comments. :) [02:37] jtv: cheers. :) === CyberJacob|Away is now known as CyberJacob [07:12] 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] how would I go about doing that ? [07:15] 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] rvba, perfect, thank you [07:15] welcome [07:38] Build And Host my web application on my own private cloud | http://askubuntu.com/q/353508 === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying [09:22] fwiw turns out my issues was Bug#1155556 === freeflying is now known as freeflying_away [09:42] bug 1155556 [09:42] bug 1155556 in python-tx-tftp (Ubuntu) "HP ProLiant DL380 G7 tftps kernel, but initrd tracebacks in tftp server. DL380 G6 succeeds." [Undecided,Fix released] https://launchpad.net/bugs/1155556 === freeflying_away is now known as freeflying === freeflying is now known as freeflying_away === matsubara-afk is now known as matsubara === kentb is now known as kentb-afk [13:42] 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] roaksoax: any idea what might be wrong? [14:27] rvba: ill check in a bit [14:27] Thanks. === freeflying_away is now known as freeflying [15:18] 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] rvba: when did you experience the install issue? [15:24] roaksoax: just now [15:24] rvba: 3 of those appeared yesterday [15:25] rvba: two of which we cant do anything [15:25] rvba: and anotherone is on your side of things [15:26] rvba: bug #1234910 [15:26] bug 1234910 in MAAS "maas unsets ipmi protocol when commissioning" [High,Triaged] https://launchpad.net/bugs/1234910 [15:26] rvba: is something I had asked before [15:26] and i was told "you cannot update power parameters individually" [15:26] 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] roaksoax: that's a bit bizarre, because we can update the power parameters individually; maybe I'm missing something here. [15:29] 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] rvso you pretty much have to update all the power parameters if you dont want them reset [15:30] roaksoax: I see; well, yes, they basically behave as one piece of information. [15:30] exatly [15:30] rvba: so if a user changes A on the webui [15:30] roaksoax: but the script manipulating the power parameters can workaround this. [15:31] rvba: and then goes to the CLI to change B [15:31] then A gets reset [15:31] and shouldn't be that way [15:31] the particular case here was [15:31] machine enlisted, authentication was changed by the user to LAN_@_0 [15:31] and then on commissioning, since commissioning doesn't touch authentication method nor changes it [15:31] it gets reset [15:32] because commissioning only updates power_user, power_pass, power_address [15:32] hence the power_type (i think is the variable) gets reset [15:32] so the correct is to not reset other parameters when updating some [15:33] rvba: ok just did a clean maas install without any issues... [15:34] roaksoax: we have two fields: power_type and power_parameters. They should be independent from one another. I'll look into this. [15:34] roaksoax: did you install other packages with the same "apt-get install" command? [15:34] That's when the problem happens. [15:35] i'll re-try [15:35] roaksoax: try sudo apt-get install -y maas python-nose python-testtools juju python-zmq [15:37] roaksoax: also, I don't understand why installing maas installs maas-dns, it's supposed to be optional IIRC. [15:38] rvba: not anymore [15:38] rvba: maas-dns and maas-dhcp are now default [15:38] roaksoax: ah ok… I don't have a problem with that but I suspect this change caused the problem I'm seeing. [15:39] rvba: uhmmm maybe not cause I had my system and had been upgrading it without any issues [15:39] rvba: where were you installing maas from though? [15:39] in precise? saucy? [15:39] roaksoax: saucy [15:39] roaksoax: just the version in the archive [15:43] rvba: ok testing your command now [15:43] stokachu: ping [15:45] roaksoax: pong [15:46] stokachu: so what was your issue installing from the cloud archive again? [15:46] rvba: ok, know what the issue is [15:46] rvba: maas-dns uses the 'maas' command [15:46] roaksoax: python-curtin is required and it doesn't exist in the cloud-tools archive [15:46] stokachu, i'm fixing. [15:46] stokachu: k thanks [15:47] smoser: cool thanks [15:47] python-curtin *is* availalbe [15:47] its (source=djorm-ext-pgarray ) python-djorm-ext-pgarray that was not [15:47] roaksoax: I'm wondering why the installation doesn't fail when one installs only maas. [15:47] i had failed to copy from -next to -staging. [15:47] just did that now, [15:47] ah ok [15:47] and then i'll push through -propsed and -updates [15:47] rvba: yeah that's weird [15:48] rvba: but anyway, maas-dns cannot be a dependency of maas-region-controller [15:49] roaksoax: Right. [15:50] rvba: which causes an issue because there would be no way to install it automatically [15:51] and gets unseeded [15:53] rvba: btw.. i just noticed that maas-dns depends on maas-dhcp, that's not needed... is it? [15:53] roaksoax: I don't see why we would have such a dependency… [15:54] roaksoax: hum, hang on… [15:54] stokachu, if you want to just get past this... [15:54] grab the binary deb from https://launchpad.net/~ubuntu-cloud-archive-private/+archive/cloud-tools-proposed/+packages [15:54] wait. wrong link [15:54] smoser: yea thats what i did [15:54] ah. ok. [15:54] form -next is probably bettre. [15:55] 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] stokachu, and thank you for being willing to be a guinea pig. tryin gthis really helps. [15:56] smoser: not a problem at all :D [15:57] rvba: right, but that's why the cluster controller is the one that provides dhcp isn't it? [15:57] rvba: so in a multi environment maas, the dhcp server on the region (which is being installed by maas-dns) [15:58] does really work [15:58] and it is just installed for nothing [15:58] roaksoax: yeah, you're right. [15:58] rvba: i think i'd rather leave it as is [15:59] rvba: being so late in the cycle [15:59] we don't want to break anything [15:59] Sounds sensible. [16:01] rvba: i just uploaded maas_1.4+bzr1656+dfsg-0ubuntu2~ppa1 to ppa:maas-maintainers/experimental [16:01] rvba: so we can test the multi package install [16:01] and see if we experience the same issue [16:02] roaksoax: ok… well, the test will be easy. [16:02] indeed [16:06] 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] rvba: that cant be [16:11] rvba: the one in ppa has higher version [16:11] it might have not been released yet [16:12] roaksoax: you're right, it's not published yet. [16:12] rvba: it is built but not released yet [16:12] yep [16:21] rvba: published now [16:25] rvba: so what script will replce import_ephemerals? [16:25] i mean what config file? [16:25] 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] roaksoax: the pserv config file. [16:26] rvba: hold on, the pserv config file will include the config for importing ephemeral images? [16:26] roaksoax: yes [16:26] why? [16:26] the ephemeral and import-pxe files [16:26] should have its own separate config [16:26] from the pserv service [16:26] why? [16:26] these are scripts [16:26] that should be possible to run [16:26] byt the user [16:26] itself [16:26] smoser: ^^ [16:27] Having a common config is not a problem for that. [16:28] 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] then pserv.yaml could be used as a config source [16:29] That's the plan. [16:29] (Note that we're still working on it) [16:29] but given that it is a "external" script, it should have its own config [16:30] roaksoax: hum, it makes sense… I'll talk to jtv (who is doing this work) about it, see what he thinks. [16:30] roaksoax: your package installed correctly [16:30] roaksoax: I'm calling it a day. See you next week. [16:30] 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] because AFAIK the config gets loaded on pserv, and maas-import-ephemerals would obtain the config from there [16:30] roaksoax: well, no. [16:31] so if we change the config, then we would need to restart pserv [16:31] rvba: alrigh! thanks for testing! [16:31] I don't think so, the script is still run "as a script". [16:31] But I'll check. [16:31] Like I said, this is still WIP. [16:32] rvba: ok! thanks! [16:32] let's catch up on monday then [16:32] Okay. [16:37] roaksoax, i agree that the user should be able to run theset things [17:01] stokachu, 'apt-get install maas' should work on proposed or updates now [17:01] (i just tested) [17:12] smoser: i did a new upload to archive that is sitting waiting for approval [17:12] it is just a packaging change though [17:22] rvba, roaksoax so does the import-ephemerals run regularly ? [17:22] it really needs to. same with import-pxe-files [17:25] smoser: it should [17:25] and can we boot saucy now ? [17:26] cause thats also moderately important :) [17:34] roaksoax, did you fix http://paste.ubuntu.com/6193171/ [17:34] ? [17:35] is that what your upload fixed? === matsubara is now known as matsubara-lunch [17:44] smoser: ok ill test it now [17:44] thanks for the quick response [17:45] let me see [17:45] smoser: yeah that's the one i fixed [17:45] stokachu, see above. it wont work :) [17:45] but a couple more poushes. and we might get ther.e [17:46] ah lol ok cool [17:46] ive got a few ansible playbooks setup so i can switch between saucy and precise [17:59] * roaksoax lunch === kentb-afk is now known as kentb [18:26] smoser, roaksoax: also lxc in the cloud-tools archive wont work unless running the lts-raring hardware enablement kernel i believe [18:26] not by default anyway unless there is a way to disable namespaces in lxc config [18:26] * stokachu hasn't checked [18:26] stokachu, what do you mean "work" ? [18:27] current lxc works fine on precise. [18:27] lxc version 1.0? [18:28] from a default install of lxc from cloud-tools archive it won't start a container [18:28] spawns errors like 'get_cgroup" failed [18:56] hey, how do I grab the power_parameters for a given node from the CLI? [18:57] I'm trying to back up a maas [18:57] also, https://code.launchpad.net/~peter-petrakis/maas/maas/+merge/189407 [18:58] ppetraki: maas-cli maas nodes -h [18:58] should give you an idea of what you can pull from it [18:59] ppetraki: http://maas.ubuntu.com/docs/maascli.html#node [19:01] stokachu, yeah, tried that: maas-cli maas node read node-eccf979e-2d23-11e3-9b02-525400052fb9 power_parameters_power_id [19:01] u'power_parameters_power_id' is not a name=value pair [19:01] read only takes system_id [19:04] right, it doesn't return enough information: http://pastebin.ubuntu.com/6193532/ [19:04] what does power_parameters_power_id refer too [19:04] the virsh stuff? [19:04] in this case it's for virsh [19:05] but I'm really targeting this towards ipmi [19:05] should still work though [19:05] ppetraki: they dont show user/pass there either [19:05] i wonder if the id is under the same umbrella [19:05] that would suck [19:05] let me look at the source and see if there are any comments [19:06] 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] thanks [19:06] ppetraki: yea could just be an oversight [19:07] ppetraki: probably should file a bug to have the api expose that [19:07] stokachu, ok, will do [19:07] I'll try and hack my existing instances to expose those fields so I can back it all up [19:31] stokachu, https://bugs.launchpad.net/maas/+bug/1235421 [19:31] Ubuntu bug 1235421 in MAAS "power_parameters_* should be returned by nodes resource" [Undecided,New] [19:32] ppetraki: thanks === matsubara-lunch is now known as matsubara [19:58] 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] "definition": "count(//node[starts-with(@id,\"disk\") and @class=\"disk\"]) >= 4" [19:59] xmlstarlet sel -T -t -v 'count(//node[starts-with(@id,"disk") and @class="disk"]) >= 4' /tmp/lshw.xml [20:00] utput is "true" [20:00] but node doesn't get tagged [20:00] some do, but not that particular one === CyberJacob is now known as CyberJacob|Away [21:24] Maas out of sync with lshw | http://askubuntu.com/q/353814 === kentb is now known as kentb-out === freeflying is now known as freeflying_away