[15:23] <roaksoax> jtv:
[15:23] <roaksoax> jtv: ping
[15:24] <jtv> Hi roaksoax
[15:24] <roaksoax> jtv: howdy!! is the MAAS_CONFIG_DIR only for the provisioningserver?
[15:25] <jtv> No, it's meant for all of MAAS.
[15:25] <jtv> Got a use for it?  :)
[15:26] <roaksoax> jtv: well I think that's kind of non desired
[15:26] <roaksoax> jtv: each service/daemon should have its own variable to find its config
[15:28] <jtv> Note that this isn't what we talked about with custom templates.
[15:28] <jtv> It helps, but it's more of a first step.
[15:28] <roaksoax> jtv: yes I understand! However, I do still believe that each service should be able to find its config on its own
[15:29] <jtv> If we move something from the source tree to /etc, then that introduces the very basic problem of how to find the right one when we're running from branch.
[15:29] <roaksoax> jtv: if you implement thjis, this now means that you will have to deprecate celery_common
[15:29] <jtv> Why that?
[15:31] <roaksoax> jtv: no nevermind about that, but yo will have to make the MAAS_CONFIG_DIR a common variuable for the cluster and the region
[15:31] <roaksoax> jtv: it would have to work the same way it works with celerycommon_config.py
[15:32] <roaksoax> isn't that adding more complexity than required?
[15:32] <jtv> In normal test/demo usage where you run from a single branch, it would be a single variable yes.
[15:32] <roaksoax> jtv: yes, but MAAS in real world will not run in one single node, would it?
[15:32] <jtv> The celery config works slightly differently.  It makes a distinction between a production-or-test run vs. a demo run.
[15:32] <jtv> In the real world you don't run MAAS from a branch.  You run it from an installed package.
[15:33] <jtv> That's the case where you _don't_ have MAAS_CONFIG_DIR.
[15:33] <jtv> But when you're running tests or a demo, you _do_ want MAAS_CONFIG_DIR.
[15:34] <jtv> If you wanted to run a demo cluster and a demo region with different setups, on the same machine, you would either run them from separate branches, or override MAAS_CONFIG_DIR for one or the other, to point to a different config directory.
[15:34] <jtv> Not sure you'd want that, of course.
[15:35] <roaksoax> jtv: right, so what if you set MAAS_CONFIG_DIR in a system where you instlaled MAAS via package to use /user/share
[15:35] <roaksoax> jtv: then the code will pick that up
[15:35] <roaksoax> jtv: and use that as a config dir
[15:35] <roaksoax> right?
[15:36] <jtv> You could make it pick that up if you wanted to, I suppose, but would you want to?
[15:36] <jtv> If you install a MAAS package, you will simply not have a MAAS_CONFIG_DIR.  If you do set one, that allows you to run one or more of the MAAS processes from a different config.
[15:36] <roaksoax> jtv: ok
[15:37] <roaksoax> i guess what I'm trying to understand is if this is also meant to be used when we package this up
[15:37] <jtv> The main thing here is to provide a uniform way for MAAS code to ask, "where is /etc/maas?" — and get a branch-local version when running from a branch.
[15:37] <jtv> No, it's not meant to be used by a package.
[15:38] <roaksoax> jtv: right, but "/etc/maas" is a packaging convinience
[15:38] <roaksoax> is a safe default
[15:38] <jtv> Yes, that remains unchanged.
[15:38] <jtv> It's normally only when running from a branch, instead of from a packaged install, that you'll want MAAS_CONFIG_DIR.
[15:39] <jtv> So it creates a kind of "lightweight chroot" effect for (1) tests, and (2) demos.
[15:39] <jtv> The problem with using the celery config for this was that it throws tests and production into one kind of config, and demos into another.  Not the right fit.
[15:40] <roaksoax> jtv: right, but what I mean is that currently we run the pserv by passing it the --config-file option that tells where to load the pserv.yaml right?
[15:40] <jtv> It's optional, I think.
[15:40] <roaksoax> no
[15:40] <roaksoax> that's how the daemon is run
[15:40] <roaksoax> and that's how it should be run
[15:41] <roaksoax> daemons should allow you to tell them where the configuration is and if not sent, then it would look for a sane default
[15:41] <jtv> So you're saying it's not looking for a sane default?  That seems wrong.
[15:41] <jtv> And we do in fact have code in there that looks for a sane default, /etc/maas/pserv.yaml.
[15:41] <jtv> Unfortunately it *also* looks for an insane default, ./etc/pserv.yaml.
[15:41] <jtv> That's for branch runs.
[15:42] <jtv> With MAAS_CONFIG_DIR, that will simplify to: if an explicit file was selected, use that.  Otherwise, look for $MAAS_CONFIG_DIR/pserv.yaml.
[15:42] <roaksoax> jtv: ok so MAAS_CONFIG_DIR is only for branch runs and not when you actually *install* and run maas?
[15:42] <jtv> Exactly.
[15:42] <roaksoax> jtv: ok, so as long as nothing else changes, then I'm fine with that
[15:42] <jtv> Good, because I think the code already landed.  :)
[15:43] <roaksoax> because I also read that this is the basis for dropping POWER_{CONFIG,TEMPLATE}_DIR
[15:44] <jtv> Eventually, yes.  Not exactly dropping it, I think, because that'd break compatibility.  But the important point is that templates by  default would live in $MAAS_CONFIG_DIR/templates.
[15:44] <jtv> If we don't have $MAAS_CONFIG_DIR, then we'd have to make that "if we're running from a branch, use <branch>/etc/maas/templates.  Otherwise, use /etc/maas/templates."
[15:45] <roaksoax> right
[15:45] <jtv> So this change allows us to say: the default location for templates is $MAAS_CONFIG_DIR/templates.  Once we have that, we can allow people to customize that location.
[15:46] <roaksoax> right
[15:46] <jtv> And then if we do that, you can move the entire template directory (and softlink the parts that you don't want to change, I guess) and _then_ there should be no more need for those fine-grained configuration items.
[15:46] <jtv> So yes, this is the basis, but it's not a simple direct step.  :)
[15:46] <roaksoax> jtv: ok so as far as the templates then
[15:47] <roaksoax> jtv: this means that MAAS_CONFIG_DIR/templates would also work in production environments and not only when running from a branch right?
[15:47] <jtv> Right — and in a production environment it would be /etc/maas/templates, whereas in a branch it would be <branch>/etc/maas/templates.
[15:48] <roaksoax> right
[15:48] <roaksoax> which means that in a production environment
[15:48] <roaksoax> we still have to set MAAS_CONFIG_DIR
[15:49] <jtv> You don't have to  set it in a production environment — unless you're trying to run MAAS with a different config directory.  But as discussed we'd rather do that for just the templates.
[15:49] <roaksoax> exactly
[15:49] <roaksoax> that's my point
[15:49] <roaksoax> my point is that by default MAAS_CONFIG_DIR will default to /etc/maas and will make all of the daemons/services to look for their configs in MAAS_CONFIG_DIR
[15:50] <roaksoax> this means that MAAS_CONFIG_DIR is a common variable for both the cluster and the region
[15:50] <jtv> Yes, that won't change.
[15:50] <jtv> Right now it's hard-coded.  You're not meant to customize it in production, although you could if you wanted to.
[15:50] <roaksoax> jtv: right, that's my point
[15:51] <jtv> So, no worries then?  Great!
[15:51] <roaksoax> jtv: regardless that MAAS_CONFIG_DIR is set to /etc/maas, then a daemon/service should be allowed to specify *where* is config file is located
[15:51] <jtv> Yes, separate issue.
[15:51] <jtv> You're currently keeping me from realizing that dream.  :)
[15:54] <jtv> Okay, not fair — what I mean is, there's more groundwork to be laid so that we can move templates to /etc, and there's more design work to be done to satisfy various people's requirements.  And I'm eagerly implementing the groundwork right now.
[15:54] <roaksoax> jtv: ok, well to keep it simply, i'm just concerned that implementing this will affect allowing each service/dameon specify where its config are located
[15:55] <jtv> If you really wanted to tweak  this per daemon, then just pass each daemon a different value for the variable.  It's an environment variable, not a configuration item.  But it's not really meant for that — it's an implementation detail, if you will.
[15:55] <roaksoax> ok
[16:36] <AskUbuntu> Maas enlist nodes with pxe timeout | http://askubuntu.com/q/302479
[17:59] <kumquat> hi all, when cloud-init runs its final userdata on a VM node, i'm getting the "error inserting ipmi_si: no such device" fatal exit after installing freeipmi-tools and trying to set up.
[17:59] <kumquat> any help would be appreciated, since the node is hanging on commissioning and keeps sending messages to nodegroups/register
[18:03] <roaksoax> kumquat: do your nodes have ipmi cards?
[18:05] <kumquat> ah, no. the fatal error also didn't impact the bootup - after a while the node registers itself successfully anyway.
[18:05] <roaksoax> kumquat: yeah
[18:39] <roaksoax> rvba: still around by any chance?
[20:50] <jtv> smoser: still here?
[22:17]  * smoser missed jtv