=== shardy is now known as shardy_lunch === shardy_lunch is now known as shardy === shardy is now known as shardy_afk [13:18] thnee, thats a fair point. for your info, though, you should be hesitant of anything that asks you for a private key. [13:29] back from a week of vacation...does https://code.launchpad.net/~larsks/cloud-init/+git/cloud-init/+merge/329661 need anything more, or is it good to go? === shardy_afk is now known as shardy [14:35] hey all, just a reminder, we have a status/discussion meeting in ~ 2 hours (Tue, 05 Sep 2017 16:30:00 +0000). [14:35] we will discuss [14:35] some of the things listed at https://lists.launchpad.net/cloud-init/msg00094.html [15:42] blackboxsw, cloudinit/net/dhcp.py [15:42] i think dhcp_discovery should take the interface back down if it brought it up [15:42] shouldnt it ? [15:43] ie, it has a side affect of leaving the 'ip link set dev up' [15:44] and EphemeralIPv4Network may have that too ? [16:09] larsks: hi there welcome back, I had forgotten about the vacation, I'll back my branch donw [16:09] larsks: hi there welcome back, I had forgotten about the vacation, I'll back my branch down [16:32] hey. [16:32] this is time for meeting now. [16:33] \o/ [16:34] anyone else here for this ? [16:34] larsks, no ajorgens, robjo ? [16:35] sorry chasing an urgent issue, not really here [16:35] no worries. [16:37] for this meeting, i'll just run through [16:37] https://public.etherpad-mozilla.org/p/cloud-init-meeting [16:38] # Recent Changes / Highlights [16:38] * integration of robjo's opensuse items [16:38] * summit results posted to mailing list https://lists.launchpad.net/cloud-init/msg00094.html [16:38] # In Progress Development / Highlights [16:39] Trello Board: [https://trello.com/b/hFtWKUn3/daily-cloud-init-curtin] [16:39] Bugs: https://bugs.launchpad.net/cloud-init [16:39] Opensuse builds: https://build.opensuse.org/package/show/Cloud:Tools:Next/cloud-init [16:39] that pasted poorly [16:39] #startmeeting cloud-init status update [16:39] :) [16:39] we also have a SRU in progress. information at https://people.canonical.com/~ubuntu-archive/pending-sru.html [16:39] ... blackboxsw do we have the both ere now ? [16:39] sorry. [16:40] yeah meetingology is here now :) [16:40] smoser: sorry, lunch, here now :) [16:40] ok. well, for next time i guess blackboxsw [16:40] put some info on bot meetingology at https://public.etherpad-mozilla.org/p/cloud-init-meeting ? [16:41] # topic: open Discussion [16:41] The biggest followup item really was to discuss release items such as frequency and version numbers. 'Proposal: Roll over to 1.0.0' in the post is generally accepted by myself and others. So I think that we will probably move to 1.0.0 [16:41] sure will do [16:41] strange that it's not here anymore. will get that up for next meeting [16:41] i think that targetting 3 month release cycles seems sane. [16:42] +1 on that. [16:42] sweet [16:43] smoser: https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/327646 can that get a review? ;) [16:43] pretty please [16:43] the 3 month ish release cycles im' more sold on. as semantic versioning is kind of hard for me to find a obvious mapping. [16:43] because [16:44] heh, yep powersj smoser and I both said it'd be on our radar for today [16:44] a.) we generally try to be backwards compatible always [16:44] b.) we don't really offer/support python api (but rather just config module input and such) [16:44] c.) "major feature" on one platform is not necessarily anything to another platform (datasource) [16:44] smoser: I'm certainly not a stickler for semantic versioning, just for rational versioning that communicates somehow that magnitude of changes between releases. [16:45] even the addition of a new datasource... which is clearly a big deal (we added Scaleway) means nothing for others. [16:45] larsks, it is still hard... [16:45] smoser: generally discussing the roadmap, what we expect to land in the upcoming release should I think bring about any discussion needed about "major" version bumps and what not [16:46] Sure. I guess an alternative, with a regular release cadence, is ubuntu-style month/year based versioning. [16:47] it certainly seems to me that unless you intend to service the right-most digit of X.Y.Z (or X.Y) then it has no value. [16:47] some downstreams may be interested in just that [16:48] I guess. I mean, I would argue that if a release consistents pretty much exclusively of bug fixes, that's a .Z release, and if a release introduces new data sources or major internal changes, that's a .Y, and if the behavior changes significantly, that's a .X. [16:48] ie, at this point i do not have intention of upstream maintaining a 1.0 branch to 1.0.1 and 1.0.2 ... (or 1.0.1.1 ... ) [16:48] so a major.minor bump then based on release cadence ++ an eye to major changes might be of interest [16:49] smoser: then perhaps a YY.MM scheme might be better [16:49] since it more closely matches the release scheme [16:49] yeah. [16:49] I think the majority of our "major" features are known within a 6 months timeframe (even 3 months) [16:50] so, whatever the numbers are, discussing the features/roadmap here will make folks interested in the numbers aware of what they mean [16:52] i think that i like the idea of time based release numbers [16:52] and documenting what changes/features/function are in each [16:52] That seems fair. [16:53] hm.. [16:54] * smoser just can't bring himself to type high version numbers [16:55] 17.09 is just around the corner [16:55] 0.7.9 -> 17.09? mostly the same numbers, just reordered [16:55] yeah.. i noticed that too. [16:55] Ha :) [16:55] numerology, fantastic [16:55] and arguably so is 7.9 [16:55] the stars are alined [16:55] aligned [16:55] (dropping 2010 years) [16:55] all hail the 17.09 [16:56] yeah, 17.9 would work [16:56] 17.9 -> 17.12 -> 18.3 -> 18.6 etc ? or do we want the extra zero for comfort ? [16:57] well, the other option is openstack based. [16:57] they dont mark months [16:57] just releases in that year [16:57] 17.1 and 17.2 [16:58] I like that [16:58] Yes, but then you'll endup with people spawning cloud-init sub-projects with names like "Zarkon" and "Farfnagle". [16:58] hah [16:58] larsks, this is a good point. [16:58] (can we call that a "feature" :) ) [16:58] larsks: may it never be! [16:58] smoser: so [16:58] * larsks has the branch name for his next patch. [16:58] it feels to me like i'd keep 17.XX including the zero [16:58] larsks: those are great names! [16:58] one thing we had in previous projects [16:58] is the month would change out while qualling the release [16:59] dpb1: "qualling"? [16:59] then we were like "should we keep it .06 or .07" [16:59] qualing [16:59] or quailing [16:59] because Ubuntu 17.10 having cloud-init 17.1 (which was released in the 9th month of 2017) is confusing. [16:59] doing QA/bug fixing [16:59] Ah, got it. [16:59] smoser: does that mean SRUs to xenial will have 16.04 and a 17.09 in the version? [16:59] powersj: yeah it would [17:00] :\ [17:00] yup [17:00] powersj, numbers mean nothing [17:00] then use 1.0.0 ;) [17:00] except to those who think they do [17:00] I thought we just established they mean everything and we should hail them [17:00] however, only for 18.04; 16.04 will forever have 0.7.X.16.04. ... even if it's cloud-init 17.12 or whatever [17:01] rharper, no [17:01] if we new-upstream-snapshot back to 16.04 it will get a new upstream version [17:01] and that is perfectly fine [17:01] ok, so it'll look strange no matter what === shardy is now known as shardy_afk [17:02] dpb1, you mentioned concern that "qualing" could change the month [17:02] smoser: so on new-upstream release in say xenial, would we ever have a ~16.04.x value? [17:02] just that it happened often for us [17:02] rharper, well it gets a 16.04.1 value, but that is only to make it < the package version in another ubuntu release. [17:02] we would start mid september, name the release 17.09, then come october, we would be done and go "oops, now we need to rename to 17.10" [17:03] (that is the only reason those exist... to account for upgrades xenial -> yakkety -> zesty -> aa ... ) [17:03] we wouldn't rename a release [17:03] in the end it didn't matter, as you mentioned, but it bugged us [17:03] yes [17:03] I think in our case, we don't name it till we ship it, that's fine [17:04] it does kind of get named. [17:04] at some point you change cloudinit/version.py [17:04] smoser: it's why I said I liked the "17.1, 17.2" scheme [17:04] i dont know. [17:04] but, it's minor [17:04] and in the end it didn't really matter [17:04] was more of a programmer brain thing [17:05] dpb1, my only issue with that is confusion with ubuntu [17:05] similar but different [17:05] yes [17:05] well, making it different helps [17:05] with powersj's concern [17:06] but not different enough (for ubuntu folks) [17:06] 16.04...17.1 [17:06] but maybe that's just our problem [17:06] you get used to it, but ya, it can be slightly confusing. [17:07] ok.. .so ignoring that [17:07] openstack has the same issue, so it's at least not crazy [17:07] lets target a release say on 21 of Sept [17:07] as a stick in the mud [17:08] and that would be called either 17.9 or 17.1 [17:08] week before rally [17:08] fyi [17:08] that seem sane ? [17:08] +1 [17:08] +1 [17:08] though not sure how we resolve the .9 or .1 part [17:08] wise sage once told me if there truly is no best choice, coin flip [17:09] rharper: flip a coin + documentation, I guess. [17:09] release sounds good , we can get heads together at the rally if we need to work out SRU issues [17:09] larsks: hehe [17:09] actually, there is a better one [17:09] you coin flip [17:09] https://www.google.com/search?client=ubuntu&hs=VJz&channel=fs&q=flip+a+coin&stick=H4sIAAAAAAAAAHvEaMct8PLHPWEp00lrTl5j1OcSyylKS0wuyS-qtHIrzUvKrwjOzC3ISRUS5WIpqSxIFeLl4pbiTM7PzItPy8ks4AEAyHBN80EAAAA [17:09] then, if you are dissapointed, you choose the opposite [17:09] lol [17:10] other htan ubuntu tie in... i really prefer using only the year. [17:10] ie... 17.1 -> 17.2 independent of the month [17:10] it's my preference still [17:10] (slight) [17:11] I like without the month as well [17:11] I'm all for either, I'd like to avoid where the month ends up being incorrect because of release slip due to testing etc [17:11] I like the month, feels like a forcing function since the version is fixed but I don't care that much, and it would make the version different than the ubuntu numbers [17:12] ok. so i'm ready to be done with this. so heres what i propose [17:12] ... though I realize this discussion walking fairly close to bikeshed territory. I'm up for whatever folks think is sane [17:13] * i pretend that i flipped a coin and it came up in favor of my preference (no minor version linked to month) [17:13] * i write to mailing list with that as the plan and suggesting the target release date of 17.1 on the 21. [17:13] * ask for anyone who would *strongly* oppose to say so [17:13] objections ? [17:14] Sounds good to me. [17:14] alright. [17:15] so i'm gonna call this meeting "done" for now. and office hours for the next 30 minutes or so. [17:15] (although i'm going to step out for 5) [17:15] objections before i step out ? [17:15] +1 smoser [17:15] none here [17:16] larsks: I just landed your move tests/unittests/helpers -> cloudinit/tests branch. thank you for the attention there https://code.launchpad.net/~larsks/cloud-init/+git/cloud-init/+merge/329661 [17:16] blackboxsw: awesome, thanks! [17:16] On a completely different topic: is there somewhere in launchpad a link to https://launchpad.net/cloud-init/+activereviews? I can never find it when I want it and end up googling the answer. [17:16] larsks: https://code.launchpad.net/cloud-init/+activereviews [17:17] is what I review daily. [17:17] That...is the same thing I just pasted. I mean, is there a link somewhere ("show all active reviews") that goes there? [17:18] here: https://code.launchpad.net/~cloud-init-dev/cloud-init/+git/cloud-init/+ref/master click on "20 branches" [17:18] heh. oops [17:18] powersj: Ah, thanks! [17:18] it includes work in progress, but gets you that same list [17:19] larsks: also sent you mail last week, if you wouldn't mind looking for it sometime after catching up would be much appreciated [17:19] powersj: yah, catching up on oodles of email today :) [17:19] I'm sure :) [17:19] no rush [17:20] harlowja: I noticed your irc client joined mid meeting, figured I'd touch base on this in case you were watching. I was touching cc_resizefs and saw something that appears to us like vestigial config option "resize_rootfs_tmp" the only thing the module does with this is ensure_dir to create the directory "/run" if it doesn't exist. [17:20] hallo [17:20] will look in a sec blackboxsw (in standup) [17:20] +1: hiya harlowja. I was going to drop the resize_rootfs_tmp if you didn't think it had any meaning anymore [17:21] http://cloudinit.readthedocs.io/en/latest/topics/modules.html#resizefs [17:24] a review point for smoser I think. I'm good w/ sankar's https://code.launchpad.net/~sankaraditya/cloud-init/+git/cloud-init/+merge/319866 for OVF. I *think* it's in state to land but wanted to make sure you were good w/ the rewriting of the broken /etc/network/interfaces which adds back the "include /etc/network/interfaces.d" that he's doing there. [17:25] blackboxsw, also see topic [17:25] http://bit.ly/ci-reviews [17:26] meh, I keep using the bzr review url without realizing it. force of habit [17:26] for shame [17:30] smoser: I pinged in #meetingology channel to try to get that bot added again for us. it dropped out on Aug15th I think looking at IRC logs [17:35] * blackboxsw has to run an errand, back in ~20 mins === shardy_afk is now known as shardy [17:57] smoser: https://bugs.launchpad.net/cloud-init/+bug/1715095 another good bug report worth a comment [17:57] Ubuntu bug 1715095 in cloud-init "network is only configured on first boot" [Undecided,New] === shardy is now known as shardy_afk [19:22] yay! [21:56] #startmeeting cloud-init status meeting [21:56] Meeting started Tue Sep 5 21:56:34 2017 UTC. The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology. [21:56] Available commands: action commands idea info link nick [21:57] #subtopic valuable subthread [21:57] #link https://cloud-init.io [21:57] #endmeeting [21:57] Meeting ended Tue Sep 5 21:57:47 2017 UTC. [21:57] Minutes: http://ubottu.com/meetingology/logs/cloud-init/2017/cloud-init.2017-09-05-21.56.moin.txt [21:57] this concludes a test broadcast [21:58] hi meetingology! [21:58] I wasn't sure why it left us. but wanted to make sure we queued up one meeting so it didn't detach due to idle time or something [22:02] hrmph [22:02] blackboxsw: how did you get it back in? [22:02] I talked to jose in #meetingology channel on freenode [22:03] blackboxsw: did he say why it left? [22:03] does he just not like us? [22:03] it just involved him (as admin) running meetingology: join #cloud-init [22:03] two separate "he"s there [22:03] no but I'll ask to be sure