[08:29] <zamba> can cloud-init help deploy ubuntu .ovas to standalone esxi servers?
[10:00] <otubo> smoser: thanks for the review. Just requested some input from blackboxsw and Odd_Bloke on the matter of merging the commits separately. If github allows to handle that I think we're good to merge?
[10:48] <meena> otubo: github can't really do that
[10:51] <otubo> meh :(
[11:05] <otubo> I'm gonna change the commit message, smoser you can squash it all together if you want.
[13:44] <Odd_Bloke> otubo: Our process requires single commits to master for changelog generation etc.; the only way of ensuring that is to squash-and-merge in GitHub, so we can only land one commit per PR.
[13:44] <Odd_Bloke> (We've talked about ways of changing that, but none of them are imminent, unfortunately.)
[13:56] <smoser> the 'update branch' button... is that fallout of "squash-and-merge only" ? its annoying that i have to hit 'update branch', and then wait until it succeeds. i'm pretty sure you dont' always have to do that.
[13:57] <smoser> it makes sense , but that is new to me. and i have to push the button, and then remember to pay attention, because if i've forgotten, then another commit may have gone into master
[13:57] <smoser> and i have to push the button again.
[13:57] <powersj> smoser, in our branch settings we have enabled a setting to ensure branches are up to date before merging
[13:58] <smoser> its just human intensive
[13:59] <smoser> i machine can certainly do that.
[14:00] <falcojr> that's a good point...we *could* relax that somewhat
[14:01] <falcojr> I think by default github allows a merge as long as it merges cleanly, not that the branch has to always be up to date
[14:02] <powersj> right, I believe the original reason we enabled this requirement was after tests were broken between merges
[14:04] <smoser> its kind of surprising though.. github is really , *really* good.
[14:04] <smoser> why is there no "land this if tests pass"
[14:04] <smoser> with a serial queue of buttom presses
[14:06] <falcojr> there's a github app for that
[14:06] <smoser> i think thats apple's ad campaign, not github.
[14:07] <otubo> Odd_Bloke: I understand, will plan better for the next one.
[14:07] <otubo> smoser: thanks for merging so quick
[14:10] <Odd_Bloke> Yeah, the issue is that Travis doesn't re-run tests without new commits being added to the PR: so we can easily break master if there is some non-textual conflict between what is now in master and what was in master when the tests last ran.
[14:10] <smoser> i'm in the mood to complain (which isn't anything new).
[14:11] <smoser> hirsute is way to close to hisuite, which is Huawei's phone manager application.
[14:11] <smoser> having known the name 'hisuite', hirsute is really hard to type
[14:11] <Odd_Bloke> We've talked about using https://bors.tech/ which would solve this for us (because it _does_ rerun tests before landing), but we haven't had the opportunity to dig into it yet.
[14:11] <Odd_Bloke> smoser: I hope hisuite is implemented in (JVM language) Groovy.
[14:12] <Odd_Bloke> (I've definitely had at least one friend jokingly complain that we've wrecked their searches for their Groovy work. :p)
[14:14] <AscII> smoser: I hope PR# 630 is now okay for you ;-)
[14:17] <AscII> thx!
[14:22] <smoser> AscII: since you're here. i just comented there.
[14:22] <smoser> if you weren't here, i'd have landed it.
[14:25] <AscII> fixed
[15:04] <blackboxsw> otubo: will talk about this review today, was bogged down in interviewing yesterday.
[15:15] <otubo> blackboxsw: you mean, about having separate commits on the same PR? Or about the review itself? Because it's already merged :)
[16:22] <otubo> blackboxsw: but something I'd like to ask is if there's any plan for a new release anytime soon. Wanted to do a new rebase for Fedora and would be to have the most recent version.
[16:27] <meena> otubo: last i heard, an SRU was *imminent*
[18:40] <meena> i cannot seem to be able to mock __enter__
[18:41] <jms1> are beginner-level questions welcome here?
[18:41] <meena> jms1: we cater to the full spectrum.
[18:45] <jms1> i'm not clear on how `merge_how` is supposed to work … https://pastebin.com/cqMDKNDv is part of what i'm doing, the machine is created with the epel repo but without the docker-ce repo
[18:47] <jms1> the entire file is actually concatenated from multiple input files by terraform. i've already verified that the `/var/lib/cloud/instances/xxx/user-data.txt` file contains what i intended it to, the pastebin is copied from that file
[19:01] <meena> Odd_Bloke: updated: https://github.com/canonical/cloud-init/pull/635 and added extremely failing tests to https://github.com/canonical/cloud-init/pull/637 i'll need some help with that.
[19:02] <meena> jms1: so, what's the problem?
[19:07] <jms1> the machine is created with the "cloudinit-epel" repo, but not the "cloudinit-docker-ce" repo
[19:09] <jms1> it's like the first `yum_repos` hash is being totally overwritten by the second one, instead of the two being merged together
[19:13] <meena> aaah, yeah, that is true and makes sense.
[19:18] <jms1> that's why i added the `merge_how` hash up top, to make it "merge" dictionaries rather than the second instance totally overwriting the first one. the documentation about the `no_replace` option could be clearer, i'm just trying to make sure i understand how it's _supposed_ to work.
[19:24] <meena> jms1: that documentation ( https://cloudinit.readthedocs.io/en/latest/topics/merging.html )really needs to have an example that's not just a list.
[19:27] <meena> https://bugs.launchpad.net/cloud-init/+bug/1532234
[20:41] <jms1> not what i was hoping for, but at least it's a _known_ issue. i guess i'll move all of the repos into the first "common" file, and all machine types will have all the yum repos, whether they need docker or not. thanks.
[21:04] <blackboxsw> otubo: thanks for the question earlier.  I was under the impression we were trying to get another release in before end of year. I'll touch base tomorrow to confirm and we can send a mail to the mailinglist