16:30:25 <bgilbert> #startmeeting fedora_coreos_meeting
16:30:25 <zodbot> Meeting started Wed Oct 24 16:30:25 2018 UTC.
16:30:25 <zodbot> This meeting is logged and archived in a public location.
16:30:25 <zodbot> The chair is bgilbert. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:25 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:30:34 <lorbus> .hello2
16:30:35 <zodbot> lorbus: lorbus 'Christian Glombek' <cglombek@redhat.com>
16:30:37 <bgilbert> #topic roll call
16:30:45 <sayan> .hello sayanchowdhury
16:30:46 <zodbot> sayan: sayanchowdhury 'Sayan Chowdhury' <sayan.chowdhury2012@gmail.com>
16:30:47 <bgilbert> .hello2
16:30:52 <mskarbek> .hello2
16:30:52 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:30:56 <zodbot> mskarbek: mskarbek 'None' <redhat@skarbek.name>
16:30:58 <dustymabe> .hello2
16:30:59 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:30:59 <ajeddeloh> .hello2
16:31:01 <zodbot> ajeddeloh: ajeddeloh 'Andrew Jeddeloh' <andrew.jeddeloh@redhat.com>
16:31:04 <slowrie> .hello2
16:31:05 <zodbot> slowrie: slowrie 'Stephen Lowrie' <slowrie@redhat.com>
16:31:15 <ksinny> .hello sinnykumari
16:31:15 <kaeso> .hello lucab
16:31:16 <zodbot> ksinny: sinnykumari 'Sinny Kumari' <ksinny@gmail.com>
16:31:19 <zodbot> kaeso: lucab 'Luca Bruno' <lucab@redhat.com>
16:31:24 <bhavin192> .hello2
16:31:25 <zodbot> bhavin192: bhavin192 'Bhavin Gandhi' <bhavin7392@gmail.com>
16:31:47 <geoff-> geoff- Geoff Levand <geoff@infradead.org>
16:33:40 <bgilbert> #chair lorbus sayan mskarbek dustymabe ajeddeloh slowrie ksinny kaeso bhavin192 geoff-
16:33:40 <zodbot> Current chairs: ajeddeloh bgilbert bhavin192 dustymabe geoff- kaeso ksinny lorbus mskarbek sayan slowrie
16:34:06 <rfairley> .hello rfairleyredhat
16:34:07 <zodbot> rfairley: rfairleyredhat 'Robert Fairley' <rfairley@redhat.com>
16:34:37 <mnguyen_> .hello mnguyen
16:34:38 <zodbot> mnguyen_: mnguyen 'Michael Nguyen' <mnguyen@redhat.com>
16:34:52 <dustymabe> good to see so many faces!
16:35:18 <bgilbert> #chair rfairley mnguyen_
16:35:18 <zodbot> Current chairs: ajeddeloh bgilbert bhavin192 dustymabe geoff- kaeso ksinny lorbus mnguyen_ mskarbek rfairley sayan slowrie
16:35:23 <bgilbert> #topic Action items from last meeting
16:35:55 <bgilbert> * bgilbert to PR the design doc and open tickets for backport-related questions
16:36:12 <bgilbert> ...hasn't happened yet
16:36:16 <bgilbert> #action bgilbert to PR the design doc and open tickets for backport-related questions
16:36:22 <dustymabe> +1
16:36:32 <bgilbert> * ajeddeloh and lorbus to experiment on grubenv + static grub config
16:36:59 <ajeddeloh> haven't gotten to the point where we can yet I don't think
16:37:36 <bgilbert> should we re-#action?
16:37:37 <lorbus> agree
16:37:41 <ajeddeloh> +!
16:37:44 <ajeddeloh> +1*
16:37:50 <lorbus> +1
16:37:51 <bgilbert> #action ajeddeloh and lorbus to experiment on grubenv + static grub config
16:38:21 <bgilbert> #topic meeting times and daylight savings
16:38:26 <bgilbert> #info https://github.com/coreos/fedora-coreos-tracker/issues/57
16:38:48 <bgilbert> blargh
16:38:50 <bgilbert> #link https://github.com/coreos/fedora-coreos-tracker/issues/57
16:39:06 <dustymabe> so we haven't had any objections
16:39:17 <dustymabe> i think we can mark it as decided and close it out
16:39:23 <kaeso> ack
16:39:33 <sayan> +1
16:39:39 <slowrie> +1
16:39:44 <ajeddeloh> +1
16:40:17 <ksinny> +1
16:40:25 <mskarbek> +1
16:40:32 <lorbus> +1
16:40:51 <bgilbert> cool
16:40:58 <bgilbert> #topic Determine how to handle automatic rollback
16:41:05 <bgilbert> #link https://github.com/coreos/fedora-coreos-tracker/issues/47
16:41:26 * ajeddeloh has nothing we didn't discuss last time
16:41:43 <dustymabe> +1 we should probably remove the meeting label for this one
16:42:11 <kaeso> (I didn't in case we had some grub cfg news)
16:42:23 <ajeddeloh> +1, we can re-add it if we get something new
16:42:49 <lorbus> yup I think the grub cfg topic needs to be covered first
16:43:26 <bgilbert> okay, that's all of the `meeting` tickets
16:43:29 <bgilbert> #topic Open Floor
16:43:52 * dustymabe would like to start talking about the cloud agents and cloud specific bits in the future
16:44:19 <slowrie> dustymabe: is there a particular agent you want to talk about?
16:44:22 <ajeddeloh> +1, also we need to start talking about building the replacement for roller
16:44:22 <dustymabe> which are https://github.com/coreos/fedora-coreos-tracker/issues/12 (already decided)
16:44:24 <slowrie> or just in general
16:44:34 <dustymabe> and https://github.com/coreos/fedora-coreos-tracker/issues/41
16:44:41 <dustymabe> slowrie: in general
16:44:55 <dustymabe> I think we have already decided to try to not ship cloud agents (#12)
16:45:32 <dustymabe> but I think we decided that before the design doc existed so we haven't added it to the design doc
16:45:35 * dustymabe checks on that
16:45:51 <bgilbert> if we ended up shipping waagent rather than reimplementing, that would collide with the platform-Python discussion
16:45:51 <dustymabe> oh no, it is in there
16:45:57 <dustymabe> https://github.com/coreos/fedora-coreos-tracker/blob/master/Design.md#cloud-agents
16:46:19 <slowrie> bgilbert: at that point couldn't we just run it in a container?
16:46:35 <kaeso> quick update from my side in the context of https://github.com/coreos/fedora-coreos-tracker/issues/37
16:46:55 <bgilbert> slowrie: CL doesn't do that now; not sure if there's a reason for that
16:47:25 <dustymabe> ok so we've decided we don't want to ship any cloud agents (#12) - should we start to look at each cloud and see what gaps we are going to have and start investigating how to resolve them?
16:47:35 <slowrie> might be worth exploring if it ends up being too much of a maintenance issue implementing a network agnostic implementation in coreos-metadata
16:47:36 <kaeso> some offline discussion on how to better integrate Ignition and portable services resulted in https://github.com/systemd/systemd/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3A%22RFE+%F0%9F%8E%81%22+label%3Aportable
16:47:58 <dustymabe> #chair utlemming
16:47:58 <zodbot> Current chairs: ajeddeloh bgilbert bhavin192 dustymabe geoff- kaeso ksinny lorbus mnguyen_ mskarbek rfairley sayan slowrie utlemming
16:48:03 * dustymabe waves a utlemming
16:48:17 <kaeso> (i.e. a few feature requests for portablectl that Lennart will be happy to land)
16:48:25 <utlemming> lol :)
16:48:25 <bgilbert> oh yeah, slowrie, want to mention the issue there?
16:48:35 <ajeddeloh> kaeso: just FYI I'm pushing hard for 3.0.0 to _just_ be a compat-breaking fixup spec change
16:48:55 <bgilbert> s/mention the issue there/describe the problem/
16:48:57 <slowrie> bgilbert: sorry, mention it where? issue #12?
16:49:02 <slowrie> oh
16:49:03 <kaeso> ajeddeloh: just as in "no features added"?
16:49:14 <ajeddeloh> yeah, it's already gunna be hairy
16:49:17 <ajeddeloh> 3.1.0 though
16:49:31 <dustymabe> kaeso: do you want to add a short update to #37 with the information you posted here?
16:49:45 <ajeddeloh> no reason we can't add it there or start planning what the spec looks like
16:49:50 <kaeso> dustymabe: yes, I just realized I should have done that earlier
16:49:55 <dustymabe> kaeso: +1
16:49:59 <slowrie> yeah, so the way that azure sends out the IP address of the metadata server is via DHCP option 254. Currently coreos-metadata parses the DHCP options but assumes networkd. I need to do more investigating into the specifics to find out if it's something that we can have work on both networkd & NetworkManager systems
16:50:22 <dustymabe> #action kaeso to add summary of discussion with lennart re: portable services to #37
16:50:38 <kaeso> ajeddeloh: makes sense. Apart from shaking the JSON schema I don't think we have any urgent new feature pending, right?
16:50:51 <ajeddeloh> right
16:50:53 <slowrie> As far as we know currently, the main thing we'd need to have to replace waagent is a phone-home style service that sends a request to said metadata server after each boot saying the system is good to go
16:51:21 * ajeddeloh needs to look over the docs the azure folks sent to me/benjamin
16:51:40 <bgilbert> specifically, coreos-metadata parses the networkd state file.  apparently waagent handles this by making its own DHCP request and parsing the option out of the response
16:51:45 <slowrie> ajeddeloh: are the docs around the metadata service or the release API?
16:51:51 <kaeso> slowrie: I saw your question somewhere else, is that metadata endpoint different than the metadata endpoint used by coreos-metadata?
16:52:20 <slowrie> kaeso: it's the same option, the issue is just how coreos-metadata is acquiring it (the networkd state file as bgilbert mentioned)
16:52:26 <ajeddeloh> slowrie: around what a machine needs to do to be a good azure citizen
16:52:27 <kaeso> ah, bgilbert answered that in the meanwhile
16:52:41 <ajeddeloh> I think, haven't gotten in to them yet
16:53:21 <slowrie> +1 if you come across anything else we'd please reach out
16:53:44 <ajeddeloh> I know the old coreos-metadata (golang) just parsed some networkd file that started with DO NOT PARSE to get it
16:54:00 <slowrie> probably /run/systemd/netif/leases
16:54:02 <ajeddeloh> dunno if that changed since the rust rewrite
16:54:02 <bgilbert> I think the new one does the same
16:54:16 <dustymabe> anyone object to me opening tickets for individual clouds where we can document gaps/strategy ?
16:54:26 <slowrie> dustymabe: +1
16:54:41 <bgilbert> dustymabe: +1
16:54:58 <bgilbert> maybe we should add a label for those
16:55:24 <slowrie> The main two imo are going to be vmware & azure
16:55:39 <ajeddeloh> gce might not be super happy either
16:55:52 <dustymabe> #action dustymabe to open tickets for individual clouds so that we can document gaps/strategy for not shipping cloud agents (#12)
16:55:53 <slowrie> ah yeah, forgot about the gce stuff
16:56:31 <dustymabe> i'll ask a quick dumb question
16:56:31 <kaeso> ajeddeloh: indeed https://github.com/coreos/coreos-metadata/blob/7727d92652cba9dbf2d3a01710187ceaf980486f/src/util/mod.rs#L65
16:56:53 <dustymabe> is "coreos-metadata" here something we would ever foresee someone else wanting to use?
16:57:08 <bgilbert> dustymabe: yes.  we've talked about renaming it.
16:57:12 <dustymabe> one example is that we are having more people looking at using ignition (not just fedora coreos)
16:57:22 <dustymabe> bgilbert: +1 ok cool
16:57:23 <kaeso> opensuse packaged it already, I think
16:57:24 <dustymabe> good to know
16:57:24 <bgilbert> I've asked around a bit and apparently there's no actual reason it's CL-specific
16:57:26 <slowrie> dustymabe: yes, it should be renamed but it has a lot of value especially when writing systemd services via Ignition that have runtime specific values
16:57:47 <bgilbert> s/it's/for it to be/
16:58:09 <dustymabe> +1 thanks for the info
16:58:13 <bgilbert> there is that bit of networkd state parsing, but otherwise I think the CL-specific bits are the naming of the environment vars it produces
16:58:42 <dustymabe> maybe we can bikeshed in a ticket
16:58:42 <jlebon> .hello2
16:58:46 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:58:47 <kaeso> there are a few assumption about CL, yes
16:58:53 <slowrie> #chair jlebon
16:58:53 <zodbot> Current chairs: ajeddeloh bgilbert bhavin192 dustymabe geoff- jlebon kaeso ksinny lorbus mnguyen_ mskarbek rfairley sayan slowrie utlemming
16:59:08 <dustymabe> #action jlebon to update entire infrastructure to fedora coreos and document update strategy
16:59:11 <dustymabe> anything else?
16:59:16 <kaeso> but I would not go through de-prefixing "coreos-" everywhere
16:59:34 <jlebon> dustymabe: :)
16:59:36 <dustymabe> #undo
16:59:36 <zodbot> Removing item from minutes: ACTION by dustymabe at 16:59:08 : jlebon to update entire infrastructure to fedora coreos and document update strategy
16:59:38 <dustymabe> :)
16:59:58 <kaeso> I doesn't mean it's specific to CL, just that we namespace our projects
17:00:00 <bgilbert> .chair dustymabe
17:00:00 <zodbot> dustymabe is seated in a chair with a nice view of a placid lake, unsuspecting that another chair is about to be slammed into them.
17:00:08 <bgilbert> :)
17:00:10 <kaeso> lol
17:00:21 <dustymabe> haha
17:00:36 <jlebon> not sure if this was talked about already, though ajeddeloh and I have been talking a lot about supporting separate /var recently
17:00:45 <ajeddeloh> oh yeah
17:00:48 <slowrie> it has not been talked about yet
17:01:07 <ajeddeloh> no, it has impact on how Ignition works
17:01:33 <jlebon> we're hopefully gonna have some good ideas soon :)
17:01:36 <ajeddeloh> basically the current files stage has conflicting requirements
17:01:39 <dustymabe> #link https://github.com/dustymabe/ignition-dracut/issues/18
17:02:14 <kaeso> ajeddeloh: I think jlebon just sorted that out today
17:02:42 <ajeddeloh> kaeso: oh?
17:02:42 <kaeso> #link https://github.com/dustymabe/ignition-dracut/pull/26
17:02:54 <jlebon> kaeso: that was mostly prep for the next stage towards supporting /var
17:03:03 <jlebon> the conflict that ajeddeloh is talking about is a different one
17:03:33 <kaeso> ah, sorry then, I thought it was the disks-ostree-files ordering
17:03:38 <ajeddeloh> adding users must have /var mounted for home directories
17:03:57 <ajeddeloh> but the filesystemEntries part (links, dirs, files) cannot
17:04:25 <jlebon> so we're discussing splitting those out into separate stages
17:04:43 <ajeddeloh> otherwise you could say "writ this file to X on the root filesystem" and end up writing it to the var file filesystem, which is a breach of the ignition semantics
17:04:57 <ajeddeloh> have disks, users, files
17:05:45 <dustymabe> seems reasonable to me
17:05:53 <ajeddeloh> we already have to do users before files for creating files owned by users created by Ignition
17:06:13 <bgilbert> ajeddeloh: why can't filesystemEntries have /var mounted?
17:06:41 <ajeddeloh> bgilbert: lets say my config says a file should be on filesystem root, path /var/foo
17:07:04 <ajeddeloh> if /var is at /sysroot/var then that file doesn't get written to the correct fs
17:07:53 <bgilbert> will users need to create nodes that will be shadowed by a mount?
17:08:14 <ajeddeloh> dunno
17:08:29 <ajeddeloh> we could change the meaning of filesystem.path
17:08:44 <bgilbert> rather than adding another stage, we could detect that case (different st_dev) and fail
17:08:54 <bgilbert> and add the stage later if actually needed
17:09:32 <ajeddeloh> that's also a possibilty
17:10:32 <bgilbert> anything else for open floor?
17:10:52 <bgilbert> closing meeting in 2m
17:12:52 <bgilbert> #endmeeting