| === 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 | ||
| roaksoax | jtv: | 15:23 |
|---|---|---|
| roaksoax | jtv: ping | 15:23 |
| jtv | Hi roaksoax | 15:24 |
| roaksoax | jtv: howdy!! is the MAAS_CONFIG_DIR only for the provisioningserver? | 15:24 |
| jtv | No, it's meant for all of MAAS. | 15:25 |
| jtv | Got a use for it? :) | 15:25 |
| 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:26 |
| 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:28 |
| 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:29 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| roaksoax | because I also read that this is the basis for dropping POWER_{CONFIG,TEMPLATE}_DIR | 15:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| roaksoax | right | 15:48 |
| roaksoax | which means that in a production environment | 15:48 |
| roaksoax | we still have to set MAAS_CONFIG_DIR | 15:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:54 |
| 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 | 15:55 |
| AskUbuntu | Maas enlist nodes with pxe timeout | http://askubuntu.com/q/302479 | 16:36 |
| 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 | 17:59 |
| roaksoax | kumquat: do your nodes have ipmi cards? | 18:03 |
| 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:05 |
| roaksoax | rvba: still around by any chance? | 18:39 |
| jtv | smoser: still here? | 20:50 |
| === kentb is now known as kentb-out | ||
| * smoser missed jtv | 22:17 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!