| diadatp | Is it possible to install i386 versions of packages via the packages: config key? I using Ubuntu 20.04 and have tried specifying the primary archive mirror with both amd64 and i386 architectures. The logs state that the apt command failed as it was unable to locate the package. | 09:51 |
|---|---|---|
| diadatp | I've resorted to using `dpkg --add-architecture i386 apt ...` in the runcmd section. | 09:51 |
| eggbean | I have the locale module failing for en_GB. I think it is because it is executing before the packages module attempts to install locales-all. How do I make it do that before the locale module runs? | 14:18 |
| eggbean | None of the packages are installing. | 14:18 |
| minimal | eggbean: I believe that is governed by the ordering of the modules listed in /etc/cloud/cloud.cfg | 14:24 |
| eggbean | minimal: Right, but I can't change that can I? | 14:25 |
| eggbean | How are you supposed to change locales? | 14:25 |
| minimal | looking on a VM here, I see "locale" defined in the cloud_config_modules section and "package-update-upgrade-install" defined in the cloud_final_modules section | 14:27 |
| minimal | you could edit that fi eif you are building your own OS images | 14:27 |
| minimal | I guess the assumption is that the base OS has the locale files present | 14:28 |
| minimal | alternatively you could use a "run_cmd" to setup the locales after the package install has run | 14:28 |
| minimal | which Linux (or other OS) distro are you using? | 14:29 |
| === meena1 is now known as meena | ||
| eggbean | Debian | 14:36 |
| eggbean | minimal: If this is the case, the locale module is pretty useless then? | 14:37 |
| eggbean | This is not exactly some obscure edge case | 14:38 |
| minimal | eggbean: so it seems you have 3 options, (1) Ask Debian to add the locales to their cloud image, (2) modify the Debian image yourself to add the locale package, or (3) use "run_cmd" instead to configure the locales | 14:38 |
| minimal | eggbean: the locale module is not useless if the locale files are present - I suggest you ask the Debian Cloud Team why the locales package is not pre-installed. I make my own VM/Cloud images for Alpine Linux and specifically ensure that Alpine's locale package is preinstalled in the image for this very reason | 14:39 |
| eggbean | I suppose 3 then. I was actually doing that intially, having converted my previous userdata bootstrap script to run_cmd commands, but trying to migrate that to cloud-init modules has led to all sorts of problems | 14:40 |
| minimal | perhaps the Debian Cloud team have never tested setting the locale via the cloud-init module? That would seem unlikely however | 14:41 |
| eggbean | I'll just use run_cmd for now. cheers | 14:43 |
| === gschanuel27 is now known as gschanuel2 | ||
| holmanb | @blackboxsw: I addressed the nits in https://github.com/canonical/cloud-init/pull/1101 - Assuming travis passes this last (minor) change I don't plan on any more changes. | 20:33 |
| blackboxsw | @holmanb should have this reviewed within the hour | 20:41 |
| blackboxsw | thanks! | 20:41 |
| blackboxsw | man, I really want to get onto some flag-day typing and mypy work with cloud-init. | 20:42 |
| blackboxsw | Something to do over Christmas break :) | 20:42 |
| holmanb | Indeed :) | 20:42 |
| blackboxsw | holmanb: on first blush cloudinit.config.schema.get_jsonschema_validator docstring doesn't match return type | 20:45 |
| holmanb | looking | 20:45 |
| blackboxsw | not sure the intent of the Non in the 3-tuple returned | 20:45 |
| blackboxsw | not sure the intent of the None in the 3-tuple returned | 20:45 |
| holmanb | Ah, I remember (though I'm not sure it's the best reason in retrospect) | 20:49 |
| holmanb | that's what validate_cloudconfig_metaschema() returns - it makes the return types match | 20:51 |
| holmanb | which really isn't necessary, but allows the tuple assignment in cloudinit/config/schema.py:157 | 20:52 |
| blackboxsw | thanks holmanb I'm grappling with why we are conflating the actual validation of metaschema with the the get_jsonschema_validator call in that initial try. I think I might suggest one more changeset, so, probably will wait until tomorrow for this :/ | 21:16 |
| blackboxsw | holmanb: also, if we invoke: validate_cloudconfig_schema(strict_metaschema=True) doesn't the cloudinitValidator we return of validate_cloudconfig_metaschema have the META_SCHEMA["additionalProperties"] = False set so that all subsequent validation becomes strict a non-permissive of additionalProperties? | 21:19 |
| holmanb | It can wait, no rush. | 21:21 |
| holmanb | @blackboxsw - yes, that's the potential future use case - strict meta datavalidation. That isn't currently used | 21:22 |
| holmanb | - yes, that's the potential future use case - strict metadata validation at runtime. That isn't currently used but I plummed through the flag in case we decide we want to turn it on in the future. | 21:23 |
| holmanb | can't type today I guess | 21:24 |
| blackboxsw | ahh " Return strict Validator and FormatChecker for use in validation" | 21:24 |
| blackboxsw | my position was that metaschema itself would be strict if validating, but module schema would be permissive | 21:25 |
| blackboxsw | event if we happen to also be validating metaschema. | 21:25 |
| blackboxsw | But, this pespective can wait until we actually attempt to validate metaschema at runtime, if at all. | 21:26 |
| holmanb | @blackboxsw: That makes sense. You make a good point; I wrote it that way to reuse the Validator and FormatChecker produced by validate_cloudconfig_metaschema() rather than a duplicate call to get_jsonschema_validator(), but doing that makes it less obvious what is happening there. | 21:33 |
| blackboxsw | holmanb: no worries , I'm trying to write up the opinion on this and we can sort tomorrow if the suggestion makes sense or not. it feels like we've added a complexity in function return values and different error handling to reuse that one schema validator. And I think even if validate_meta is True, we probably should retain the original META_SCHEMA["additionalProperties"] definition was even when we return from | 21:36 |
| blackboxsw | validate_cloudconfig_metaschema. | 21:36 |
| blackboxsw | we might be able to still call get_jsonschema_validator once before validate_cloudconfig_metaschema and pass the validator into validate_cloudconfig_metaschema | 21:37 |
| blackboxsw | then we don't have to have the implicit indirection | 21:37 |
| holmanb | I like the simplicity of that. | 21:38 |
| blackboxsw | and we'd also avoid trying to shoe-horn common 3-tuple return values into validate_cloudconfig_metaschema | 21:38 |
| blackboxsw | +1 will try to form a solid suggestion on that front and see if that holds water | 21:39 |
| holmanb | sounds good, thanks | 21:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!