[00:07] Daviey: stil around? [00:11] * roaksoax dinner === wgrant_ is now known as wgrant [03:12] RoAkSoAx: bingo!...put in the hostname for "User ID" and worked like magic ;) [08:24] roaksoax: hey [10:44] Hi. I trying to install MAAS onto Virtualbox. I did everything what i should (i guess) but doing juju bootstrap just show me error 409. Anybody has it installed and its works good (onto virtualbox)? === matsubara is now known as matsubara-afk [13:10] Daviey: checking [13:39] rvba: howdy!! I have the power stuff I just haven't proposed a branch yet as I wanna test it first with real ipmi cards, even though, robbiew confirmed it worked [13:40] roaksoax: that's great news! [13:42] rvba: what's the democeleryconfig.py for? [13:42] roaksoax: the celery config used in dev mode. [13:43] i.e., when running MAAS directly from the tree. [13:43] rvba: and is services/celeryd/run also par of dev mode? [13:43] Yes. [13:43] ok, just checking before I package something up :) [13:43] That's how we start the services in dev mode, that uses 'supervise'. [13:44] rvba: oh btw.. I wanted to ask you, how can I effectively determine/check/test that the templates are being rendered correctly. Where can I see a similar output of passing -x to shell [13:44] roaksoax: it's only interesting for you (as far as packaging is concerned) as an example about how we start the services in a dev environment. [13:48] roaksoax: I assume you want to test the new power templates... then I think you should add tests in there ./src/provisioningserver/power/tests/test_poweraction.py [13:49] rvba: yes want to test them, but want to see the output of the rendering [13:49] roaksoax: have a look at the last tests in this file. [13:49] roaksoax: test_virsh_checks_vm_state [13:50] rvba: right, but is there no way to actually see how it is being rendered? [13:51] rvba: becuase the error messages received are not helpful at all [13:51] roaksoax: action = PowerAction(POWER_TYPE.VIRSH) / script = action.render_template(...) [13:51] roaksoax: ^ isn't what you're looking for? [13:51] rvba:that's the same output being placed on the logs, isn't it? [13:52] on celery.log when something fails [13:52] I /think/ you see the full stacktrace in celery.log when something fails. [13:53] rvba: http://pastebin.ubuntu.com/1086195/ [13:54] rvba: you see a stack strace but you don't see rendered output or failure [13:54] rvba: what I want to see is if the variables have been rendered correctly and things like that [13:54] rvba: similar to placing -x on a shell script [13:55] either way, the template is shell and we should eb able to see how it gets rendered right? [13:56] roaksoax: that error means we had an error running the generated script. Thee rendering went fine, otherwise you would have gotten a perfectly clear error about the missing variable. [13:56] s/Thee/The/ [13:57] rvba: yes, but while the rendering might not have had any errors, I don't know whether the variables ended up with a value, and then passed empty values to the command, which made it fail [13:57] rvba: so the command might have failed because it had empty arguments [13:57] rvba: thta's what I wanna test [13:57] roaksoax: fair enough. [13:57] roaksoax: http://paste.ubuntu.com/1086199/ [13:57] roaksoax: that's the code that generate this error... there is a TODO there :) [13:58] yeah [13:58] roaksoax: I could add the generated script in the error log. [13:58] rvba: but anyways, regardless of that being in place in tehe code, isn't there a manual way to test it? [14:00] roaksoax: you can manually do this http://paste.ubuntu.com/1086200/ to see the rendered script in the error log [14:00] rvba: more than just the rendered script, isn't it possible to see the output of it as if it was passed the "-x" (cause it is a shell script at the end of the day_ [14:01] rvba: cool, Ill try that [14:01] roaksoax: what does "-x" do exactly? [14:02] (I think I asked that question before but I don't remember the answer...) [14:04] roaksoax: maybe I forgot to mention that this is a change to run_shell in ./src/provisioningserver/power/poweraction.py. [14:04] roaksoax: also, in that method, 'subprocess.Popen' is what calls the script, you could probably add "-x" in there. [14:07] rvba: ok cool. I'lll look into that [14:10] rvba: btw.. does this make sense to you? http://paste.ubuntu.com/1086214/ [14:12] rvba: since those are UI changes mostly, I just wanna make sure it makes sense [14:12] roaksoax: you're also changing the parameters for ipmi_lan. [14:13] rvba: yeah [14:13] that's why I said mostly :) [14:13] roaksoax: but yeah, the UI changes make sense. [14:13] roaksoax: I'm trying to find where I took the list of the parameters from. [14:14] rvba: from cobbler: /usr/bin/ipmitool -H "$power_address" -U "$power_user" -P "$power_pass" power "$power_mode" [14:14] roaksoax: right, so, did I got it wrong for ipmi_lan ? [14:14] rvba: for for ipmilan you simply add -I lan [14:16] roaksoax: anyway, I'll trust you on this one :). [14:22] rvba: hehe :) [14:35] Daviey: I have 2 server questions that need to be answered, can you recommend someone on the server team who could help out please? [14:35] czajkowski: what are the questions [14:36] roaksoax: http://askubuntu.com/questions/160198/openstack-dashboard-access-after-installing-w-maas and http://askubuntu.com/questions/157717/can-i-provision-a-maas-node-with-an-arbitrary-install-image [14:37] czajkowski: so 1. goes for adam_g [14:37] adam_g: http://askubuntu.com/questions/160198/openstack-dashboard-access-after-installing-w-maas [14:38] rvba: support for quantal in MAAS is not yet ready right? [14:38] roaksoax: no, right now, precise is hardcoded. [14:38] rvba: ok [14:44] allenap: I tested the ssh keys with one of the latest maas revs and everything works as expected [14:45] allenap: 1. after enlist before commissioning. 2. after clicking on commissioning but before it actually commissions. 3. afgter commissioning, before deploying (After having it allocated to admin) [14:45] allenap: so the issue might be related to the fact that a machine was never allocated to the admin or a user before it was deployed? [14:50] roaksoax: I'm not sure that's possible... or I think it should not be. rvba? [14:51] allenap: maybe they started the machine when in "Ready" state, without clicking manually on MAAS to start a node maybe? [14:52] roaksoax: Possibly. Cobbler could well be in the right state to just install the machine. [14:53] yep [14:53] that's what I'm thinking [14:53] allenap: the 'acquire' step makes the node the property of the user requesting a node for deployment. [14:54] So it's not possible for a node to be deployed without having an owner. [14:57] roaksoax: THANKS [14:57] damn caps sorry. [14:58] rvba: right, but after the node is ready, it has no owner, however if you click on "Start Node" it allocates it to the user [15:03] rvba: so maybe users were manually turning on nodes before they were manually allocated with "Start Node" on the WebUI [15:03] ending with no keys [15:04] roaksoax: that seems possible indeed. But the node were definitely powered up outside of MAAS control. [15:04] nodes* [15:04] We might be able to address that by ensuring that netboot_enabled is off when the node is in the ready pool. [15:04] indeed [15:05] However, even that's not 100%. A node that was once allocated and returned to the pool is not wiped, so turning netboot off just means it'll boot into the previous OS. [15:05] * allenap thinks we *really* ought to wipe machines that are deallocated. [15:07] allenap: that might not be a good idea [15:07] you might one to deallocate a machine from the pool [15:07] allenap: but keep everything installed for some reason [15:08] allenap: either way, from deallocation back to ready, shouldn;t be a problem, cause once is allocated again, you would wipe the intsllation [15:08] allenap: rvba btw.. there's no way to get an allocated node back to the pool from the WebUI right? [15:09] roaksoax: I'm thinking also about data security. It may be a requirement that the disks are wiped, though I guess that's another story. [15:10] yeah [15:11] allenap: so if in the WEbUI i click on "Start Node", I'm only presented with a "Delete" button, right? SO that means there's no way to bring it back to the pool [15:11] such as "Stop Node" [15:11] that powers it off and allocates it back to the pool [15:12] roaksoax: Really? Gulp. [15:17] allenap: last I check it was like that [15:17] anyway, I'll finish up with releasing a new maas and recheck [15:22] rvba: Do you know if we did any work on node deallocation? [15:23] allenap: I don't think we did. [15:52] allenap: there's no config for python-txtftp yet right? [15:55] btw there's a broken symlink on trunk, in etc/ named -> ../run/named [15:56] roaksoax: that's normal, ../run/named gets populated when the conf is created. [15:57] rvba: ok, but that means shipping a broken link [15:57] rvba: that should be clean IMHO [15:57] roaksoax: 'make services/dns/@run' will populate it for instance. [15:57] rvba: right, but that should be created on make rather than shipping a broken link on trunk... you shouldn't be shipping a link on trunk [15:57] roaksoax: Yes, etc/pserv.yaml. It should Just Work for now, though not on the right port I think. [15:58] roaksoax: why do you want to ship it? I thought you'd ship only so selected files from etc/ ? [15:58] s/so/some/ [15:58] allenap: right but that's started by pserv, not by twistd tftp :) [15:58] rvba: it still in the source [15:58] rvba: i ship selected files from binary while it is still in the source [15:59] roaksoax: Yes, don't run twistd tftp :) [15:59] allenap: ok then :) [15:59] roaksoax: It's okay for it to be there, just don't arrange for it to start by default or anything. [15:59] allenap: so I'll just install it then in PYTHONPATH [16:00] roaksoax: Yeah, that's all we need. [16:00] allenap: was wondering to see whether I ship add an upstart job or not === matsubara-afk is now known as matsubara [16:01] roaksoax: No, sorry about that. I can sense you were excited at the prospect ;) [16:01] roaksoax: I can create that link when running make indeed. But why exactly do you think a broken link is that bad? [16:01] allenap: hehe i just wanna get it over with :) [16:02] rvba: AFAIK it is a bad idea to ship broken links on source tarballs [16:03] rvba: i'm fine shipping it, I just think it would be better to have it generated and cleaned on make [16:06] roaksoax: I definitely can do that (but I'd be happy to learn why it's so bad to ship broken links ;) ). [16:06] Apart from the fact that the word 'broken' sounds bad in itself :). [16:12] rvba: IMHO becuase it is prone to failure when it comes to builds. On the other hand, It creates a few issues wth tar I think [16:12] when setting mtime or mode [16:12] roaksoax: fair enough, I'll do it ;). [16:13] roaksoax: fwiw that link is only there because we wanted to make clear that the config was generated. [16:14] We could have generated the config directly in /etc/named but that would have been confusing. [16:14] err etc/named [16:14] rvba: right but you could add a message header saying its generated :) [16:14] cause either way, that doesn't show on bzr, does it? [16:15] roaksoax: run/* is ignored by bzr. The link was committed in bzr. [16:16] rvba: right, so you could also ignore etc/named and not commit it [16:16] roaksoax: sure, but that would be a little bit weird. [16:18] rvba: might be indeed... but that file gets created and removed on distclean [16:18] so it doesn't really belong to the branch [16:18] IMHO [16:18] True, it's just a bit confusing to have it in etc/named. But I'll consider that. [16:18] I mean I'll consider generating the config in etc/named directly. [16:19] rvba: alright! I'm happy with whichever makes your life easier, though shipping the symlink is also weird for me! [16:19] rvba: and I'm sure the MIR team would be "WTH is there a broken symlink in the code" [16:20] roaksoax: all right :) [16:20] :) [16:20] rvba: thanks though! [17:00] allenap: there seems to be an error in pserv [17:00] after adding the config option for tftp [17:02] allenap: yep, pserv doesn't start [17:03] Oh rats. [17:05] roaksoax: Can you grab the logs? [17:05] allenap: there's no pserv log [17:06] [17:06] roaksoax: Ah, is this with the new python-tx-tftp package? [17:07] allenap: yes [17:07] allenap: no longer showed in: http://pastebin.ubuntu.com/1086510/ [17:08] allenap: but the file is installed as twisted pluging [17:08] roaksoax: Okay, I forgot about this. The upstream, shylent, has reviewed most of my recent changes (favourably) but has not pulled them into his branch. I'll prod him about it. [17:08] allenap: can you give me a patch [17:08] Sure. [17:09] roaksoax: http://paste.ubuntu.com/1086512/ [17:13] allenap: /usr/bin/twistd: Unknown command: maas-pserv [17:16] allenap: is twisted not recognizing maas-pserv installed/present/available when it is installed in the right place [17:18] roaksoax: I changed the pserv plugin code so that it wouldn't spew errors when it failed to initialise. It probably can't import something from python-tx-tftp and is breaking. When that patch is in place it /ought/ to work again. [17:18] allenap: is not [17:19] allenap: i patched it in /usr/share/pyshared/tftp/ [17:19] roaksoax: Okay, you could try adding a `raise` to the maas-pserv twisted plugin, so that the error is not suppressed. [17:20] roaksoax: Unfortunately I have to go now :-/ Good luck in the meantime. Email the list if this is still not working at your EOD and we'll (red squad) take a look. [17:48] rvba: does provisioning server and stuff add /usr/share/maas as part of the path? [17:48] rvba: i'm having a pserv error due to apparently not being able to import [17:50] rvba: http://pastebin.ubuntu.com/1086581/