=== tds3 is now known as tds
=== tds0 is now known as tds
=== cpaelzer__ is now known as cpaelzer
smoserhey. sorry if i'm off in the weeds https://github.com/canonical/cloud-init/pull/42613:39
smoseri fully realize that historically vmware administrators expect that they can execute arbitrary code inside guests.13:40
smoserand 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.13:41
=== tds6 is now known as tds
Odd_Blokesmoser: I don't think you're off in the weeds, I agree with your assessment (and line of questioning).14:07
meenaI'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 other14:12
meenai can imagine at least one of those teams, or their common department head, wanting to close that door14:15
=== waxfire2 is now known as waxfire
Odd_Blokeblackboxsw: 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:38
Odd_Blokerharper: 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.14:40
lucasmourablackboxsw, should we do a manual fix for this commit as well: https://git.launchpad.net/cloud-init/commit/?id=3e2f7356 ?15:05
meenaright, i got distracted reading that15:16
rharperOdd_Bloke: i'll look15:20
blackboxswfalcojr: 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
blackboxswmy plan is to reflect those changes into each manual cloud template after this PR land.15:39
rharperOdd_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 unstable15:42
rharperOdd_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 implementation15:43
smoserit should fail though.15:46
smoserif 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!"15:47
blackboxsw#startmeeting cloud-init status meeting16:21
meetingologyMeeting started Tue Jun 16 16:21:42 2020 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.16:21
meetingologyAvailable commands: action commands idea info link nick16:21
blackboxsw#chair smoser Odd_Bloke rharper16:22
meetingologyCurrent chairs: Odd_Bloke blackboxsw rharper smoser16:22
blackboxswWelcome to the bi-weekly cloud-init status meeting. A place to chat about upstream cloud-init activity/16:22
blackboxswhis meeting is a welcome place for interruptions, questions, requests and unrelated discussions at any point.16:23
blackboxswprevious meeting minutes are stored on github16:23
blackboxsw#link https://cloud-init.github.io/16:23
blackboxswThe 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
blackboxswFrom the previous meeting we captured no actions, so I'll jump into the next topic16:24
blackboxsw#topic Recent Changes16:24
blackboxswthe following are commits merged into cloud-init's upstream master branch: https://paste.ubuntu.com/p/WdsZXbwwWd/16:25
blackboxswfound via git log --since 06-02-202016:26
blackboxswnotable 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:29
blackboxswalso 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:30
blackboxswcommunity 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:31
blackboxsw#topic In-progress Development16:32
blackboxswUpstream 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:33
blackboxswWe 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
blackboxswTo track this release, anyone can subscribe to the SRU process bug16:34
blackboxsw#link https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/188101816:35
ubot5Ubuntu 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
blackboxswthat bug will go to Fix Released when our upload to <ubuntu-release>-updates apt pocket is published16:35
blackboxswBeyond 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:36
blackboxsw#link https://github.com/canonical/cloud-init/pull/39116:37
blackboxswThanks Odd_Bloke for driving that refactor. Those interested should check out the above PR16:38
blackboxswI think that about wraps it.16:39
meenaduring the util.subp refactor i suggested also looking into centralising service enabling and (re) starting16:40
meenabut we kinda glossed over that because of the net refactor16:41
blackboxswmeena: good chance to bring that up: let's get that comment link16:41
blackboxsw#link https://github.com/canonical/cloud-init/pull/416#issuecomment-64003296816:43
blackboxswmeena: your comment was really about re-organizing the ./systemd ./upstart top-level directories and refactoring down into the distros somehow?16:44
blackboxswas that startup service construct is highly distro dependent?16:44
blackboxswIf 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:46
blackboxswgiven 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 linux16:48
blackboxswI think that refactor would be significantly simpler to describe in a distro-level API16:49
blackboxswmeena: maybe we file a feature bug against cloud-init so we can prioritize that work.16:51
meenayou're right. let's do that16:51
blackboxswwe could surface that bug to the mailinglist16:52
blackboxswmeena: 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 services16:53
meetingologyACTION: file feature bug about refactoring startup services16:53
blackboxsw#action mailing list email requesting comment/concerns about a refactor of startup services16:53
meetingologyACTION: mailing list email requesting comment/concerns about a refactor of startup services16:53
blackboxswI've added actions that we can track by next meeting to see if we can make progress on that discussion16:54
blackboxswok next topic I think16:54
blackboxsw#topic community charter16:54
blackboxswAs always, any aspects of the cloud-init project is open for participation from community members.16:55
blackboxswWe 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/pulls16:56
blackboxswall reviews are welcome on any PRs that are up. and driving feature discussions are also encouraged. Thanks meena for participating on all of those fronts16:57
blackboxswfor 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=bitezise16:59
blackboxsw#topic Office Hours (~next 30 minutes)16:59
blackboxswThis '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:00
blackboxswIn the absence of discussion topics, reviewing the active PRs generally occurs to scrub our queue and unblock conversations.17:01
* blackboxsw addresses some review comments on a CI Ubuntu daily test branch17:02
AnhVoMSFTquestion: is there anyway to only target a particular reporting handler?17:22
AnhVoMSFTRight 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:23
blackboxswhrm, good question AnhVoMSFT . looking17:30
Odd_Blokeblackboxsw: 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:33
blackboxswnice suggestion Odd_Bloke17:42
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:43
* cyberpear wondering if there's any collaboration with the ignition folks17:44
blackboxswAnhVoMSFT: I think it's be reasonable to provide a named report handler to ReportEventStack17:46
blackboxswand let ReportEventStack limit what handlers it can emit publish_event to17:46
meenahttps://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:48
blackboxswAnhVoMSFT: that'd mean I suppose that report_event would need to accept a new param to limit which handler it calls handler.publish_event  for17:50
meenahttps://github.com/canonical/cloud-init/blob/master/cloudinit/config/cc_rsyslog.py#L210 one more17:52
blackboxswor 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:52
blackboxswand here meena https://github.com/canonical/cloud-init/blob/master/cloudinit/config/cc_fan.py#L55-L8317:54
blackboxswok I've got to run.   time to close the meeting for today. Thanks all for joining in!17:58
meetingologyMeeting ended Tue Jun 16 17:58:32 2020 UTC.17:58
meetingologyMinutes:        http://ubottu.com/meetingology/logs/cloud-init/2020/cloud-init.2020-06-16-16.21.moin.txt17:58
AnhVoMSFT@blackboxsw I think we will look into adding a new param to report_event17:58
AnhVoMSFTso that it can emit only to a certain handler and does not go through all the available_hanlder17:59
AnhVoMSFT(probably adding a new param indicating a new filter list)17:59
blackboxswAnhVoMSFT: that makes sense to me. So, you'd avoid using the ReportEventStack context manager with  that as well?18:10
blackboxswor do you plan to also use the context manager?18:10
AnhVoMSFTI have not looked that far to be honest. Will take a look later this week and start some POC19:09
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 VM19:43
meenadoes the meetingology text exist in formated?19:45
rharperAnhVoMSFT: 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 merging19:51
rharperAnhVoMSFT: If the user-data blob coming from IMDS is empty; then that would work out fine;19:51
AnhVoMSFTthanks @rharper20:04
blackboxswmeena: 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:16
blackboxswAnhVoMSFT: 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-data20:20
blackboxswsee NoCloud/OpenStack/IBMCloud/Oracle datasources I think20:21
blackboxswwhich could allow your platform to expose some pre-defined configuration20:22
meenablackboxsw: aah!thank you20:29
=== vrubiolo1 is now known as vrubiolo
blackboxswOdd_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/xenial22:31

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!