[08:29] can cloud-init help deploy ubuntu .ovas to standalone esxi servers? [10:00] 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] otubo: github can't really do that [10:51] meh :( [11:05] I'm gonna change the commit message, smoser you can squash it all together if you want. [13:44] 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] (We've talked about ways of changing that, but none of them are imminent, unfortunately.) [13:56] 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] 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] and i have to push the button again. [13:57] smoser, in our branch settings we have enabled a setting to ensure branches are up to date before merging [13:58] its just human intensive [13:59] i machine can certainly do that. [14:00] that's a good point...we *could* relax that somewhat [14:01] 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] right, I believe the original reason we enabled this requirement was after tests were broken between merges [14:04] its kind of surprising though.. github is really , *really* good. [14:04] why is there no "land this if tests pass" [14:04] with a serial queue of buttom presses [14:06] there's a github app for that [14:06] i think thats apple's ad campaign, not github. [14:07] Odd_Bloke: I understand, will plan better for the next one. [14:07] smoser: thanks for merging so quick [14:10] 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] i'm in the mood to complain (which isn't anything new). [14:11] hirsute is way to close to hisuite, which is Huawei's phone manager application. [14:11] having known the name 'hisuite', hirsute is really hard to type [14:11] 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] smoser: I hope hisuite is implemented in (JVM language) Groovy. [14:12] (I've definitely had at least one friend jokingly complain that we've wrecked their searches for their Groovy work. :p) [14:14] smoser: I hope PR# 630 is now okay for you ;-) [14:17] thx! [14:22] AscII: since you're here. i just comented there. [14:22] if you weren't here, i'd have landed it. [14:25] fixed === cpaelzer__ is now known as cpaelzer [15:04] otubo: will talk about this review today, was bogged down in interviewing yesterday. [15:15] blackboxsw: you mean, about having separate commits on the same PR? Or about the review itself? Because it's already merged :) [16:22] 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] otubo: last i heard, an SRU was *imminent* === ijohnson is now known as ijohnson|lunch [18:40] i cannot seem to be able to mock __enter__ [18:41] are beginner-level questions welcome here? [18:41] jms1: we cater to the full spectrum. [18:45] 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] 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] 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] jms1: so, what's the problem? [19:07] the machine is created with the "cloudinit-epel" repo, but not the "cloudinit-docker-ce" repo [19:09] 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] aaah, yeah, that is true and makes sense. [19:18] 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] 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] https://bugs.launchpad.net/cloud-init/+bug/1532234 [19:27] Ubuntu bug 1532234 in cloud-init "Merging with data in /etc/cloud/cloud.cfg does not work as expected" [High,Confirmed] === MAbeeTT_ is now known as MAbeeTT === ijohnson|lunch is now known as ijohnson [20:41] 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] 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 === masterdonx2 is now known as MasterdonX