[13:04] If I compare http://archive.ubuntu.com/ubuntu/pool/main/c/cloud-init/ to https://launchpad.net/~cloud-init-dev/+archive/ubuntu/proposed, why is the PPA behind proposed? My understanding was that it took some time for the package to make it to proposed, and we also pushed it to the PPA and could use that in the mean time for testing. Am I [13:04] misunderstanding something? [13:17] Hey everyone, I just realized that for xenial, we are dropping the jsonschema requirement from the package. In that case, our schema tests for https://git.launchpad.net/cloud-init/commit/?id=8bcf1c06 are not properly applied, since xenial will not perform any verification on the schema file as can be see here: https://github.com/canonical/cloud-init/blob/4261ae538563d262bc76b8c55f7cc0c8abb14b00/cloudinit/config/schema.py#L90 [13:18] Is that something we are okay with for this release or should we change that behavior on xenial ? === Odd_Bloke changed the topic of #cloud-init to: Migration to travis-ci.com in progress, expect some CI weirdness | pull-requests https://git.io/JeVed | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting June 16 16:15 UTC | 20.1 (Feb 18) | 20.2 (Apr 28) | https://bugs.launchpad.net/cloud-init/+filebug [13:33] powersj: Thanks for the help on Friday! Full disclosure, I'd forgotten I didn't have admin on the new cloud-init repo, which is why you get ping-and-run'd. :p [13:35] falcojr: Hmm, looks to me like we didn't upload the most recent version to the PPA. :/ [13:40] lucasmoura: We are happy for the schema behaviour to not be present on xenial. (We don't introduce new dependencies in stable releases without substantial justification, and xenial released before the schema code landed in cloud-init.) [13:41] Odd_Bloke, ack [13:41] rharper: You should probably sign the CLA too. :p [14:18] powersj: GH/Travis are very confused about your README PR, I think we may need to throw that one away and start again. [14:21] OK, I think it might have been confused because the commit you created had state attached to it in a weird way; I just `commit --amend`ed it locally, and it's now only showing a single in-progress Travis check. [14:23] Odd_Bloke: ack [14:31] paride: I've just sent an email to the cloud-init ML to answer your "Mhh, how is it that Travis CI didn't run on this PR?" Q. :) [14:32] (And have already applied the prescribed fix in this case. :) [14:36] Odd_Bloke, great, thanks [14:45] Odd_Bloke, based on your email I assume we are in a happy state now? [15:03] powersj: Yep, thanks! [15:03] sweet [15:17] I'd like to have someone take a look at https://github.com/canonical/cloud-init/pull/416 sooner than later. [15:17] for obvious reasons, re-basing or merging is probably going to be a pain again. === 5EXAAFRTG is now known as ober [16:08] lucasmoura: thanks for the update on the SRU [16:08] https://github.com/cloud-init/ubuntu-sru/pull/99#pullrequestreview-426391003 [16:08] smoser: grabbing it now [16:09] lucasmoura: just a minor set of fixes on your PR #99, then we'll land it [16:21] blackboxsw, Thanks for the review. I have updated the code [16:23] smoser: review posted. thanks! [16:29] blackboxsw: responded [16:29] lucasmoura: mergedhttps://github.com/cloud-init/ubuntu-sru/pull/99 [16:29] checking smoser [16:30] +1 smoser [16:30] launching a container now to double check smoser and will merge [16:30] and we can follow up w/ separate pr for runparts [16:31] is_exe doesn't seem unreasonable as a method exposed from a 'subp' module. [16:31] but since we have no other callers, your argument seems sane. [16:32] yeah I kinda figured the same. I was checking for any other users of X_OK... hrm looks like cloud-init/cloudinit/config/cc_chef.py [16:32] could use that too. [16:32] smoser: ok maybe we leave it public [16:33] smoser: sorry bout that. and we can fold in cc_chef to use subp.is_exe? [16:33] or separate PR [16:33] ? [16:34] so you're [16:34] oops. [16:34] um... i dont really feel strong. [16:35] i can do it. or not. [16:35] ok let's leave it public, as I can imagine other callers using subp.is_exe in the future [16:35] ok. [16:35] and chef could be adapted to it with a separate pr [16:35] or this one if you want [16:36] ok. back to public. [16:36] woo hoo. and around we go [16:36] going through a deployment now [16:46] blackboxsw: can you land? thanks for review. and very fast review of 148 files ;) [16:47] smoser: just checking the a set of chef changes for temporary file handling that appears to be in your branch. I think it's just locally when I diff against master. but I'm double checking before merging (as I'm hovering over the merge button)_ [16:48] yeah part of your PR. ok and documented. n/m [16:49] smoser: merged thx [16:49] i moved subp_blob_in_tempfile into cc_chef [16:49] as it was the only caller of that [16:49] and that method used util.writefilei and subp [16:49] so which woudl have caused recursive import [16:50] that was just the easiest way out since only one caller [17:03] blackboxsw: https://github.com/canonical/cloud-init/pull/416#issuecomment-640032968 any comment on (my comment)? [17:05] meena: heh, I saw that happy face on your comment and interpreted as a joke given the complexity of the cloudinit.distro.net refactor :/ [17:06] meena: specifically what do you see in that which would be significantly different on BSD*? [17:06] or rather, across each linux distro [17:07] well, right now, we my handle enabling and starting services on BSD, in modules, where we do it on Linux,it's all duplicated code [17:08] i actually thought, for puppet, we could use puppet to do it for us platform independently :D [17:09] (and probably the same for chef, but i don't know chef, so i can't speak for chef) [17:09] heh, right.... just get people to swallow the big puppet config mgmt solution pill. There goes our boot time :/ [17:10] all you'd do is puppet apply, not the full thing with server and agent and database [17:11] (in fact, despite being a Big Puppet Cheer Girl, i don't use the server/agent setup at all) [17:14] but, yeah, running ruby from python just to execute service { puppet: ensure => running, enabled => true } is overkill,overly specialised to that one module,and implementing very basic service handling in cloud-init would benefit more services [17:17] meena: yeah I'm a puppet fan too. Thanks for more context. I was misreading your PR comment related to the move of subp and didn't realize you were actually talking about the init services. right, those *could/should* be distro-specialized as there is a very different approach on many distros [17:19] sorry you were talking about a separate refactor. and I *think* that would make sense to generalize that service enable/chaining/start etc. right now the jinja templates for that and the config templates are getting a bit busy, which indicates that we may need to develop a better way to deal with it [17:20] * blackboxsw tries to wrap up all the discussion you good folks have been having on the cloudinit.(distro).net refactor per https://github.com/canonical/cloud-init/pull/391/files [18:06] Odd_Bloke: looks really good https://github.com/canonical/cloud-init/pull/391/files initial questions and I can followup [18:26] smoser: cloudinit/subp.py:377:17: F821 undefined name 'logexc' on https://github.com/canonical/cloud-init/pull/420 [18:31] blackboxsw: i don tknow what to do about that [18:33] https://paste.ubuntu.com/p/37rbHM6XQq/ ? [18:34] yeah smoser that looks good [18:35] don't want to pull in util.logexc [18:41] smoser: have you seen this before? I now see two travis CI builds queued for your PR and I can't trash the first one https://github.com/canonical/cloud-init/pull/419 [18:41] it's preventing me from merging via github UX [18:44] blackboxsw: no [18:44] not seen nit [18:48] y'all ever gone a day of using computers without reporting at least one bug? [18:55] blackboxsw, see Odd_Bloke's email [18:55] re: transition to travis-ci.com === Odd_Bloke changed the topic of #cloud-init to: Migration to travis-ci.com in progress, see https://lists.launchpad.net/cloud-init/msg00284.html | pull-requests https://git.io/JeVed | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting June 16 16:15 UTC | 20.1 (Feb 18) | 20.2 (Apr 28) | https://bugs.launchpad.net/cloud-init/+filebug [18:58] ahh oops right. I had triggered rebuild, but that didn't quite clear it up. though smoser just put that PR up within the last hour, so I don't that qualifies as a PR generated before the move [19:01] blackboxsw: Huh, yeah, that is weird. [19:01] Particularly as both checks are pointing at the same Travis build ID. :/ [19:01] smoser: is it worth, closing and reopening you RP? [19:01] meena: when i left Canonical, i looked at how many bugs i'd opened. I think it was 1 every 3 days for 10 years (including weekends/holidays) [19:01] PR rather https://github.com/canonical/cloud-init/pull/419 [19:01] blackboxsw: thats fine. i'll just re-submit [19:01] yeah something is amiss there as smoser's other PRs from today were running CI fine [19:01] thx [19:02] smoser: you'd think it'd get better, eventually?? huh? [19:05] i dont recall the number that were still open ;) [19:11] good a happy single CI run in progress on https://github.com/canonical/cloud-init/pull/421 [19:12] let's not try to look too closely [19:12] I'm going to look very closely into sleep now [20:50] falcojr: lucasmoura Odd_Bloke I uploaded 20.2.45 to https://launchpad.net/~cloud-init-dev/+archive/ubuntu/proposed/+packages I think the build finally completed in that PPA as I now see the right version present in apt policy [20:51] so we should be able to use that PPA for testing [21:03] https://github.com/canonical/cloud-init/pull/414 <-- this has two non-committer +1s, if a committer wants to take a quick look [21:05] lucasmoura: could nits on https://github.com/cloud-init/ubuntu-sru/pull/103/files [21:09] blackboxsw: Thanks! (And thanks to James and Paride for the earlier reviews!) [21:12] blackboxsw, Thanks for the review. I have updated the code [21:17] lucasmoura: a small response on renaming terminate_instance function. and +1 [21:19] blackboxsw, done [21:24] lucasmoura: merged. also with trello cards if you ctrl-c on the PR url and ctrl-v while highlighting the card, it attaches the PR link to the card top-level so that trello github automation will surface whether the PR is merged [21:25] lucasmoura: per this trello card https://trello.com/c/clHH7aDU/1680-add-code-to-terminate-ec2-instance it looks like you attach links in a comment, which doesn't surface github PR status on the card [21:25] awesome looks fixed now [21:25] then I can see a "1 merged" icon on the card without opening it (as well as [21:25] ci results too) [21:26] blackboxsw, Cool feature :) I will use on my next cards. Thanks for pointing that out [21:26] thanks [22:40] lucasmoura: for tomorrow https://github.com/canonical/cloud-init/pull/390/files review done [22:41] for ec2 mirror disabling [22:41] blackboxsw, ack