=== ubot5` is now known as ubot5 === matsubara is now known as matsubara-lunch === matsubara-lunch is now known as matsubara === kentb-out is now known as kentb [15:23] jtv: [15:23] jtv: ping [15:24] Hi roaksoax [15:24] jtv: howdy!! is the MAAS_CONFIG_DIR only for the provisioningserver? [15:25] No, it's meant for all of MAAS. [15:25] Got a use for it? :) [15:26] jtv: well I think that's kind of non desired [15:26] jtv: each service/daemon should have its own variable to find its config [15:28] Note that this isn't what we talked about with custom templates. [15:28] It helps, but it's more of a first step. [15:28] jtv: yes I understand! However, I do still believe that each service should be able to find its config on its own [15:29] 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] jtv: if you implement thjis, this now means that you will have to deprecate celery_common [15:29] Why that? [15:31] 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] jtv: it would have to work the same way it works with celerycommon_config.py [15:32] isn't that adding more complexity than required? [15:32] In normal test/demo usage where you run from a single branch, it would be a single variable yes. [15:32] jtv: yes, but MAAS in real world will not run in one single node, would it? [15:32] The celery config works slightly differently. It makes a distinction between a production-or-test run vs. a demo run. [15:32] In the real world you don't run MAAS from a branch. You run it from an installed package. [15:33] That's the case where you _don't_ have MAAS_CONFIG_DIR. [15:33] But when you're running tests or a demo, you _do_ want MAAS_CONFIG_DIR. [15:34] 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] Not sure you'd want that, of course. [15:35] 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] jtv: then the code will pick that up [15:35] jtv: and use that as a config dir [15:35] right? [15:36] You could make it pick that up if you wanted to, I suppose, but would you want to? [15:36] 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] jtv: ok [15:37] i guess what I'm trying to understand is if this is also meant to be used when we package this up [15:37] 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] No, it's not meant to be used by a package. [15:38] jtv: right, but "/etc/maas" is a packaging convinience [15:38] is a safe default [15:38] Yes, that remains unchanged. [15:38] It's normally only when running from a branch, instead of from a packaged install, that you'll want MAAS_CONFIG_DIR. [15:39] So it creates a kind of "lightweight chroot" effect for (1) tests, and (2) demos. [15:39] 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] 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] It's optional, I think. [15:40] no [15:40] that's how the daemon is run [15:40] and that's how it should be run [15:41] 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] So you're saying it's not looking for a sane default? That seems wrong. [15:41] And we do in fact have code in there that looks for a sane default, /etc/maas/pserv.yaml. [15:41] Unfortunately it *also* looks for an insane default, ./etc/pserv.yaml. [15:41] That's for branch runs. [15:42] 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] jtv: ok so MAAS_CONFIG_DIR is only for branch runs and not when you actually *install* and run maas? [15:42] Exactly. [15:42] jtv: ok, so as long as nothing else changes, then I'm fine with that [15:42] Good, because I think the code already landed. :) [15:43] because I also read that this is the basis for dropping POWER_{CONFIG,TEMPLATE}_DIR [15:44] 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] If we don't have $MAAS_CONFIG_DIR, then we'd have to make that "if we're running from a branch, use /etc/maas/templates. Otherwise, use /etc/maas/templates." [15:45] right [15:45] 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] right [15:46] 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] So yes, this is the basis, but it's not a simple direct step. :) [15:46] jtv: ok so as far as the templates then [15:47] 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] Right — and in a production environment it would be /etc/maas/templates, whereas in a branch it would be /etc/maas/templates. [15:48] right [15:48] which means that in a production environment [15:48] we still have to set MAAS_CONFIG_DIR [15:49] 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] exactly [15:49] that's my point [15:49] 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] this means that MAAS_CONFIG_DIR is a common variable for both the cluster and the region [15:50] Yes, that won't change. [15:50] Right now it's hard-coded. You're not meant to customize it in production, although you could if you wanted to. [15:50] jtv: right, that's my point [15:51] So, no worries then? Great! [15:51] 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] Yes, separate issue. [15:51] You're currently keeping me from realizing that dream. :) [15:54] 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] 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] 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] ok [16:36] Maas enlist nodes with pxe timeout | http://askubuntu.com/q/302479 [17:59] 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] any help would be appreciated, since the node is hanging on commissioning and keeps sending messages to nodegroups/register [18:03] kumquat: do your nodes have ipmi cards? [18:05] ah, no. the fatal error also didn't impact the bootup - after a while the node registers itself successfully anyway. [18:05] kumquat: yeah [18:39] rvba: still around by any chance? [20:50] smoser: still here? === kentb is now known as kentb-out [22:17] * smoser missed jtv