[08:30] <oshoval> Hi, researched bit more about the problem i had, and the status is that the VM does have a password, but since the default cloud.cfg there has a distro config, it will manipulate the password if UserData exists. disabling the user-groups + set-passwords module fix it. we must not touch the passwords, else the login might suffer from race condition in case its in the middle of setting the passwords. assuming what i just said is legit (?)
[08:30] <oshoval> , trying to disable those two modules in an elegant way, using the /etc/cloud/cloud.cfg.d/ or something, if i may ask how to do so ? (trying, didn't managed yet)
[08:40] <meena> oshoval: there should be no trace von
[08:40] <meena> race condition
[08:41] <meena> all the modules are done in the order they are specified in cloud.cfg
[08:41] <meena> the log should be able to tell you what happened when
[09:06] <oshoval> meena: the race is not between the cloud-init and itself, but between the e2e test that tries to console the VM and login, in case the password which already exists, is reconfigured because of those two modules, the test will fail its attempt to login, and a retry is needed, we are trying to eliminate this
[09:08] <oshoval> we cant have a userData that doesn't set the pass, since the cloud.cfg default is setting a password, and we dont want to totally remove the UserData, and to have an elegant and robust method that if we bump fedora would still work, without double config of the password, so far found that disabling those modules is the nicest i think (but not yet an elegant way to disable them)
[09:08]  * meena mumbles something about ssh keys
[09:10] <oshoval> meena: currently we dont use ssh, but console login, so i prefer not to change the login method, in case this is what you mean ;]
[09:14] <meena> ooohh
[09:14] <meena> i can't even imagine how you would e2e test that
[09:17] <oshoval> we have already lots of tests that spin a VM, and then console the VM, and login using fedora:fedora, that password is already there, but since those modules are enabled, sometimes they just cause a race condition which we want to eliminate, i can send u a code example if you are curious
[09:22] <meena> what are you taking as cue to start e2e tests?
[09:23] <meena> i guess most people would use the phone home module for that
[09:25] <oshoval> we just have golang waiting for the machine to spin and then waiting for the console to say "login" by sending \n
[09:27] <meena> i'd use a clear signal, like the phone home module that's run last
[09:34] <oshoval> we are trying to keep it simple at the moment, but we will consider that, thanks
[09:46] <otubo> smoser: blackboxsw not sure I missed any message, but I don't think there's anything left to address on the PR. Is that right? https://github.com/canonical/cloud-init/pull/721
[09:47] <otubo> smoser: blackboxsw any chance to get it menrged anytime soon? Thanks!
[15:21] <smoser> otubo: thanks for y patience
[19:44] <Tahvok> Hey guys! Is it possible to set a uid and gid as user/group in writ_files? I've tried setting owner: 100:100, but it simply threw an error: KeyError: 'getpwnam(): name not found: 100'
[19:44] <Tahvok> I know that the user/group do not exist, I still need to set them manually to the specific uid/gid
[19:56] <Odd_Bloke> Tahvok: Not as the code is currently, no, unfortunately; we treat the given values as names in all cases: https://github.com/canonical/cloud-init/blob/master/cloudinit/util.py#L1345-L1355
[19:58] <Tahvok> Odd_Bloke: ok, thank you! So for now my only option would be to use chown in runcmd?
[20:22] <Odd_Bloke> Tahvok: I believe so, yes.
[20:24] <Tahvok> Odd_Bloke: thanks again!
[20:25] <Odd_Bloke> :)