16:03 <blackboxsw> #startmeeting Cloud-init bi-weekly  status
16:03 <meetingology> Meeting started Mon Nov 13 16:03:13 2017 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
16:03 <meetingology> 
16:03 <meetingology> Available commands: action commands idea info link nick
16:03 <powersj> o/
16:03 <blackboxsw> time change got to us
16:04 <blackboxsw> #meetingtopic Recent Changes
16:05 <blackboxsw> hey folks. thanks for joining just pulling together the content for the last couple weeks of work for the cloud-init project
16:06 <smoser> http://paste.ubuntu.com/25954862/
16:06 <smoser> $ git log a90a8b1cb3104ee3250ac79d6e25a9ff4f527baa.. | log2dch | sed 's,^    ,,' | pastebinit
16:06 <blackboxsw> most of the ubuntu-side of the house was involved in handling the SRU of 17.1 into ubuntu and handling any discovered regressions
16:06 <blackboxsw> Published cloud-init packages to Bionic Beaver release
16:06 <blackboxsw> Update Gentoo Linux support to "rc-service" scripts as "service" is deprecated, thanks to ckonstanski!
16:06 <blackboxsw> Detected and fixed a pre-release regression of resizefs when root path is specified by UUID on the kernel cmdline (LP: #1725067)
16:06 <ubot5> Launchpad bug 1725067 in cloud-init (Ubuntu Zesty) "cloud-init resizefs fails when booting with root=PARTUUID=" [Medium,Fix committed] https://launchpad.net/bugs/1725067
16:06 <blackboxsw> #link http://paste.ubuntu.com/25954862/
16:07 <blackboxsw> #info SRU queued for release today
16:07 <blackboxsw> Here's the cloud-init content we published for the last two weeks:
16:07 <blackboxsw> #link https://github.com/canonical-server/dev-summary/blob/master/doc/2017-10-31.md
16:07 <blackboxsw> #link https://github.com/canonical-server/dev-summary/blob/master/doc/2017-11-07.md
16:09 <blackboxsw> last week we handled an EC2 behavior regression for xenial, whereby we didn't want to change cloud-init to configure all nics based on ec2 metadata, we will only configure the primary nice
16:09 <blackboxsw> last week we handled an EC2 behavior regression for xenial, whereby we didn't want to change cloud-init to configure all nics based on ec2 metadata, we will only configure the primary NIC
16:09 <blackboxsw> with those SRU regresssions fixed and published to master, we expect cloud-init 17.1 updated in Xenial,Zesty and Artful today
16:10 <blackboxsw> #meetingtopic In-progress development
16:10 <blackboxsw> smoser: rharper anything here?
16:10 <smoser> #link http://bit.ly/ci-reviews
16:11 <smoser> robjo has done a couple fixes for SuSE and i've pulled a few of them.
16:11 <smoser> he has one up i saw yestderday for ntpSuSE
16:11 <smoser> others ther.e we've been delinquent due to some distractions recently.
16:11 <rharper> blackboxsw: nothing new for me at the moment
16:12 <smoser> and chad had one up for clean and status
16:12 <blackboxsw> btw thx robjo ckonstanski and Dave Mulford for the fixes over the last iteration. We also expect that a couple VMware branches for the OVF datasource will last this week or next
16:12 <smoser> which is nice.
16:13 <robjo> moving the meeting an hour foward while we are on Standard time or is this a one time occurance, did I miss an announcement?
16:13 <blackboxsw> #meetingtopic Office Hours (next 30 minutes)
16:14 <robjo> lp#1731619, chrony support, should that also be driven through ntp config or should there be a new config option?
16:14 <blackboxsw> so we'll hang out with eyes on this channel for any burning questions/bugs/questions
16:14 <smoser> robjo: well, the meeting is listed in UTC time
16:14 <smoser> that pays no attention to US legislation to change clocks at random points in the year :)
16:15 <robjo> oK, my fault when I added it to my calendar, eay enough to fix ;)
16:15 <smoser> but the humans here were also affected :)
16:15 <blackboxsw> heh, anyone opposed to shifting this meeting time +30 from now during the next few months?
16:15 <blackboxsw> as the meeting now collides w/ another meeting for us
16:15 <blackboxsw> :/
16:16 <blackboxsw> officially 16:30 UTC?
16:17 <robjo> Well, I'd prefer to either follow the "randomness" clock manipulation or not follow it
16:19 <robjo> meaning don't change the meeting time because there exists a conflict when standard time switches to daylight savings or vice versa, becaus if you do that you might as well follow the silliness of the government to begin with
16:19 <blackboxsw> fair point. ok let's keep the new time as is.
16:20 <blackboxsw> we've discussed side-channel, we can shift our meetings out of the way of this
16:20 <blackboxsw> so robjo +1
16:20 <blackboxsw> 16:00 UTC
16:24 <blackboxsw> also related to CI side, powersj and rharper spent quite a bit of time w/ our continuous integration infrastructure fixing/addressing memory & storage pressure issues to make sure we avoid intermittent false test failures due to timeouts or system resource contention
16:24 <blackboxsw> #link https://jenkins.ubuntu.com/server/view/cloud-init/
16:28 <via> is there a way to use metadata in the cloud-init file? specifically, if i want to use the aws-provided instance id in an attribute
16:28 <robjo> OK, back to my question about chrony:  lp#1731619, chrony support, should that also be driven through ntp config or should there be a new config option?
16:28 <via> like configuring the chef node name to have my instance id in it
16:32 <blackboxsw> #link https://bugs.launchpad.net/cloud-init/+bug/1731619
16:32 <ubot5> Launchpad bug 1731619 in cloud-init "Support chrony as a client for ntp" [Undecided,New]
16:33 <blackboxsw> it's a good bug, we've had a couple of discussions about ntpd versus timesyncd for different system environments
16:34 <blackboxsw> current implementation of cc_ntp module is to return False ('ntp' not installable) on certain known environments where we know we want systemd timesyncd to run instead by default
16:34 <smoser> via: i think what your asking is (i htink) covered in https://trello.com/c/AYaCdQyT
16:35 <via> well, i'm trying to do it in a yaml cloud-config file
16:35 <smoser> right. as it is right now, via you cann't reference anything from the metadata.
16:35 <via> does that mean i need to use #jinja and if so how does that play with #cloud-config ?
16:35 <via> oh
16:36 <via> bummer
16:36 <via> should i just switch to a shell script?
16:36 <smoser> but we'd hope to implement that.
16:36 <smoser> via: thats really the only way right now. and then in the shell scripty you'd have to query the metadata service yourself.
16:36 <via> okay, damn
16:36 <via> thanks
16:36 <blackboxsw> robjo: we think that's a good approach/feature suggestion. We could add chrony template files etc like the ntp templates, and we might be able to have the distro report what time sync daemon it wants to run
16:36 <smoser> basically... we realize what you're asking is quite helpful and reasonable but dont have a way to do it right now
16:36 <smoser> but we do plan on implementing it.
16:37 <via> no worries, i'm stuck on an ancient version anyway
16:38 <robjo> blackboxsw: That was my thinking, move the "service_name" setting to the distro as "time_service_name" and then drive cc_ntp based on that
16:39 <robjo> since with a third option the black/white decision being made today will no longer work
16:39 <blackboxsw> +1 robjo yeah. rharper was chatting about this potential approach as well
16:39 <robjo> look there is also grey ;)
16:39 <blackboxsw> heh yeah
16:40 <robjo> Next question.... network config.
16:40 <blackboxsw> yeah might have to 'grow' an override option in cc_ntp module eventually
16:41 <blackboxsw> as those grey use-cases come up (per bugs/requests ;) )
16:41 <robjo> A long timi ago the RHEL implementation was re-written to use sysconfig renderer, but RHEL sysconfig and SLE sysconfig are different, why wouldn't they be
16:42 <robjo> that also implies that the openSUSE/SLES implementation for network config rendering still uses the "old" implementation and thus produces a warning in the log file
16:43 * blackboxsw is looking for the warning generated
16:43 <robjo> this would imply some refactoring is in order if we want to move openSUSE/SLES to using the newer API to render the network config
16:44 <robjo> blackboxsw: "apply_network_config is not currently implemented "
16:44 <robjo> "for distribution '%s'.  Attempting to use apply_network"
16:45 <blackboxsw> ahh. right-o
16:45 <robjo> the question from my point would be is, when I want to implement the SUSE bits am I also on the hook for the refactoring part or can I get some help with that? which of course will make my life easier ;)
16:47 <robjo> And yes, I realize a bug will need to be filed, but I haven't figured out how to formulate this nicely
16:47 <blackboxsw> robjo: I think we should be able to help out a bit with that refactor to make sure it's cleaner and easier to maintain.
16:47 <robjo> OK :)
16:50 <blackboxsw> there are a couplengeneric distro fixes which need to get designed (just like in the datasources) to make the common distro classes a bit easier to maintain as well as making classes a bit more modular and more easily tested.
16:51 <blackboxsw> we still haven't landed some of the common datasource changes we had talked about during the Summit because we've been avoiding risk during the 17.1 release. But, similar/minor architecture changes should start taking shape here for datasources and distros now that we see a light at the end of the tunnel on the release.
16:52 <blackboxsw> we'll keep our eyes open for discussions/suggestions from folks
16:54 <robjo> Speaking of data sources, for the SUSE Container As A Service Platform, we implemented a data source to read from local disk, is that something that would be of interest upstream? Yes, this might seem silly but in our use case it makes perfect sense ;)
16:56 <blackboxsw> robjo: I'm curious how different that datasource would be from nocloud datasource
16:56 <blackboxsw> http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html?highlight=nocloud
16:56 <blackboxsw> #link http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html?highlight=nocloud
16:56 <blackboxsw> which allows for providing local data instead of dealing with metadata
16:56 <blackboxsw> well network metadata
16:57 <robjo> I wasn't really involved, just accepted the patch to the package and have not done a comparison to nocloud, but I'll take a look
17:00 <blackboxsw> good deal.... think we are at the top of the hour... so I'll probably end meeting now
17:01 <blackboxsw> thanks via robjo rharper powersj & smoser. next meeting 2 weeks same early time
17:01 <blackboxsw> #endmeeting