=== tds3 is now known as tds
=== tds0 is now known as tds
=== cpaelzer__ is now known as cpaelzer
[13:39] <smoser> hey. sorry if i'm off in the weeds https://github.com/canonical/cloud-init/pull/426
[13:40] <smoser> i fully realize that historically vmware administrators expect that they can execute arbitrary code inside guests.
[13:41] <smoser> and I also realize that cloud-init is'nt *really* going to stop that.  But cloud-init should at least allow the user to lock the door that cloud-init opened.
=== tds6 is now known as tds
[14:07] <Odd_Bloke> smoser: I don't think you're off in the weeds, I agree with your assessment (and line of questioning).
[14:12] <meena> I've worked in companies that used VMware where creating the husk of a vm, and filling it with an actual OS where in the hands of two different teams who don't trust each other
[14:15] <meena> i can imagine at least one of those teams, or their common department head, wanting to close that door
=== waxfire2 is now known as waxfire
[14:38] <Odd_Bloke> blackboxsw: meena: Goneri: Just replied to (I think) all the comments on https://github.com/canonical/cloud-init/pull/391 and also asked for some specific high-level input in my latest comment.
[14:40] <Odd_Bloke> rharper: smoser: Your thoughts in ^ on how we should think about interface renaming conceptually would be much appreciated, as I think that's the one outstanding question I want to resolve before I'd be happy landing this PR, and I don't feel like I have the background in the details that you do.
[15:05] <lucasmoura> blackboxsw, should we do a manual fix for this commit as well: https://git.launchpad.net/cloud-init/commit/?id=3e2f7356 ?
[15:16] <meena> right, i got distracted reading that
[15:20] <rharper> Odd_Bloke: i'll look
[15:37] <Odd_Bloke> Thanks!
[15:39] <blackboxsw> falcojr: here's a reference to the consolidated rc file for manually test clouds during SRU, https://github.com/cloud-init/ubuntu-sru/pull/113  this is only a meager start to consolidating some of the common config, utilities and functions.
[15:39] <blackboxsw> my plan is to reflect those changes into each manual cloud template after this PR land.
[15:39] <blackboxsw> lands*
[15:42] <rharper> Odd_Bloke: hrm, I didn't see a specific response to how BSD handles containers (maybe that's not needed) or multi-nic instances on platforms where the nic names/macs are unstable
[15:43] <rharper> Odd_Bloke: I would say lacking a response (or not having answer) I'd lean on keeping renaming Linux specific, and if/when it becomes an issue in BSD, they can provide an implementation
[15:46] <smoser> it should fail though.
[15:47] <smoser> if something provides a network config that includes renaming. then cloud-init needs to fail as it can't possibly do it, and the user is just going to say "where is my foonic0!"
[16:21] <blackboxsw> #startmeeting cloud-init status meeting
[16:21] <meetingology> Meeting started Tue Jun 16 16:21:42 2020 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:21] <meetingology> Available commands: action commands idea info link nick
[16:22] <blackboxsw> #chair smoser Odd_Bloke rharper
[16:22] <meetingology> Current chairs: Odd_Bloke blackboxsw rharper smoser
[16:22] <blackboxsw> Welcome to the bi-weekly cloud-init status meeting. A place to chat about upstream cloud-init activity/
[16:23] <blackboxsw> his meeting is a welcome place for interruptions, questions, requests and unrelated discussions at any point.
[16:23] <blackboxsw> *this*
[16:23] <blackboxsw> previous meeting minutes are stored on github
[16:23] <blackboxsw> #link https://cloud-init.github.io/
[16:24] <blackboxsw> The topics we generally cover in this meeting are the following: Previous Actions, Recent Changes, In-progress Development, Community Charter, Office Hours (~30 mins).
[16:24] <blackboxsw> From the previous meeting we captured no actions, so I'll jump into the next topic
[16:24] <blackboxsw> #topic Recent Changes
[16:25] <blackboxsw> the following are commits merged into cloud-init's upstream master branch: https://paste.ubuntu.com/p/WdsZXbwwWd/
[16:26] <blackboxsw> found via git log --since 06-02-2020
[16:29] <blackboxsw> notable changes:   util.runparts and subp out of util into subp.py,      there are a couple of branches related to improved vmware support, and resolving keyerror issues for users providing network configuration with bridges.
[16:30] <blackboxsw> also upstream travis CI is now using the commercial travis-ci.com instead of travis-ci-org which should give us better throughput on test runs.
[16:31] <blackboxsw> community notice: if any PRs created > 1 week ago have problems with unresolved travis ci runs marked 'in progress' those PRs will likely need to be closed and re-submitted due to the shift in travis-ci endpoints.
[16:32] <blackboxsw> #topic In-progress Development
[16:33] <blackboxsw> Upstream devs are currently working our way through Ubuntu StableReleaseUpdate (SRU) validation to release cloud-init version 20.2.45  to Ubuntu Xenial, Bionic, Eoan and Focal.  Thanks falcojr lucasmoura and Odd_Bloke for all the help generating test cases and reviewing SRU-related content.
[16:34] <blackboxsw> We are about halfway through out testing of this release of cloud-init and expect to be able to wrap this up before next week.
[16:34] <blackboxsw> To track this release, anyone can subscribe to the SRU process bug
[16:35] <blackboxsw> #link https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1881018
[16:35] <ubot5> Ubuntu bug 1881018 in cloud-init (Ubuntu) "sru cloud-init (19.4.33 to 20.2-45) Xenial, Bionic, Eoan and Focal" [Undecided,In progress]
[16:35] <blackboxsw> that bug will go to Fix Released when our upload to <ubuntu-release>-updates apt pocket is published
[16:36] <blackboxsw> Beyond SRU, there is a significant refactor of cloudinit.net* module to define a clear API and push distro-specific content into the distro modules.
[16:37] <blackboxsw> #link
[16:37] <blackboxsw> #link https://github.com/canonical/cloud-init/pull/391
[16:38] <blackboxsw> Thanks Odd_Bloke for driving that refactor. Those interested should check out the above PR
[16:39] <blackboxsw> I think that about wraps it.
[16:40] <meena> during the util.subp refactor i suggested also looking into centralising service enabling and (re) starting
[16:41] <meena> but we kinda glossed over that because of the net refactor
[16:41] <blackboxsw> meena: good chance to bring that up: let's get that comment link
[16:43] <blackboxsw> #link https://github.com/canonical/cloud-init/pull/416#issuecomment-640032968
[16:44] <blackboxsw> meena: your comment was really about re-organizing the ./systemd ./upstart top-level directories and refactoring down into the distros somehow?
[16:44] <blackboxsw> as that startup service construct is highly distro dependent?
[16:46] <blackboxsw> If that's the suggestion you are raising for comment, I think it sounds like a reasonable thing to consider. Each distro has it's own way of handling system service management.
[16:47] <meena> *nod
[16:48] <blackboxsw> given the fact that all the systemd/ startup script files are all templates, it indicates that we have a lot of distro-specific uniqueness even across various flavors of linux
[16:49] <blackboxsw> I think that refactor would be significantly simpler to describe in a distro-level API
[16:51] <blackboxsw> meena: maybe we file a feature bug against cloud-init so we can prioritize that work.
[16:51] <meena> you're right. let's do that
[16:52] <blackboxsw> we could surface that bug to the mailinglist
[16:53] <blackboxsw> meena: do you want to do either of those (bug or mailinglist email: subj: Refactor startup service to distro-specific Api) ?
[16:53] <blackboxsw> #action file feature bug about refactoring startup services
[16:53] <meetingology> ACTION: file feature bug about refactoring startup services
[16:53] <blackboxsw> #action mailing list email requesting comment/concerns about a refactor of startup services
[16:53] <meetingology> ACTION: mailing list email requesting comment/concerns about a refactor of startup services
[16:54] <blackboxsw> I've added actions that we can track by next meeting to see if we can make progress on that discussion
[16:54] <blackboxsw> ok next topic I think
[16:54] <blackboxsw> #topic community charter
[16:55] <blackboxsw> As always, any aspects of the cloud-init project is open for participation from community members.
[16:56] <blackboxsw> We thank everyone for contributing bugs @ https://bugs.launchpad.net/cloud-init/+filebug, reviewing open 'New' bugs that are filed, and reviewing pulls requests @ https://github.com/canonical/cloud-init/pulls
[16:57] <blackboxsw> all reviews are welcome on any PRs that are up. and driving feature discussions are also encouraged. Thanks meena for participating on all of those fronts
[16:59] <blackboxsw> for those just wanting to join in and contribute small pull requests there is a queue of bugs or features that should be a fairly contained set of tasks in our bitesize queue:
[16:59] <blackboxsw> #link https://bugs.launchpad.net/cloud-init/?field.tag=bitezise
[16:59] <blackboxsw> #topic Office Hours (~next 30 minutes)
[17:00] <blackboxsw> This 'section' of the meeting is a time where a couple of upstream devs will be available in channel for any discussions, questions, bug work or PR reviews.
[17:01] <blackboxsw> In the absence of discussion topics, reviewing the active PRs generally occurs to scrub our queue and unblock conversations.
[17:02]  * blackboxsw addresses some review comments on a CI Ubuntu daily test branch
[17:22] <AnhVoMSFT> question: is there anyway to only target a particular reporting handler?
[17:23] <AnhVoMSFT> Right now the Azure DS emits events to the HyperV KVP handler and they also pass through the log handler. For the most part this is fine (and useful). For some larger event message (like compressed log), it does not make sense to emit a large blob of compressed gzip + b64 to the log, is it possible to skip the log handler ?
[17:30] <blackboxsw> hrm, good question AnhVoMSFT . looking
[17:33] <Odd_Bloke> blackboxsw: meena: Note that the service files are selected at package generation time, not at runtime, so it's not entirely clear to me how you would integrate them into the Distro hierarchy.
[17:42] <blackboxsw> nice suggestion Odd_Bloke
[17:43] <blackboxsw>  AnhVoMSFT: I'm not seeing any filtering config options in reporting: config for handlers.   Are you saying you are looking to add compressed object writes to your kvp message message plane?
[17:44]  * cyberpear wondering if there's any collaboration with the ignition folks
[17:46] <blackboxsw> AnhVoMSFT: I think it's be reasonable to provide a named report handler to ReportEventStack
[17:46] <blackboxsw> and let ReportEventStack limit what handlers it can emit publish_event to
[17:48] <meena> https://github.com/canonical/cloud-init/blob/master/cloudinit/config/cc_puppet.py#L106 could this be entirely puppet specific, and no other module does this dance?
[17:50] <blackboxsw> AnhVoMSFT: that'd mean I suppose that report_event would need to accept a new param to limit which handler it calls handler.publish_event  for
[17:50] <blackboxsw> https://github.com/canonical/cloud-init/blob/master/cloudinit/reporting/events.py#L84
[17:52] <meena> https://github.com/canonical/cloud-init/blob/master/cloudinit/config/cc_rsyslog.py#L210 one more
[17:52] <blackboxsw> or maybe you are suggesting that we add the ability for an existing handler to define a set of data types that it accepts (and will silently ignore others)?
[17:54] <blackboxsw> and here meena https://github.com/canonical/cloud-init/blob/master/cloudinit/config/cc_fan.py#L55-L83
[17:58] <blackboxsw> ok I've got to run.   time to close the meeting for today. Thanks all for joining in!
[17:58] <blackboxsw> #endmeeting
[17:58] <meetingology> Meeting ended Tue Jun 16 17:58:32 2020 UTC.
[17:58] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/cloud-init/2020/cloud-init.2020-06-16-16.21.moin.txt
[17:58] <AnhVoMSFT> @blackboxsw I think we will look into adding a new param to report_event
[17:59] <AnhVoMSFT> so that it can emit only to a certain handler and does not go through all the available_hanlder
[17:59] <AnhVoMSFT> (probably adding a new param indicating a new filter list)
[18:10] <blackboxsw> AnhVoMSFT: that makes sense to me. So, you'd avoid using the ReportEventStack context manager with  that as well?
[18:10] <blackboxsw> or do you plan to also use the context manager?
[19:09] <AnhVoMSFT> I have not looked that far to be honest. Will take a look later this week and start some POC
[19:43] <AnhVoMSFT> @blackboxsw @rharper @Odd_Bloke: is there any way to create an image with an existing user-data (#cloud-config) and provisions the VM with cloud-init using  the user-data that was prepared inside the VM
[19:45] <meena> does the meetingology text exist in formated?
[19:51] <rharper> AnhVoMSFT: hrm, sort of;  you can put additional user-data config in an /etc/cloud/cloud.cfg.d/NN-my-user-data.yaml  ... however, if there are namespace overlaps then you have to deal with merging
[19:51] <rharper> AnhVoMSFT: If the user-data blob coming from IMDS is empty; then that would work out fine;
[20:04] <AnhVoMSFT> thanks @rharper
[20:16] <blackboxsw> meena: http://ubottu.com/meetingology/logs/cloud-init/2020/cloud-init.2020-06-16-16.21.log.html  or our rendering of it here: https://cloud-init.github.io/
[20:20] <blackboxsw> AnhVoMSFT: and some cloud datasources have grown vendor-data which would act like pre-defined userdata for an instance which users can augment/extend/override with their own user-data
[20:21] <blackboxsw> see NoCloud/OpenStack/IBMCloud/Oracle datasources I think
[20:22] <blackboxsw> which could allow your platform to expose some pre-defined configuration
[20:29] <meena> blackboxsw: aah!thank you
=== vrubiolo1 is now known as vrubiolo
[22:31] <blackboxsw> Odd_Bloke: for tomorrow I fixed my daily build branch https://github.com/canonical/cloud-init/pull/435   had to run new-upstream-snapshot --skip-release instead of --update-patches on ubuntu/daily/xenial