[00:07] <roaksoax> Daviey: stil around?
[00:11]  * roaksoax dinner
[03:12] <robbiew> RoAkSoAx: bingo!...put in the hostname for "User ID" and worked like magic ;)
[08:24] <Daviey> roaksoax: hey
[10:44] <javor> 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)?
[13:10] <roaksoax> Daviey: checking
[13:39] <roaksoax> 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] <rvba> roaksoax: that's great news!
[13:42] <roaksoax> rvba: what's the democeleryconfig.py for?
[13:42] <rvba> roaksoax: the celery config used in dev mode.
[13:43] <rvba> i.e., when running MAAS directly from the tree.
[13:43] <roaksoax> rvba: and is services/celeryd/run also par of dev mode?
[13:43] <rvba> Yes.
[13:43] <roaksoax> ok, just checking before I package something up :)
[13:43] <rvba> That's how we start the services in dev mode, that uses 'supervise'.
[13:44] <roaksoax> 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] <rvba> 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] <rvba> 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] <roaksoax> rvba: yes want to test them, but want to see the output of the rendering
[13:49] <rvba> roaksoax: have a look at the last tests in this file.
[13:49] <rvba> roaksoax: test_virsh_checks_vm_state
[13:50] <roaksoax> rvba: right, but is there no way to actually see how it is being rendered?
[13:51] <roaksoax> rvba: becuase the error messages received are not helpful at all
[13:51] <rvba> roaksoax: action = PowerAction(POWER_TYPE.VIRSH) / script = action.render_template(...)
[13:51] <rvba> roaksoax: ^ isn't what you're looking for?
[13:51] <roaksoax> rvba:that's the same output being placed on the logs, isn't it?
[13:52] <roaksoax> on celery.log when something fails
[13:52] <rvba> I /think/ you see the full stacktrace in celery.log when something fails.
[13:53] <roaksoax> rvba: http://pastebin.ubuntu.com/1086195/
[13:54] <roaksoax> rvba: you see a stack strace but you don't see rendered output or failure
[13:54] <roaksoax> rvba: what I want to see is if the variables have been rendered correctly and things like that
[13:54] <roaksoax> rvba: similar to placing -x on a shell script
[13:55] <roaksoax> either way, the template is shell and we should eb able to see how it gets rendered right?
[13:56] <rvba> 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] <rvba> s/Thee/The/
[13:57] <roaksoax> 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] <roaksoax> rvba: so the command might have failed because it had empty arguments
[13:57] <roaksoax> rvba: thta's what I wanna test
[13:57] <rvba> roaksoax: fair enough.
[13:57] <rvba> roaksoax: http://paste.ubuntu.com/1086199/
[13:57] <rvba> roaksoax: that's the code that generate this error... there is a TODO there :)
[13:58] <roaksoax> yeah
[13:58] <rvba> roaksoax: I could add the generated script in the error log.
[13:58] <roaksoax> rvba: but anyways, regardless of that being in place in tehe code, isn't there a manual way to test it?
[14:00] <rvba> roaksoax: you can manually do this http://paste.ubuntu.com/1086200/ to see the rendered script in the error log
[14:00] <roaksoax> 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] <roaksoax> rvba: cool, Ill try that
[14:01] <rvba> roaksoax: what does "-x" do exactly?
[14:02] <rvba> (I think I asked that question before but I don't remember the answer...)
[14:04] <rvba> roaksoax: maybe I forgot to mention that this is a change to run_shell in ./src/provisioningserver/power/poweraction.py.
[14:04] <rvba> roaksoax: also, in that method, 'subprocess.Popen' is what calls the script, you could probably add "-x" in there.
[14:07] <roaksoax> rvba: ok cool. I'lll look into that
[14:10] <roaksoax> rvba: btw.. does this make sense to you? http://paste.ubuntu.com/1086214/
[14:12] <roaksoax> rvba: since those are UI changes mostly, I just wanna make sure it makes sense
[14:12] <rvba> roaksoax: you're also changing the parameters for ipmi_lan.
[14:13] <roaksoax> rvba: yeah
[14:13] <roaksoax> that's why I said mostly :)
[14:13] <rvba> roaksoax: but yeah, the UI changes make sense.
[14:13] <rvba> roaksoax: I'm trying to find where I took the list of the parameters from.
[14:14] <roaksoax> rvba: from cobbler: /usr/bin/ipmitool -H "$power_address" -U "$power_user" -P "$power_pass" power "$power_mode"
[14:14] <rvba> roaksoax: right, so, did I got it wrong for ipmi_lan ?
[14:14] <roaksoax> rvba: for for ipmilan you simply add -I lan
[14:16] <rvba> roaksoax: anyway, I'll trust you on this one :).
[14:22] <roaksoax> rvba: hehe :)
[14:35] <czajkowski> 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] <roaksoax> czajkowski: what are the questions
[14:36] <czajkowski> 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] <roaksoax> czajkowski: so 1. goes for adam_g
[14:37] <roaksoax> adam_g: http://askubuntu.com/questions/160198/openstack-dashboard-access-after-installing-w-maas
[14:38] <roaksoax> rvba: support for quantal in MAAS is not yet ready right?
[14:38] <rvba> roaksoax: no, right now, precise is hardcoded.
[14:38] <roaksoax> rvba: ok
[14:44] <roaksoax> allenap: I tested the ssh keys with one of the latest maas revs and everything works as expected
[14:45] <roaksoax> 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] <roaksoax> 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] <allenap> roaksoax: I'm not sure that's possible... or I think it should not be. rvba?
[14:51] <roaksoax> allenap: maybe they started the machine when in "Ready" state, without clicking manually on MAAS to start a node maybe?
[14:52] <allenap> roaksoax: Possibly. Cobbler could well be in the right state to just install the machine.
[14:53] <roaksoax> yep
[14:53] <roaksoax> that's what I'm thinking
[14:53] <rvba> allenap: the 'acquire' step makes the node the property of the user requesting a node for deployment.
[14:54] <rvba> So it's not possible for a node to be deployed without having an owner.
[14:57] <czajkowski> roaksoax: THANKS
[14:57] <czajkowski> damn caps sorry.
[14:58] <roaksoax> 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] <roaksoax> rvba: so maybe users were manually turning on nodes before they were manually allocated with "Start Node" on the WebUI
[15:03] <roaksoax> ending with no keys
[15:04] <rvba> roaksoax: that seems possible indeed.  But the node were definitely powered up outside of MAAS control.
[15:04] <rvba> nodes*
[15:04] <allenap> We might be able to address that by ensuring that netboot_enabled is off when the node is in the ready pool.
[15:04] <roaksoax> indeed
[15:05] <allenap> 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] <roaksoax> allenap: that might not be a good idea
[15:07] <roaksoax> you might one to deallocate a machine from the pool
[15:07] <roaksoax> allenap: but keep everything installed for some reason
[15:08] <roaksoax> 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] <roaksoax> allenap: rvba btw.. there's no way to get an allocated node back to the pool from the WebUI right?
[15:09] <allenap> 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] <roaksoax> yeah
[15:11] <roaksoax> 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] <roaksoax> such as "Stop Node"
[15:11] <roaksoax> that powers it off and allocates it back to the pool
[15:12] <allenap> roaksoax: Really? Gulp.
[15:17] <roaksoax> allenap: last I check it was like that
[15:17] <roaksoax> anyway, I'll finish up with releasing a new maas and recheck
[15:22] <allenap> rvba: Do you know if we did any work on node deallocation?
[15:23] <rvba> allenap: I don't think we did.
[15:52] <roaksoax> allenap: there's no config for python-txtftp yet right?
[15:55] <roaksoax> btw there's a broken symlink on trunk, in etc/ named -> ../run/named
[15:56] <rvba> roaksoax: that's normal, ../run/named gets populated when the conf is created.
[15:57] <roaksoax> rvba: ok, but that means shipping a broken link
[15:57] <roaksoax> rvba: that should be clean IMHO
[15:57] <rvba> roaksoax: 'make services/dns/@run' will populate it for instance.
[15:57] <roaksoax> 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] <allenap> roaksoax: Yes, etc/pserv.yaml. It should Just Work for now, though not on the right port I think.
[15:58] <rvba> roaksoax: why do you want to ship it?  I thought you'd ship only so selected files from etc/ ?
[15:58] <rvba> s/so/some/
[15:58] <roaksoax> allenap: right but that's started by pserv, not by twistd tftp :)
[15:58] <roaksoax> rvba: it still in the source
[15:58] <roaksoax> rvba: i ship selected files from binary while it is still in the source
[15:59] <allenap> roaksoax: Yes, don't run twistd tftp :)
[15:59] <roaksoax> allenap: ok then :)
[15:59] <allenap> roaksoax: It's okay for it to be there, just don't arrange for it to start by default or anything.
[15:59] <roaksoax> allenap: so I'll just install it then in PYTHONPATH
[16:00] <allenap> roaksoax: Yeah, that's all we need.
[16:00] <roaksoax> allenap: was wondering to see whether I ship add an upstart job or not
[16:01] <allenap> roaksoax: No, sorry about that. I can sense you were excited at the prospect ;)
[16:01] <rvba> roaksoax: I can create that link when running make indeed.  But why exactly do you think a broken link is that bad?
[16:01] <roaksoax> allenap: hehe i just wanna get it over with :)
[16:02] <roaksoax> rvba: AFAIK it is a bad idea to ship broken links on source tarballs
[16:03] <roaksoax> rvba: i'm fine shipping it, I just think it would be better to have it generated and cleaned on make
[16:06] <rvba> roaksoax: I definitely can do that (but I'd be happy to learn why it's so bad to ship broken links ;) ).
[16:06] <rvba> Apart from the fact that the word 'broken' sounds bad in itself :).
[16:12] <roaksoax> 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] <roaksoax> when setting mtime or mode
[16:12] <rvba> roaksoax: fair enough, I'll do it ;).
[16:13] <rvba> roaksoax: fwiw that link is only there because we wanted to make clear that the config was generated.
[16:14] <rvba> We could have generated the config directly in /etc/named but that would have been confusing.
[16:14] <rvba> err etc/named
[16:14] <roaksoax> rvba: right but you could add a message header saying its generated :)
[16:14] <roaksoax> cause either way, that doesn't show on bzr, does it?
[16:15] <rvba> roaksoax: run/* is ignored by bzr.  The link was committed in bzr.
[16:16] <roaksoax> rvba: right, so you could also ignore etc/named and not commit it
[16:16] <rvba> roaksoax: sure, but that would be a little bit weird.
[16:18] <roaksoax> rvba: might be indeed...  but that file gets created and removed on distclean
[16:18] <roaksoax> so it doesn't really belong to the branch
[16:18] <roaksoax> IMHO
[16:18] <rvba> True, it's just a bit confusing to have it in etc/named.  But I'll consider that.
[16:18] <rvba> I mean I'll consider generating the config in etc/named directly.
[16:19] <roaksoax> rvba: alright! I'm happy with whichever makes your life easier, though shipping the symlink is also weird for me!
[16:19] <roaksoax> rvba: and I'm sure the MIR team would be "WTH is there a broken symlink in the code"
[16:20] <rvba> roaksoax: all right :)
[16:20] <roaksoax> :)
[16:20] <roaksoax> rvba: thanks though!
[17:00] <roaksoax> allenap: there seems to be an error in pserv
[17:00] <roaksoax> after adding the config option for tftp
[17:02] <roaksoax> allenap: yep, pserv doesn't start
[17:03] <allenap> Oh rats.
[17:05] <allenap> roaksoax: Can you grab the logs?
[17:05] <roaksoax> allenap: there's no pserv log
[17:06] <allenap> <surprised smiley>
[17:06] <allenap> roaksoax: Ah, is this with the new python-tx-tftp package?
[17:07] <roaksoax> allenap: yes
[17:07] <roaksoax> allenap: no longer showed in: http://pastebin.ubuntu.com/1086510/
[17:08] <roaksoax> allenap: but the file is installed as twisted pluging
[17:08] <allenap> 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] <roaksoax> allenap: can you give me a patch
[17:08] <allenap> Sure.
[17:09] <allenap> roaksoax: http://paste.ubuntu.com/1086512/
[17:13] <roaksoax> allenap: /usr/bin/twistd: Unknown command: maas-pserv
[17:16] <roaksoax> allenap: is twisted not recognizing maas-pserv installed/present/available when it is installed in the right place
[17:18] <allenap> 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] <roaksoax> allenap: is not
[17:19] <roaksoax> allenap: i patched it in /usr/share/pyshared/tftp/
[17:19] <allenap> roaksoax: Okay, you could try adding a `raise` to the maas-pserv twisted plugin, so that the error is not suppressed.
[17:20] <allenap> 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] <roaksoax> rvba: does provisioning server and stuff add /usr/share/maas as part of the path?
[17:48] <roaksoax> rvba: i'm having a pserv error due to apparently not being able to import
[17:50] <roaksoax> rvba: http://pastebin.ubuntu.com/1086581/