[00:47] <roaksoax> bigjools: o/
[02:46] <bigjools> roaksoax: latest precise package won't install
[02:46] <roaksoax> bigjools: output?
[02:48] <bigjools> roaksoax: http://pastebin.ubuntu.com/1357069/
[02:48] <roaksoax> bigjools: let me fix it
[02:51] <roaksoax> bigjools: oh I know what the problem is :). you should be able to install it using a clean install
[02:51] <roaksoax> i'll add the necessary conflict/replaces
[02:52] <bigjools> yeah ::)
[14:44] <jtv> smoser, are you here?
[14:44] <smoser> jtv, here.
[14:44] <jtv> Hi.  Has anyone asked you yet about ways to get our custom commissioning scripts into cloud-init?
[14:45] <roaksoax> jtv: howdy! hey all the packaging changes you did to change the iscsi stuff from regin to cluster... that also applies to the stabilization branch, right?
[14:45] <jtv> Hi!  Er... I don't think it did, but give me a moment to collect my memories about why.
[14:46] <roaksoax> jtv: that applies to having the images in the cluster-controller rather than region-controller, which is part of the stabilization branch
[14:46] <jtv> Ah.  I may be confusing different jobs there.
[14:47] <smoser> jtv, well, sort of. in denmark i talke da bit with rapheal on how it should be done... i 'd have to think again.
[14:47] <jtv> There are associated changes to the codebase, so it's not just a matter of porting the packaging changes across.
[14:47] <roaksoax> jtv: bug #1068843
[14:48] <smoser> we need to re-wrk the way that stuff is done.
[14:48] <jtv> So it needs a change in cloud-init?
[14:49] <smoser> the rendering for commissioning user-data will basically output a cloud-archive format.
[14:49] <smoser> no changes to cloud-init.
[14:49] <smoser> just to the rendering of the user-data.
[14:50] <smoser> jtv, i'll try to write something readable down at http://pad.daviey.com/custom-commissioning
[14:50]  * jtv loads
[14:50] <smoser> is there a bug for this ?
[14:51] <roaksoax> jtv: https://launchpad.net/maas/+milestone/12.10-stabilization has bug #1068843, which means that all the images should now be on the cluster-controller, right? This means that the tgtd stuff should also be backported to the quantal packaging, right?
[14:51] <roaksoax> (because all the ephemerals will be in the cluster controller side, rather than in the region)
[14:52] <jtv> smoser: I don't think we have a bug for that yet, no.
[14:56] <jtv> roaksoax: yes, that means that the packaging changes should be backported to 1.2.  I was told that there had already been some packaging changes to make the cluster controller depend on tgtd as well.
[14:59] <jtv> smoser: one particular concern was that we wanted to run the custom commissioning scripts from the main commissioning script, so that we can report success using the "signal" call (if appropriate).  We figured that having cloud-init run all the scripts itself probably wasn't going to a perfect fit.
[15:02] <smoser> jtv, right. but some thing syou might not want that.
[15:02] <jtv> eparse
[15:04] <roaksoax> jtv: alright, i'll take care of it
[15:04] <jtv> Thanks.  Losing my laptop really knocked me out of things for a while.
[15:06] <smoser> jtv, right now in existing commissiong script, it is actually not difficult for the user to add something and have it get run, and then maas-signal to post its output back.
[15:07] <smoser> but just because the user needs to send a file down does not mean they necessarily want it executed and its output posted back.
[15:07] <jtv> Right.
[15:07] <smoser> the current script differenciates this by "add_bin" and "add_script". but obviously they might also want to send my_python_library.py down, which would then be used by my_commissioning_script.py
[15:08] <jtv> We're not even talking about supporting that yet, tbh.
[15:08] <jtv> But we do want to be able to report overall success, not just success for each of several scripts.
[15:09] <jtv> And of course failure for custom scripts that bail out without ever getting to the point where they report success.
[15:19] <smoser> jtv, does the stuff there make sense?
[16:01] <jtv> smoser: having trouble figuring out the text tbh
[16:06] <smoser> hmm.
[16:06] <jtv> Most of the text seems to say that cloud-init will run the custom scripts, but then the very last line seems to assume that the maas harness script will do it.  How do the two fit together?
[16:06] <smoser> cloud-init does what you tell it to do.
[16:07] <smoser> maas has to tell it to run the scripts
[16:07] <smoser> it does so by sending a script that executes the other peices.
[16:10] <jtv> That's what we've been wanting, yes.  But I don't see it anywhere in the text, really.  It only says that cloud-init will run files it gets sent.
[16:12] <smoser> i've update dthe last line there, jtv, maybe morem explicit on that now.
[16:15] <jtv> smoser: I guess one of the two prior points is wrong then... one says that cloud-init will run files whose names start with "report-" and the other says that cloud-init will act upon the other files.  But cloud-init in both cases.  I'm guessing that one of those was meant to be the maas harness script instead.
[16:29] <jtv> smoser: sorry, had some trouble there — maybe I shouldn't have upgraded this machine after all.  :)
[16:39] <jtv> Hmm... still can't connect to pad.daviey.com
[16:39] <mgz> daviey appears to be down
[16:53] <Daviey> mgz: i am always down with t
[16:54] <jtv> I like the front page...  just says "Error"
[16:54] <Daviey> jtv: i killed it, do you need it?
[16:54] <jtv> We sort of do, yes.
[16:54] <Daviey> ok, give me 2
[16:55] <mgz> daviey's getting on up
[17:10]  * jtv has to leave now
[17:27] <Daviey> sorry
[17:27] <Daviey> was on a call
[17:29] <Daviey> it's back up
[18:00] <spideyman_> jam: Hi, Do you have a few minutes to discuss the kernel_opt tagging?
[18:01] <mgz> spideyman_: he's probably not on now, as it's late in his timezone, but feel free to bug me instead
[18:01] <jam> spideyman_: so it is technically 5 hours after my EOD, but I'd like to give you help as much as possible
[18:01] <jam> mgz: I was going to poke you, but it is your EOD to, isn't it ? :)
[18:01] <mgz> he *shouldn't* be on... :)
[18:02] <mgz> I owe an hour or so anyway
[18:02] <jam> spideyman_: we essentially appreciate someone actually using the feature, since we want to make sure it is useful
[18:02] <spideyman_> jam: Ah yes..it's very nice, and sorry I didn't realize it was so late
[18:04] <spideyman_> mgz:I sent an email to jam yesterday regarding the issue. If you have some spare time to look at it, I'd appreciate it
[18:04] <jam> spideyman_: timezones being what they are, there really isn't "good" overlap between us.
[18:04] <mgz> spideyman_: I read the main
[18:04] <mgz> *mail
[18:05] <jam> spideyman_: so I think the starting thing is to just find out what is going wrong with your script, because it generally looks right from our end.
[18:05] <jam> So probably we need to have you run it, and figure out what the state is after the script has run.
[18:05] <spideyman_> mgz: ah right. So essentially, I'm not seeing an update in the UI, and the node.tags.values() is empty...yet the tag is created successfully
[18:06] <spideyman_> jam: sure one sec
[18:06] <mgz> so, my one immediate thought was you probably just need to call save()?
[18:06] <jam> spideyman_: can you successfully go to http://.../MAAS/tags/<tag-name> ?
[18:06] <jam> mgz: IME you don't need save for many to many relationships
[18:06] <jam> they get written right away
[18:06] <mgz> in the custom methods we do that already, but when working directly on the model methods, they don't
[18:06] <jam> but maybe you need a save for the new creation?
[18:07] <mgz> right, I think perhaps.
[18:07] <jam> mgz: though I could be wrong about the M2M
[18:07] <jam> save() would certainly be something to try.
[18:07] <spideyman_> jam: running the script now..it will be a sec
[18:08] <jam> Though note that he didn't add a save around the workerNode.tags.add()
[18:09] <mgz> right, the details of the django orm I'm still unclear on, but the top block of code looks a little wrong
[18:10] <mgz> creates 'new_item', then looks it up immediately and puts in 'created_tag', and uses that to add
[18:10] <jam> mgz: the only one I could specifically point to is doing node.tags.create() vs Tag.objects.create(), and using a get() after the create rather than just using the created item.
[18:10] <jam> mgz: right, it seems odd, though not specifically wrong.
[18:10] <mgz> so, seemed like something persistency might be going wrong there
[18:11] <mgz> spideyman_: so, specifically, try the following instead:
[18:12] <mgz> new_tag = Tag.objects.create(name=tag_name, definition="true", kernel_opts=kernel_opts)
[18:12] <mgz> new_tag.save() # may or may not matter
[18:13] <spideyman_> mgz: okay, I give it a shot. I actually need to reboot, as this VM is not responding well
[18:13] <mgz> new_tag.node_set.add(tagged_node)
[18:13] <mgz> and then maybe throw in another save just in case to start with, then if that works, try taking them out again :)
[18:27] <spideyman_> mgz: sorry for the delay...my vm wasn't cooperating.
[18:27] <spideyman_> mgz: https://pastebin.canonical.com/78396/
[18:27] <spideyman_> mgz: I'll paste bin the tag info
[18:28] <spideyman_> mgz: https://pastebin.canonical.com/78397/
[18:29] <spideyman_> mgz: and there's the tag that it created...but it's not attached to the node
[18:29] <mgz> can you pastebin your script too?
[18:29] <spideyman_> mgz: and here's the code I added: https://pastebin.canonical.com/78398/
[18:35] <spideyman_> mgz: the messy but "working" copy is here: lp:~jeffmarcom/+junk/maas-cert if interested.
[18:35] <spideyman_> mgz: you'll find the whole script in question under maascert/control/maas_nodes.py
[18:36] <mgz> spideyman_: so, I'd just flip all that to something like...
[18:36] <mgz> https://pastebin.canonical.com/78401/
[18:37] <mgz> which is the simplest that you can persuade the ORM to do. the other thing to try is to not supply definition= at all.
[18:40] <mgz> hm, the fact the node is your own subclass may also have som bearing
[18:41] <spideyman_> mgz: hmm...still didn't work
[18:42] <spideyman_> mgz: that's true...everything has worked with it so far. I'd hoped that it wouldn't be an issue
[18:45] <spideyman_> mgz: wait...removing the definition worked
[18:46] <mgz> okay, seems that's what you want here anyway, as you're manually assigning the tag to the node
[18:47] <spideyman_> mgz: right...thanks so much!!
[18:48] <mgz> I wonder if the definition was borked because the reasoning is wrong on "true" being a good xpath to match everything, or whether the async nature of populate nodes is somehow messing with your setup
[18:49] <mgz> anyway, I shall now descend, but will stay in this channel under my other alias in case you have any other questions
[20:11] <Pradeep_> on quantal maas after doing "sudo apt-get install maas-dhcp maas-dns" do I need to edit the configurations manually for dhcp
[20:11] <Pradeep_> I remember in Precise it used to be interactive
[20:11] <dannf> hey Pradeep_  - yeah there used to be debconf settings for ip range, etc
[20:12]  * dannf doesn't know how things work in quantl though
[20:13] <Pradeep_> on Precise also there used to be a dnsmaq template file where I can go and edit the configuration
[20:14] <Pradeep_> I was referring to this document http://people.canonical.com/~gavin/docs/lp:maas/install.html#disc-install for installation
[20:47] <Pradeep_> is dhcpd used in Quantal instead of dnsmasq?