lcpfnvcyneed some help10:16
lcpfnvcyI have a cloud-init config file used to create a vm10:16
lcpfnvcyI'm trying to write a file into a /home/user directory10:16
lcpfnvcybut as the owner: user10:16
lcpfnvcybut it keeps being owned by root10:16
lcpfnvcyany ideas why ?10:16
lcpfnvcythis is with the write_file module10:16
lcpfnvcy  - path: /home/user/storage.cfg10:17
lcpfnvcy    permissions: '0755'10:17
lcpfnvcy    owner: "user:user"10:17
lcpfnvcy 10:17
lcpfnvcyit's a simple text file10:17
tribaallcpfnvcy: I suspect you're hitting https://bugs.launchpad.net/cloud-init/+bug/148611310:18
ubot5Launchpad bug 1486113 in cloud-init "write_files runs before users/groups, renders "owner" useless" [High,Confirmed]10:18
lcpfnvcylooks like that is it10:19
lcpfnvcyI can change the ownership via runcmd then ?10:19
tribaalI suspect you could yes - but I'm not sure when runcmd runs relative to the other modules10:19
tribaalmaybe somebody else can chime in later (a lot of people on this channel are on American timezones)10:20
lcpfnvcyah ok10:21
lcpfnvcyruncmd also gives weird user issues10:22
lcpfnvcybut ok I'll wait10:22
lcpfnvcyif this is correct, then the execution order doesn't make sense to me10:34
lcpfnvcywhy with runcmd, I still cannot 'chown user directory'10:34
Odd_Blokelcpfnvcy: I believe runcmd should work; what issues are you seeing using it?13:26
lcpfnvcyOdd_Bloke: I've tried runcmd, with a simple 'chown user directory' but the directy remains root13:52
lcpfnvcyunless my runcmd is wrong13:52
lcpfnvcybut I dont see errors in the log13:52
lcpfnvcy[ chown, lcp, /mnt/blobfusetmp]13:53
lcpfnvcysomething like that13:53
Odd_BlokeDoes that do what you expect if you run it by hand after boot?13:55
lcpfnvcyOdd_Bloke: yes15:08
lcpfnvcyI can chown the directory login into vm15:08
Odd_Blokelcpfnvcy: In that case, please file a bug and attach the output of `cloud-init collect-logs` to it. :)15:10
lcpfnvcyI'm trying to do this with an azure vm15:12
blackboxswOdd_Bloke: forgot to ask about cloud-init SRU, did we get all the verification logs we needed15:37
Odd_Blokeblackboxsw: I'm not sure, TBH, I've been focused on other stuff.15:37
blackboxswnp I'll kick it. I think we are all green all the way15:38
blackboxswyep powersj marked it verfication done yesterday15:39
blackboxswjust needed a bump in#ubuntu-release15:39
Odd_BlokeOK, nice.15:39
AnhVoMSFTblackboxsw rharper has the cloud-init 19.3 SRU been cut yet?18:31
chillysurfernow that AnhVoMSFT mentions it, what determines when we increment the minor or the build component for versioning in cloud-init?18:39
blackboxswAnhVoMSFT 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 images18:40
blackboxswchillysurfer: minor is changed with each new upstream cut of cloud-init18:40
blackboxswwe number our versions <year>.<upstream_release_count_for_this_year>18:40
blackboxswthe 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
blackboxswso 19.2.36 happens to be 36 commits past the 19.2 upstream cut as published into  Xenial, Bionic, Disco and Eoan18: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_BlokeAnhVoMSFT: We haven't released 19.3 yet; did you mean the 19.2 SRU that Chad is talking about, or something else?18:43
blackboxswchillysurfer: 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_BlokeWe only have major/minor versions upstream, which follow the pattern Chad mentioned.18:44
Odd_BlokeThe -36 is Ubuntu-specific.18:45
blackboxswfor context 19.2.36 is the version of cloud-init that we are SRUing (publishing stable release update) into Xenial, Bionic and Disco18:45
Odd_BlokeIt's -36, _not_ .36.18:46
blackboxsw:) thx18:46
Odd_BlokeWe don't follow semver, so we need to be careful about that.18:46
Odd_BlokeBecause 19.2-37 could have one enormous change compared to 19.2-36, for example.18:46
blackboxswgood pt.18:47
chillysurferbut the "37" in this case will be pushed to the ppas right?18:49
chillysurferor if not, what determines when a version/update is pushed?18:49
Odd_BlokeThe 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
chillysurferso SRU != upstream release cut?18:50
Odd_BlokeWell, we will SRU new upstream releases, in general.18:51
Odd_BlokeBut we also SRU snapshots of upstream in Ubuntu.18:51
chillysurferso what is the determining factor to make, for instance, 19.2-37 instead of 19.3-0?18:51
Odd_BlokeThere isn't a clear rule about it.18:51
chillysurferah ok18:52
Odd_BlokeBecause 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
chillysurferlast 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
blackboxswchillysurfer: 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 original20:09
blackboxswdefaults 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
blackboxswif 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 releases20:11
Odd_Blokechillysurfer: 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_Blokechillysurfer: 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_BlokeThe 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_BlokeBut you shouldn't expect to see every commit turned into a package in the Ubuntu archive.20:30
Odd_BlokeFor 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_Blokechillysurfer: Does that make some sense?20:32
blackboxswthx Odd_Bloke20:56
chillysurferOdd_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!