[03:52] <roaksoax> bigjools: hey!
[03:52] <bigjools> o/ roaksoax
[03:52] <roaksoax> bigjools: so it is in my lsit to separate the the ipmi code into its own script
[03:52] <bigjools> \o/
[03:52] <roaksoax> bigjools: but since it needs to be used in both enlistment/commissioning, we need a way to make it available in both cases
[03:53] <roaksoax> bigjools: which it seems that the easier way is to provide a maas-utils package
[03:53] <roaksoax> that installs it
[03:53] <bigjools> built from the maas source package?
[03:53] <roaksoax> yep
[03:53] <roaksoax> bigjools: i would also move the stuff from maas-enlist into that
[03:53] <bigjools> is there any point doing that though, can't it just live in the cluster controller package?
[03:54] <roaksoax> bigjools: no
[03:54] <roaksoax> bigjools: how would you installit during vcommissioning/enlistment to be used?
[03:54] <bigjools> oh sorry of course, it runs on the node
[03:55] <bigjools> I'd rather keep this out of packages otherwise it locks core functionality into Ubuntu
[03:56] <roaksoax> bigjools: why would it?
[03:56] <bigjools> I still think templates are the way to go - and I'd be tempted to move maas-enlist too
[03:56] <bigjools> because the node is required to install a package so it can program the bmc
[03:57] <roaksoax> bigjools: i wanna put both maas-enlist & maas-ipmi-detect on a single place that can be re-used
[03:57] <bigjools> I agree with that
[03:57] <bigjools> I'm just not sure a package is the right place
[03:57] <roaksoax> bigjools: well these are helper tools
[03:57] <roaksoax> bigjools: either we source them somehow by both commissioning/enlistment preseeds
[03:57] <bigjools> I'd say enlistment is more than a helper :)
[03:58] <roaksoax> bigjools: the thing is thatat least maas-enlist can be used externally
[03:58] <bigjools> I was thinking that we'd factor them into a single script that can be tested in its own right, and then pull that into the preseed template
[03:58] <roaksoax> bigjools: and I would like to do the same with maas-ipmi-autodetect
[03:58] <bigjools> or via metadata
[03:59] <roaksoax> i guess we can do that, *but* i would still like to use them separately
[03:59] <roaksoax> maas-enlist allows to remotely enlist a node
[03:59] <bigjools> I have no objection to packaging them - but I do to making that the exclusive method for the node to get the code
[03:59] <bigjools> seems like we agree :)
[03:59] <roaksoax> and maas-ipmi-autodetect allows to configure them without having them in maas, but returns the credentials needed for maas, that can be sent with maas-enlist for example
[04:00] <bigjools> right
[04:00] <roaksoax> bigjools: ok, sounds good to me then, covering both escenarios is good
[04:00] <bigjools> excellent!
[04:00] <roaksoax> alright! i'm off
[04:00] <roaksoax> have a good day :)
[04:00] <bigjools> roaksoax: thanks - if you need help, just holler
[04:01] <roaksoax> will do
[13:48] <rvba> roaksoax: Hi Andres.  Sorry to bother you again with that problem but I really think there is a problem with the saucy daily package (the one in ppa:maas-maintainers/dailybuilds).  I tried installing it on a recent saucy instance on canonistack and I'm still not getting these services started.  Could you give me a hand with that?
[13:49] <rvba> roaksoax: as you can see from the difference between the package (built from the same upstream and the same packaging branch) on precise and saucy, the services are not started on saucy but are fine on precise: http://paste.ubuntu.com/5692883/
[13:49] <rvba> roaksoax: http://paste.ubuntu.com/5693704/ / http://paste.ubuntu.com/5693706/
[13:50] <roaksoax> rvba i already looked and it is not the maas package
[13:50] <rvba> roaksoax: oh?  What is it then?
[13:50] <roaksoax> these are things that changed in Ubuntu related to how the init system is being handled
[13:50] <roaksoax> so I'm looking into it
[13:51] <rvba> Ah ok.  Thanks a lot.
[13:52] <roaksoax> rvba: btw in you're backport announcement please clarify
[13:52] <roaksoax> that there a new depencies thst will be uograded and new ones that are no in the precose archive which may cause other issues
[13:53] <roaksoax> and that you guys are supporting/fixing bugs with any of those
[13:54] <rvba> Well, I think the level of support is yet to be decided, it's just a ppa after all.
[13:54] <roaksoax> rvba: right nut if you are telling users "use the latest with dependencies that are no in precise" you need to support that
[13:55] <rvba> That's definitely not what I said.
[13:55] <roaksoax> because theres bren cases wjere people report bugs in ubuntu
[13:55] <roaksoax> when they are using ppa
[13:55] <roaksoax> and they xould be reporting bugs out of new versions or packages that dont even exist in the release pocket of ubuntu
[13:56] <roaksoax> tbh i would evem reduce that and would xontinue to ship yui in packaging for your backport and use python-txttftp from precise instead of ppa
[13:56] <rvba> I understand.  Right now, the only thing that exist is a daily backport ppa.  Nothing more.  I really don't think it needs clarification about what kind of support we provide for that.
[13:56] <roaksoax> i think it is important to minimize the delta
[13:57] <rvba> Sounds sensible indeed.
[13:57] <roaksoax> in caae we need to backport this to the actual release
[13:57] <rvba> But tbh the yui package is really low risk.
[13:58] <roaksoax> i agree but it os still a new pacakage not in ubuntu precise
[13:58] <roaksoax> at least you need to clarify that in your email
[13:59] <roaksoax> so users are aware how their systema can break
[14:00] <rvba> If we were talking about package in the stable ppa, I would agree.  But this email was about a daily backport ppa, nothing more.  If a user decides to use a random package from a random ppa, there is not much we can do about it.
[14:01] <rvba> But ok, I'll add a comment about the fact that we don't support it officially.
[14:04] <rvba> roaksoax: done
[14:05] <roaksoax> rvba: right, but my point being is that you need to warn your users what are the implications of them testing your "latest" stuff. Becuase you are telling them "hey use our latest stuff, we are making sure this is stable for you to use and we support it... it is backport" and then if something breaks, it would be "well... sorry.... you used a ppa..."
[14:05] <roaksoax> rvba: so imho, users need to be aware of these things
[14:05] <rvba> roaksoax: a *daily* ppa is obviously not something stable.
[14:06] <roaksoax> rvba: right, but you are shipping extra dependencies that *are* "stable"
[14:06] <roaksoax> rvba: that are *not* daily
[14:06] <roaksoax> if you break users they are not gonna be happy and tyhey are going to blame *ubuntu*
[14:07] <roaksoax> rvba: python-tx-tftp *is* in precise so you can also drop it from the PPA
[14:07] <rvba> roaksoax: well, okay
[14:08] <rvba> roaksoax: just checking that precise contains the right version…
[14:08] <roaksoax> rvba: i had similar discussion with Daviey the other day in the fact that changes such as the GenericIpAddressField should have continue to be uspported in MAAS until the next LTS< so if we had to backport or even SRU MAAS again to Precise, we would have no other depndencies to worry about
[14:08] <roaksoax> rvba: it does, has the same patches as what's in raring
[14:08] <roaksoax> different version though
[14:11] <roaksoax> rvba: i think freeipmi-tools is also *not* needed
[14:12] <roaksoax> rvba: i would also suggest you remove juju from there and let users use it from juju
[14:12] <roaksoax> rvba: i would also suggest you remove juju from there and let users use it from juju's ppa
[14:13] <rvba> roaksoax: it's there so we can run the integration tests on that ppa.
[14:13] <rvba> roaksoax: we have all the same packages in the daily (non-backport) ppa btw
[14:14] <rvba> roaksoax: but obviously if some packages can be removed from these ppas (freeipmi-tools/python-tx-tftp) I'll do it.
[14:17] <roaksoax> ok cool
=== kentb-out is now known as kentb
[14:31] <roaksoax> rvba: btw.. were you able to take a look to the celery/100% utilization bug?
[14:31] <rvba> roaksoax: not yet, but one of us will have a look soon.
[14:31] <roaksoax> cool thanks
[14:31] <roaksoax> rvba: this is someone who is deploying in production has experienced
[16:16] <smoser> roaksoax, how do i apply a tag to "all nodes" ?
[16:22] <roaksoax> smoser: there's no way to do that
[16:22] <roaksoax> rvba: ^^
[16:22] <smoser> no?
[16:23] <smoser> i thought you coudl just apply a xpath expression tthat essentiall matched '.'
[16:23] <rvba> smoser: http://bazaar.launchpad.net/~maas-maintainers/maas/qa-lab-tests/view/head:/maas-integration.py#L523
[16:23] <rvba> "definition=true()"
[16:23] <rvba> That should do the trick.
[16:24]  * rvba has to run.
[16:24] <rvba> See you guys tomorrow!
=== matsubara is now known as matsubara-lunch
[16:49] <smoser> roaksoax, bother again
[17:30] <roaksoax> smoser: shoot :)
[17:30] <roaksoax> smoser: (btw.. above i mean, no "easy" way to do that)
[17:31] <smoser> roaksoax, i'm not geting the right command line args to my nodes i dont think
[17:34] <roaksoax> smoser: how so?
=== matsubara-lunch is now known as matsubara
[22:11] <adam_g> roaksoax, is there anythign that would override / rewrite  IPMI credentials i've manually set for a node via web ui
[22:11] <adam_g> ?
[22:16] <roaksoax> adam_g: commissioning would
[22:16] <adam_g> roaksoax, but not provisioning, right?
[22:17] <roaksoax> nope
[22:17] <roaksoax> nothing would on provisioning
[22:18] <adam_g> ok
=== kentb is now known as kentb-out