| ajd_ | i've got a VM on an openstack-ish setup which is configured using a ConfigDrive, and for some reason cloud-init isn't always detecting said ConfigDrive - any hints where I should start looking to debug this and understand why it can't seem to find it? | 02:29 |
|---|---|---|
| CrummyGummy | Hi. I am dabbling with cloud-init. I need a script run on startup but it doesn't seem to be running. | 10:26 |
| CrummyGummy | I ran the schema command and it said that my cloud.cfg file is valid | 10:27 |
| CrummyGummy | I'm not sure how else to debug this. It's just doing nothing. All I need is that script run so I set my datasource_list to None. | 10:28 |
| CrummyGummy | Can anyone please give me some guidance on how to sort this out? | 10:29 |
| CrummyGummy | I found this answer. It works when running it as the example. No luck with the server actually running it. https://gist.github.com/aw/40623531057636dd858a9bf0f67234e8 | 10:57 |
| falcojr1 | CrummyGummy: can you provide a link to your cloud-config? | 16:06 |
| ens | hi folks. i am looking to do some contributions and was directed towards here to see about coming on as a bug squasher. | 16:22 |
| ens | can anyone give me a few pointers on where i should get started? | 16:22 |
| falcojr1 | ens: We welcome all contributions! You're interested specifically in cloud-init bugs? | 16:25 |
| falcojr1 | if you haven't contributed a PR to the project yet, here's probably a good starting place | 16:25 |
| falcojr1 | https://cloudinit.readthedocs.io/en/latest/topics/hacking.html# | 16:25 |
| falcojr1 | our bugs are on launchpad here: https://bugs.launchpad.net/cloud-init | 16:26 |
| ens | falcojr1: thanks. i am indeed. it seems like a good project to sharpen my cloud/python skills. i have a lot of non-cloud + programming experience in other stuff. | 16:27 |
| ens | so i figure if i roll up my sleeves and do some work with this then i'll learn one way or another. and i have a lot of free time. | 16:28 |
| falcojr1 | sounds good! Let us know if there's anything unclear in the docs | 16:30 |
| ens | i guess the main thing for me at the moment is probably to actually start using the software in order to get acquainted with it before i can realistically consider contributing any patches and such. | 16:44 |
| ens | i'll be reading up on the docs and have an adventure with it soon, but i was just wondering if you had any particular setup or example you thought might be beneficial to follow for educating myself? | 16:45 |
| ens | much appreciated for the help btw | 16:45 |
| blackboxsw | ens: to shamelessly promote a general community effort that hasn't gotten enough attention (and doesn't require a lot of context to start putting up PRs) here's a pointer to a bucket of schema definitions that'd really help us toward our upcoming goals for better cloud-init user-facing errors: https://bugs.launchpad.net/cloud-init/+bugs?field.tag=bitesize | 17:04 |
| blackboxsw | at some point we want json schema definitions in all of our cloud config modules, trying to grab one of those feature bugs related to schema would be an easy get your toe into the water without broader context. Only knowledge you'd need to build would be around https://json-schema.org/understanding-json-schema/UnderstandingJSONSchema.pdf | 17:05 |
| blackboxsw | and mapping that knowledge to allowed configuration options in cloud-init | 17:05 |
| blackboxsw | falcojr1: I'm reviewing the PR adding a deferred write_files module and wondering a couple things https://github.com/canonical/cloud-init/pull/916 | 17:06 |
| ubottu | Pull 916 in canonical/cloud-init "Add module 'write-deferred-files' executed in stage 'final'" [Open] | 17:06 |
| blackboxsw | I'm wondering if we actually want to define that cloud-init would honor both: write_files_deferred: [...] | 17:07 |
| blackboxsw | - and - | 17:07 |
| blackboxsw | write_files: | 17:07 |
| blackboxsw | - path: 1 | 17:07 |
| blackboxsw | deferred: true|false # false default | 17:07 |
| blackboxsw | 17:07 | |
| blackboxsw | I can't decide if we want folks to only use the top-level `write_files`: directive and force per item "defer: true" or just allow a top-level write_files_deferred and just honor the basic write_files schema, but perform those operations all in cloud-init-final. | 17:09 |
| blackboxsw | I'm just generally averse to providing two ways to do the same thing. | 17:10 |
| blackboxsw | by that logic, I also don't want a users: subordinate -files directive as that is far too specific where a generic `write_files_deferred` will do and solve other use cases. | 17:11 |
| blackboxsw | so I guess my proposal is either of these two options: | 17:12 |
| blackboxsw | 1. only surface a new write_files: defer:true option, add a cc_write_files_deferred module which reads `write_files:` config and operates on all `deferred: true` items | 17:13 |
| blackboxsw | OR | 17:13 |
| blackboxsw | 2. add a new `cc_write_files_deferred` module which will have the same schema as cc_write_files.schema with the exception that it only handles a new top-level config directive `write_files_deferred: [....]` | 17:15 |
| blackboxsw | I'll make these comments on the PR too for broader communication | 17:15 |
| ens | blackboxsw: thanks for the advice on where to jump in. i'll read up on what the story is. | 17:42 |
| blackboxsw | excellent, welcome to the party | 17:42 |
| falcojr1 | blackboxsw: right, #1 is my preference there | 17:49 |
| blackboxsw | thanks falcojr1 I just fell on to option too as I felt cc_write_files_deferred honoring a new write_files_deferred: key allowed us to more easily group deferred items without having to add defer: true to each item in a list (if someone is manipulating lots of user-owned files for instance).... But in either case I provided diffs for both solutions to discuss | 18:34 |
| blackboxsw | https://github.com/canonical/cloud-init/pull/916#pullrequestreview-724531404 | 18:34 |
| ubottu | Pull 916 in canonical/cloud-init "Add module 'write-deferred-files' executed in stage 'final'" [Open] | 18:34 |
| blackboxsw | ok onto that gcloud thing | 18:35 |
| falcojr1 | thanks! | 18:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!