17:02:11 <roshi> #startmeeting atomic_wg
17:02:11 <zodbot> Meeting started Wed Mar  1 17:02:11 2017 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:02:11 <zodbot> The meeting name has been set to 'atomic_wg'
17:02:20 <roshi> #topic Roll Call
17:02:23 <kushal> .hellomynameis kushal (one hand typist)
17:02:24 <zodbot> kushal: Sorry, but you don't exist
17:02:27 <kushal> heh
17:02:30 <kushal> .hellomynameis kushal
17:02:31 <zodbot> kushal: kushal 'Kushal Das' <mail@kushaldas.in>
17:02:31 <dustymabe> .hellomynameis dustymabe
17:02:33 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dustymabe@redhat.com>
17:02:36 <trishnag> .hello trishnag
17:02:37 <zodbot> trishnag: trishnag 'Trishna Guha' <trishnaguha17@gmail.com>
17:02:40 <roshi> .hello roshi
17:02:40 <jhogarth> .hellomynameis jhogarth
17:02:41 <zodbot> roshi: roshi 'Mike Ruckman' <mruckman@redhat.com>
17:02:44 <zodbot> jhogarth: jhogarth 'James Hogarth' <james.hogarth@gmail.com>
17:03:08 <tflink> .hello tflink
17:03:09 <zodbot> tflink: tflink 'Tim Flink' <tflink@redhat.com>
17:03:13 * tflink is lurking
17:03:28 <miabbott> .hello miabbott
17:03:29 <zodbot> miabbott: miabbott 'Micah Abbott' <miabbott@redhat.com>
17:03:35 <roshi> #chair dustymabe kushal trishnag jhogarth miabbott
17:03:35 <zodbot> Current chairs: dustymabe jhogarth kushal miabbott roshi trishnag
17:03:43 * miabbott also lurks
17:03:53 <roshi> welcome all, let's get down to it then
17:03:58 <ksinny> .hello ksinny
17:04:00 <zodbot> ksinny: Sorry, but you don't exist
17:04:16 <roshi> #topic Decide on version scheme for F26
17:04:17 <dustymabe> welcome ksinny jhogarth all
17:04:19 <ksinny> .hello sinnykumari
17:04:19 <roshi> #link https://pagure.io/atomic-wg/issue/229
17:04:21 <zodbot> ksinny: sinnykumari 'Sinny Kumari' <ksinny@gmail.com>
17:04:29 <walters_> .hello walters
17:04:31 <zodbot> walters_: walters 'Colin Walters' <walters@redhat.com>
17:04:37 * ksinny mostly in listening mode
17:04:41 <dustymabe> roshi: do we have any action items from last meeting?
17:04:49 <trishnag> ksinny: o/
17:04:49 <jbrooks> .fas jasonbrooks
17:04:50 <zodbot> jbrooks: jasonbrooks 'Jason Brooks' <JBROOKS@REDHAT.COM>
17:04:50 <roshi> bah, I always forget to check that
17:04:56 * dustymabe remembers signing up for at least one thing that I didn't do
17:05:02 <ksinny> trishnag: hey!
17:05:29 <sayan> .hello sayanchowdhury
17:05:31 <zodbot> sayan: sayanchowdhury 'Sayan Chowdhury' <sayan.chowdhury2012@gmail.com>
17:05:39 <jlebon> .hello jlebon
17:05:40 <zodbot> jlebon: jlebon 'None' <jlebon@redhat.com>
17:06:00 <jberkus> .hello jberkus
17:06:01 <zodbot> jberkus: jberkus 'Josh Berkus' <josh@agliodbs.com>
17:06:06 <roshi> #topic Previous Meeting Follow-Up
17:06:13 <roshi> woah, full meeting today :)
17:06:22 <roshi> action items from last week:
17:06:38 <roshi> * jberkus to open issues around each proposed dockerfile requirements change
17:06:44 <roshi> * dusty to close Future of Fedora Dockerfiles #180
17:06:50 <roshi> * dusty to create atomic-wg page for future VFAD topics
17:06:56 <roshi> * jberkus to follow-up with misc and quaid about location of HW
17:07:01 <roshi> * jberkus to create vfad idea list page
17:07:05 <roshi> * sayan to create ticket on moving fedimg from libcloud to boto
17:07:12 <roshi> welcome all :)
17:07:21 <jberkus> can we bump my items by 5min? finishing up call
17:07:36 <dustymabe> i closed #180 - did not create VFAD page yet
17:07:50 <roshi> sure thing jberkus
17:08:01 <dustymabe> #action dusty to create atomic-wg page for future VFAD topics
17:08:37 <dustymabe> sayan: did you open that ticket?
17:08:50 <sayan> dustymabe: not yet
17:09:41 <dustymabe> #action sayan to create ticket on moving fedimg from libcloud to boto
17:09:45 <dustymabe> mind trying to do that today
17:09:56 <dustymabe> ok we'll come back to jberkus
17:10:23 <roshi> #topic F26 naming scheme
17:10:25 <roshi> #link https://pagure.io/atomic-wg/issue/229
17:11:06 <walters_> 🚳shed
17:11:26 <dustymabe> so really we have decided in the ticket what we'd like to ostree versions to look like
17:11:43 <dustymabe> the limitation is now just seeing what contstraints we have to work within to achieve our goals
17:12:10 <sayan> dustymabe: I was actually wondering where to create the ticket :)
17:12:24 <roshi> I don't have an opinion, I just want to understand whatever we land on
17:12:28 <dustymabe> sayan, you can make it on the atomic-wg if you like
17:12:46 <sayan> Okay
17:12:48 <walters> dustymabe, ostree version is `$major.$datestamp.$serial` ?
17:13:12 <dustymabe> walters: yeah, I think that is where we were leaning in the ticket
17:13:22 <walters> i'm OK with that, but it's useful to note ostree commits already have datestamps, and rpm-ostree shows that by default too
17:13:38 <roshi> that makes sense enough to me
17:13:52 <walters> so `$major.$serial` would work equally well IMO
17:14:06 <jberkus> ok, full attention now, sorry
17:14:10 <walters> which i guess is actually what we do today
17:14:10 <roshi> right, but having it in the image name makes sense because that's what a lot of us see most of the time
17:14:49 <roshi> working with the new images, and having hdds full of a year or more qcow and isos (as is my case)
17:14:51 <walters> roshi, agreed, if the ostree version doesn't have the date embedded, we should indeed use the pungi one in the name
17:14:56 <kushal> roshi +1 to that.
17:14:59 <bowlofeggs> .hello bowlofeggs
17:15:00 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <randy@electronsweatshop.com>
17:15:03 <bowlofeggs> (bowloflateeggs)
17:15:03 <dustymabe> so walters the one thing that is nice about having the ostree version be time based is that our current scheme of updating the updates ref every night and then promoting the two week ref at release time
17:15:18 <dustymabe> is that our two week releases don't look odd
17:15:23 <jberkus> VFAD ideas page
17:15:27 <jberkus> https://fedoraproject.org/wiki/Cloud/VFAD_ideas
17:15:33 <walters> dustymabe, can you elaborate on "odd"?
17:15:34 <dustymabe> i.e. jumping from 25.47 to 25.64
17:15:41 <roshi> jberkus: we'll go back to the action items after this
17:15:46 <trishnag> #link https://fedoraproject.org/wiki/Cloud/VFAD_ideas
17:15:47 <walters> i don't understand...we do in fact jump versions
17:16:02 <dustymabe> right
17:16:03 <walters> oh you mean if it was a date stamp
17:16:08 <dustymabe> yeah
17:16:19 <walters> so this is something https://github.com/cgwalters/ostree-releng-scripts/blob/master/do-release-tags fixes
17:16:22 <dustymabe> it would look "less odd" - the underlying tech and process would be the same
17:16:32 <jberkus> walters: the problme is that I can't install an ostree release by date stamp
17:16:37 <jberkus> I have to know the number
17:16:55 <walters> or the commit hash, yes
17:17:10 <jberkus> right, and since we have no catalog ...
17:17:48 <walters> jberkus, the versions and commit hashes are in the release emails now
17:17:57 <walters> and at some point we should fix the web page to show them
17:18:01 <dustymabe> let's be constructive - so basically do you think having the time in the version is a bad idea?
17:18:05 <dustymabe> or a good idea
17:18:07 <walters> like https://wiki.centos.org/SpecialInterestGroup/Atomic/Devel
17:18:26 <walters> i wouldn't say it's a bad idea
17:18:35 <dustymabe> k
17:18:43 <roshi> proposed #agreed - use the $major.$datestamp.$serial for F26 and close the ticket.
17:18:44 <jberkus> dustymabe: pro: makes it easy to have multiple releases per day in case something blows up
17:18:56 <roshi> +1s or acks?
17:19:10 <dustymabe> jberkus: this change doesn't make it easy for that
17:19:16 <jberkus> ah, ok
17:19:22 <dustymabe> we can already have multiple ostree builds per day
17:19:28 <jberkus> wait, if we're going to have a serial, why bother with the time?
17:19:43 <dustymabe> "serial" resets with the day
17:19:53 <jbrooks> I don't see the value of time, tbh
17:19:59 <walters> maybe just drop the .serial unless it'd be nonzero
17:19:59 <jberkus> neither do I
17:20:02 <jbrooks> But I don't care if it's there
17:20:08 <roshi> +1 to walters
17:20:10 <jberkus> walters: easier to have a stable format
17:20:15 <roshi> was going to say the same thing
17:20:19 <dustymabe> the serial is there for days where we need to build ostree repo twice
17:20:33 <dustymabe> or many times
17:20:41 <dustymabe> 20170301.0
17:20:43 <dustymabe> then .1
17:20:44 <dustymabe> then .2
17:20:45 <jberkus> walters: regexing for "serial is present" is much harder than 'serial is non-zero"
17:21:08 <roshi> but checking len() is easy :)
17:21:09 <walters> so i think my vote here is `$major.$datestamp.$serial` until we revisit tree promotion for 256
17:21:10 <walters> 26
17:21:13 <dustymabe> nobody is going to be searching for this value
17:21:23 <jlebon> really, we'd be fine either way -- the one thing that i like about embedding the timestamp is that other artifacts like qcow2s can be matched up right away
17:21:30 <jberkus> hmmm, none of this gets us out of needing a catalog, does it?
17:21:52 <dustymabe> jberkus: not really
17:21:59 <roshi> nope, but I'm in the same boat as jlebon about the other artifacts
17:22:02 <dustymabe> i mean this would make it more discoverable
17:22:24 <dustymabe> like i could guess that the ostree built today was 20170301.0
17:22:25 <jlebon> jberkus: an "rpm-ostree upgrade" always gives you the latest version. if you want to jump to a specific version, then you must have seen it somewhere, right?
17:22:27 <dustymabe> and probably be right
17:22:48 <jberkus> jlebon: sometimes it's "oh, that's broken, let me try the version before this one"
17:22:49 <jlebon> you can also inspect for whatever the latest version is without pulling
17:22:50 <dustymabe> jlebon: unless you want to jump to a version that was 10 days ago
17:23:03 <dustymabe> jberkus: you can add a ^ to your commit
17:23:14 <dustymabe> and that will give you the "parent commit"
17:23:21 <jberkus> dustymabe: yeah?  for the hash?
17:23:25 <dustymabe> yeah
17:23:29 <jberkus> dustymabe: can you blog that?
17:23:41 <jberkus> short, just a para and an example
17:23:56 <jlebon> (though note that won't be the last released TWR, but the last nightly)
17:24:03 <jberkus> oh
17:24:46 <jberkus> back to topic: jlebon explain about matching other artifacts?
17:24:49 <dustymabe> ok we're getting a bit off in the weeds
17:24:53 <roshi> so +1/-1 votes for $major.$datestamp.$serial ?
17:25:08 <jberkus> roshi: I can't vote until I have an answer to the above question
17:25:09 <miabbott> +1 for $major.$datestamp.$serial
17:25:10 <jlebon> +1
17:25:13 <trishnag> +1
17:25:26 <dustymabe> what's the question?
17:25:35 <roshi> the timestamp would be in the names of the raw and qcow images
17:25:44 <jberkus> matching other artifacts that have a time attached.  is it a thing?
17:25:47 <roshi> so for doing install testing or image testing, it's a reall boon
17:25:55 <trishnag> dustymabe:  +1/-1 votes for $major.$datestamp.$serial ?
17:26:18 <jlebon> jberkus: i just meant it's easier to know which commit to expect given a pungi timestamp
17:26:20 <dustymabe> jberkus: I don't understand what you're asking
17:26:22 <jberkus> because if there's some way that having .time instead of .serial makes testing easier, I'm for it
17:26:23 <roshi> jberkus: does that answer the question?
17:27:00 <jberkus> if there isn't, then I'm for .serial
17:27:20 <roshi> +1 to the proposed
17:27:32 <roshi> I'm showing +4 and -0
17:27:42 <roshi> #agreed - use the $major.$datestamp.$serial for F26 and close the ticket.
17:27:46 <roshi> next topic
17:27:56 <roshi> we're going to run out of time at this rate :p
17:28:16 <dustymabe> jberkus: grab us in #fedora-cloud
17:28:18 <jberkus> roshi: few discussions longer than naming things
17:28:31 <roshi> one of the hardest things in computers :P
17:28:39 <jberkus> so, next topic?
17:28:43 <roshi> #topic Planning first atomic VFAD
17:28:45 <roshi> #link https://pagure.io/atomic-wg/issue/201
17:29:02 <roshi> I thought this one was closed already? we had it
17:29:18 <jberkus> yes.  close?
17:29:20 <roshi> moving on
17:29:26 <dustymabe> yeah - i think the only thing left is figuring out our structure going forward
17:29:37 <dustymabe> i'm creating a page for that
17:29:43 <roshi> structure for what?
17:29:47 <jberkus> also creating a list of scheduled VFADs
17:29:56 <roshi> yeah, that's not this ticket though
17:30:06 <roshi> #topic Ship fedora-motd
17:30:08 <roshi> #link https://pagure.io/atomic-wg/issue/160
17:31:14 <dustymabe> i feel bad but we really haven't done due diligence on this ticket because we are working on a bunch of other "foundational" stuff right now
17:31:26 <dustymabe> skip, for now
17:31:31 <kushal> dustymabe, next week we can do one about writing more tests
17:31:39 <kushal> vFAD I mean.
17:32:12 <jberkus> kushal: add it to the list of vFAD ideas: https://fedoraproject.org/wiki/Cloud/VFAD_ideas
17:32:19 <kushal> I will, thanks
17:32:58 <dustymabe> damn
17:33:13 <dustymabe> can we actually just add that as a page to our pagure instance?
17:33:30 <dustymabe> wiki is a black hole to me
17:33:44 <roshi> shouldn't that be under the Atomic space not the Cloud space?
17:33:46 <jberkus> dustymabe: I don't care where it is as long as we can find it again / edit it easily
17:33:53 <jberkus> roshi: do we have an Atomic space?
17:34:11 <roshi> yeah, just change the link s/Cloud/Atomic/
17:34:55 <roshi> thanks jberkus
17:35:18 <jberkus> ok, moving now
17:35:22 <jberkus> please stop editing
17:35:54 <jberkus> done: https://fedoraproject.org/wiki/Atomic/VFAD_ideas
17:35:59 <roshi> votes to skip this topic until next time?
17:36:16 <dustymabe> yes, move on
17:36:16 <jberkus> next
17:36:49 <roshi> #topic Fedora OpenShift Playground (FOSP)
17:36:51 <roshi> #link https://pagure.io/atomic-wg/issue/153
17:38:07 <jberkus> this is related to my action item
17:38:14 <jberkus> so, still waiting on hardware
17:38:57 <dustymabe> next
17:39:10 <roshi> #info Still waiting on hardware for the FOSP efforts
17:39:17 <roshi> #topic Open Floor
17:39:25 <roshi> that's all the items we had for today
17:39:28 <jberkus> I expect to have a racking date for the HW next week
17:39:32 <roshi> anyone have anything for open floor?
17:39:45 <jberkus> do we want to discuss rolling upgrades?
17:39:49 * roshi is still on track to have our tests running in taskotron by the end of the week
17:39:55 <dustymabe> jberkus: no
17:40:01 <dustymabe> I think we need a dedicated time for that
17:40:02 <roshi> lol
17:40:14 <jberkus> ok.  in the meantime, folks, please comment on this issue: https://pagure.io/atomic-wg/issue/231
17:40:17 <dustymabe> or we'll basically run out the end of the meeting
17:40:34 <dustymabe> i have a few items for open floor
17:40:54 <dustymabe> 1. we just did an atomic 2 wk release today
17:41:04 <roshi> sweet
17:41:13 <jberkus> yay!
17:41:14 <dustymabe> 2. we have a ton of container reviews/policy decisions that are starting to get thrown at us
17:41:29 <jberkus> dustymabe: yeah, I know, I'm way behind on that
17:41:36 <dustymabe> i have started tagging things with "containers"
17:41:38 <dustymabe> https://pagure.io/atomic-wg/issues?status=Open&tags=containers
17:41:48 <dustymabe> so here is the problem
17:41:58 <dustymabe> if we become a bottleneck, which we are at this point
17:42:06 <dustymabe> people are going to get frustrated and not contribute
17:42:13 <dustymabe> how do we overcome this?
17:42:24 <dustymabe> there is a container best practices team in red hat
17:42:32 <dustymabe> can we get some more people involved in the reviews?
17:42:36 <roshi> we need to define a few things at the very least I think
17:42:48 <jberkus> dustymabe: is there a CBP team?
17:42:49 <roshi> what's required to be a reviewer?
17:42:54 <jberkus> dustymabe: last I checked that was unstaffed
17:43:09 <roshi> are all the docs up to date on steps to take
17:43:10 <dustymabe> jberkus: I think there is. there are at least guidelines, and somebody created those
17:43:23 <jberkus> dustymabe: yeah, but that team moved on ~~ 6 months ago
17:43:40 <dustymabe> well either way, we need people with container expertise to help us do reviews
17:44:06 <dustymabe> i'm bad about this myself, since I haven't done a review yet
17:44:19 <dustymabe> but either way, let's try to think of people that might be able to help us
17:44:52 <jberkus> well, the first thing would be to recruit the submitters
17:44:58 <jberkus> i.e. submit a contianer, review a container
17:45:05 <jbrooks> good idea
17:45:16 <dustymabe> right, but their review "doesn't count" initially
17:45:27 <dustymabe> we can make them review another container as "practice"
17:45:42 <kushal> Yes, like the rpm reviewer process.
17:45:46 <dustymabe> but I think they have to be "blessed" or something for their review to count
17:46:04 <roshi> in the beginning, we probably need a core group of ProvenContainerers to get the process rolling until there are enough reviewers
17:46:08 <dustymabe> kushal: this might be an opportunity for you to help, since you know more about applications than some of the rest of us
17:46:10 <gbraad> what would be the criteria to review against?
17:46:38 <dustymabe> roshi: ^^
17:46:44 <trishnag> It would be nice if we can have DOC for the same. like roshi said.
17:46:48 <jhogarth> since I've got a key container (for me due to EPEL PHP EOL issues) blocked by this ....
17:47:15 <jberkus> well, and there's also the changing requirements ...
17:47:16 <dustymabe> jhogarth: yes. thank you for "being patient"
17:47:21 <jhogarth> there needs to be some firming up of a few things that are going to be common amongst many services ...
17:47:28 <gbraad> jberkus: my point exactly
17:48:10 <dustymabe> jberkus: can you identify a core group of people that would be able to hash these things out?
17:48:17 <dustymabe> if given some time together?
17:48:24 <jhogarth> we don't have time for it today but take a look at issues 233-235 and comment this week if you could peeps? stuff like systemd based containers, volumes and how to handle version versus what;s in repos are going to trip us up otherwise
17:48:38 <gbraad> if assistance would be needed, I would like to volunteer
17:48:50 <dustymabe> assistance for policy or doing reviews?
17:48:54 <jberkus> gbraad: accepted!
17:49:06 <gbraad> maybe both
17:49:07 <jhogarth> and once things start to go through without them clarified we'll get a divergence rather than consistency quickly ... which is hard to go back and fix in retrospect once things begin moving along
17:49:12 <dustymabe> gbraad: thank you so much !
17:49:26 <dustymabe> jhogarth: would you be interested in helping guide the policy as well?
17:49:36 <gbraad> will sync up with you later about this. OK?
17:50:09 <dustymabe> so jberkus, would you mind being point on the "policy issues" around our container review?
17:50:11 <jhogarth> very much so ... it's why I semi-lurked at this meeting and created the issues for discussion after all!
17:50:24 <jberkus> dustymabe: ok
17:50:29 <dustymabe> make you can get gbraad jhogarth maxamillion and a few others together and do a VFAD next week on it?
17:50:45 <jberkus> gonna lean on jhogarth though because my March is terrible travel month
17:51:14 <dustymabe> I'm going to open a ticket and assign it to you
17:51:24 <jberkus> dustymabe: sure, can someone ref me on how to do a VFAD?  because I missed the first one (FOSDEM)
17:51:26 <roshi> works for me
17:51:41 <dustymabe> jberkus: yep. we'll work it out in #fedora-cloud
17:52:01 <dustymabe> this is great. glad to have some "direction" on that front
17:52:11 <dustymabe> any other open floor topics?
17:52:16 * roshi has nothing
17:52:36 <jhogarth> (just please read and comment on 233-235 guys?)
17:52:45 <jhogarth> ;)
17:53:01 <jberkus> dustymabe: can we follow-up by email? I need to get on an airplane
17:53:03 <dustymabe> jhogarth: yes. but I also think the VFAD (hopefully happening next week) will allow for discussion to flow on those issues
17:53:13 <dustymabe> jberkus: sure
17:53:19 * roshi sets the endmeeting fuse...
17:53:20 <roshi> 3...
17:53:22 <dustymabe> i'll open the ticket and we can discuss from there
17:53:53 <roshi> 2...
17:53:58 <roshi> thanks for coming folks!
17:54:23 <roshi> 1...
17:54:27 <roshi> #endmeeting