| lcpfnvcy | how | 10:15 |
|---|---|---|
| lcpfnvcy | *hi | 10:16 |
| lcpfnvcy | need some help | 10:16 |
| lcpfnvcy | I have a cloud-init config file used to create a vm | 10:16 |
| lcpfnvcy | I'm trying to write a file into a /home/user directory | 10:16 |
| lcpfnvcy | but as the owner: user | 10:16 |
| lcpfnvcy | but it keeps being owned by root | 10:16 |
| lcpfnvcy | any ideas why ? | 10:16 |
| lcpfnvcy | this is with the write_file module | 10:16 |
| lcpfnvcy | write_files: | 10:17 |
| lcpfnvcy | - path: /home/user/storage.cfg | 10:17 |
| lcpfnvcy | permissions: '0755' | 10:17 |
| lcpfnvcy | owner: "user:user" | 10:17 |
| lcpfnvcy | 10:17 | |
| lcpfnvcy | it's a simple text file | 10:17 |
| tribaal | lcpfnvcy: I suspect you're hitting https://bugs.launchpad.net/cloud-init/+bug/1486113 | 10:18 |
| ubot5 | Launchpad bug 1486113 in cloud-init "write_files runs before users/groups, renders "owner" useless" [High,Confirmed] | 10:18 |
| lcpfnvcy | ok | 10:18 |
| lcpfnvcy | looks like that is it | 10:19 |
| lcpfnvcy | I can change the ownership via runcmd then ? | 10:19 |
| tribaal | I suspect you could yes - but I'm not sure when runcmd runs relative to the other modules | 10:19 |
| tribaal | maybe somebody else can chime in later (a lot of people on this channel are on American timezones) | 10:20 |
| lcpfnvcy | ah ok | 10:21 |
| lcpfnvcy | runcmd also gives weird user issues | 10:22 |
| lcpfnvcy | but ok I'll wait | 10:22 |
| lcpfnvcy | https://stackoverflow.com/questions/34095839/cloud-init-what-is-the-execution-order-of-cloud-config-directives | 10:34 |
| lcpfnvcy | if this is correct, then the execution order doesn't make sense to me | 10:34 |
| lcpfnvcy | why with runcmd, I still cannot 'chown user directory' | 10:34 |
| Odd_Bloke | lcpfnvcy: I believe runcmd should work; what issues are you seeing using it? | 13:26 |
| lcpfnvcy | Odd_Bloke: I've tried runcmd, with a simple 'chown user directory' but the directy remains root | 13:52 |
| lcpfnvcy | unless my runcmd is wrong | 13:52 |
| lcpfnvcy | but I dont see errors in the log | 13:52 |
| lcpfnvcy | [ chown, lcp, /mnt/blobfusetmp] | 13:53 |
| lcpfnvcy | something like that | 13:53 |
| Odd_Bloke | Does that do what you expect if you run it by hand after boot? | 13:55 |
| lcpfnvcy | Odd_Bloke: yes | 15:08 |
| lcpfnvcy | I can chown the directory login into vm | 15:08 |
| Odd_Bloke | lcpfnvcy: In that case, please file a bug and attach the output of `cloud-init collect-logs` to it. :) | 15:10 |
| lcpfnvcy | ok | 15:12 |
| lcpfnvcy | I'm trying to do this with an azure vm | 15:12 |
| blackboxsw | Odd_Bloke: forgot to ask about cloud-init SRU, did we get all the verification logs we needed | 15:37 |
| blackboxsw | ? | 15:37 |
| Odd_Bloke | blackboxsw: I'm not sure, TBH, I've been focused on other stuff. | 15:37 |
| blackboxsw | np I'll kick it. I think we are all green all the way | 15:38 |
| blackboxsw | yep powersj marked it verfication done yesterday | 15:39 |
| blackboxsw | just needed a bump in#ubuntu-release | 15:39 |
| Odd_Bloke | OK, nice. | 15:39 |
| AnhVoMSFT | blackboxsw rharper has the cloud-init 19.3 SRU been cut yet? | 18:31 |
| chillysurfer | now that AnhVoMSFT mentions it, what determines when we increment the minor or the build component for versioning in cloud-init? | 18:39 |
| blackboxsw | AnhVoMSFT chillysurfer: I checked in on this internally ~3 hours ago. it was approved but hadn't yet been published. The SRU team did get that upload finalized today, so tonight it should be put into new cloud images | 18:40 |
| blackboxsw | chillysurfer: minor is changed with each new upstream cut of cloud-init | 18:40 |
| blackboxsw | we number our versions <year>.<upstream_release_count_for_this_year> | 18:40 |
| blackboxsw | the subrevision number is generated based on the number of commits that landed since the upstream release cut and we only generate that when we release into an ubuntu series as part of an SRU or package upload into the latest development ubuntu release (Eoan). | 18:41 |
| blackboxsw | so 19.2.36 happens to be 36 commits past the 19.2 upstream cut as published into Xenial, Bionic, Disco and Eoan | 18:42 |
| * blackboxsw needs to double check on the subrevision numbering. But, the major and minor is 19 (year), 2 (second upstream release within 2019 [4 per year]) | 18:43 | |
| Odd_Bloke | AnhVoMSFT: We haven't released 19.3 yet; did you mean the 19.2 SRU that Chad is talking about, or something else? | 18:43 |
| blackboxsw | chillysurfer: we are *late* on an upstream release of 19.3, but it is just a line in the sand based on trying to get 4 upstream upstream releases per year, it is not specifically gated on a feature set. | 18:44 |
| Odd_Bloke | We only have major/minor versions upstream, which follow the pattern Chad mentioned. | 18:44 |
| Odd_Bloke | The -36 is Ubuntu-specific. | 18:45 |
| blackboxsw | for context 19.2.36 is the version of cloud-init that we are SRUing (publishing stable release update) into Xenial, Bionic and Disco | 18:45 |
| Odd_Bloke | It's -36, _not_ .36. | 18:46 |
| blackboxsw | :) thx | 18:46 |
| Odd_Bloke | We don't follow semver, so we need to be careful about that. | 18:46 |
| Odd_Bloke | Because 19.2-37 could have one enormous change compared to 19.2-36, for example. | 18:46 |
| blackboxsw | good pt. | 18:47 |
| chillysurfer | but the "37" in this case will be pushed to the ppas right? | 18:49 |
| chillysurfer | or if not, what determines when a version/update is pushed? | 18:49 |
| Odd_Bloke | The daily PPAs get the latest every day. | 18:50 |
| Odd_Bloke | (But note that PPAs are Ubuntu-specific, so that doesn't invalidate my point above. :) | 18:50 |
| chillysurfer | so SRU != upstream release cut? | 18:50 |
| Odd_Bloke | Correct. | 18:50 |
| Odd_Bloke | Well, we will SRU new upstream releases, in general. | 18:51 |
| Odd_Bloke | But we also SRU snapshots of upstream in Ubuntu. | 18:51 |
| chillysurfer | so what is the determining factor to make, for instance, 19.2-37 instead of 19.3-0? | 18:51 |
| Odd_Bloke | There isn't a clear rule about it. | 18:51 |
| chillysurfer | ah ok | 18:52 |
| Odd_Bloke | Because of the nature of cloud-init (which is that it's generally only consumed when integrated into an image by a distributor), having semantic version numbers isn't all that valuable. | 18:53 |
| chillysurfer | last question (hopefully :)), is every SRU pushed to the archives for ubuntu? for instance, 19.2-0 all the way to current is pushed? or are some skipped? e.g. 19.2-15 wasn't pushed to archives? | 19:01 |
| blackboxsw | chillysurfer: sorry I missed that. for Ubuntu, we actually take tip of tree of master and bring that into each SRU. so all commits make it into the SRU. We also have an obligation to existing ubuntu Xenial, Bionic and Disco users to retain original behavior. For example. if a new feature that landed in tip changes a default behavior on Xenial, we end up surfacing a configuration option to retain the original | 20:09 |
| blackboxsw | defaults in Xenial, but allow cloud-init users to make use of that feature by enabling a configuration option to get the 'new' behavior seen on tip. | 20:09 |
| blackboxsw | if we know ahead of time we are changing default cloud-init behavior, we generally surface that #cloud-config configuration option in tip and just alter the config defaults to turn that new feature 'off' on stable Ubuntu releases | 20:11 |
| Odd_Bloke | chillysurfer: I think you're confusing some terminology here. SRU stands for Stable Release Update, and is the process we follow to get newer versions of cloud-init back into already-released versions of Ubuntu. | 20:26 |
| Odd_Bloke | (In general, the software in the Ubuntu Archive does not change after release, to provide stability for its users.) | 20:26 |
| Odd_Bloke | chillysurfer: We only create new packages every so often, generally when there's a specific feature or bug fix that would be valuable to older releases. | 20:29 |
| Odd_Bloke | The latest such packages were based on the 36th commit since the 19.2 tag, so their versions all have the prefix "19.2-36". | 20:29 |
| Odd_Bloke | But you shouldn't expect to see every commit turned into a package in the Ubuntu archive. | 20:30 |
| Odd_Bloke | For example, the version prefixes before 19.2-36 were (working from latest to oldest) 19.2-24, 19.2-21, 19.2-13, 19.2-9, 19.2-5, and 19.2. | 20:31 |
| Odd_Bloke | chillysurfer: Does that make some sense? | 20:32 |
| blackboxsw | thx Odd_Bloke | 20:56 |
| chillysurfer | Odd_Bloke blackboxsw that makes total sense! thank you! | 23:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!