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