16:05:12 <jberkus> #startmeeting atomic-community
16:05:13 <zodbot> Meeting started Mon Nov 13 16:05:12 2017 UTC.  The chair is jberkus. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:05:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:05:13 <zodbot> The meeting name has been set to 'atomic-community'
16:05:13 <centbot> Meeting started Mon Nov 13 16:05:12 2017 UTC.  The chair is jberkus. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:05:13 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:05:27 <dustymabe> .hello2
16:05:30 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dustymabe@redhat.com>
16:05:33 <jberkus> I think I just found a bug in the meetbot code ;-)
16:05:34 <ashcrow> .hello smilner
16:05:35 <zodbot> ashcrow: smilner 'None' <smilner@redhat.com>
16:05:38 <jberkus> #topic roll call
16:05:41 <ashcrow> .hello smilner
16:05:41 <zodbot> ashcrow: smilner 'None' <smilner@redhat.com>
16:05:56 <jberkus> my apologies for the confusion about the meeting time.  I blame Ben Franklin.
16:06:02 <jberkus> .hello jberkus
16:06:03 <zodbot> jberkus: jberkus 'Josh Berkus' <josh@agliodbs.com>
16:06:35 <jberkus> jbrooks: I know you're online, are you on IRC?
16:06:41 <walters> .hello walters
16:06:42 <zodbot> walters: walters 'Colin Walters' <walters@redhat.com>
16:06:48 <jbrooks> jberkus, yes
16:06:50 * ashcrow chuckles
16:06:54 <jbrooks> Oh, right, time zones
16:06:59 <jbrooks> .fas jasonbrooks
16:07:00 <zodbot> jbrooks: jasonbrooks 'Jason Brooks' <JBROOKS@REDHAT.COM>
16:07:01 <miabbott> .hello miabbott
16:07:03 <zodbot> miabbott: miabbott 'Micah Abbott' <miabbott@redhat.com>
16:07:13 <giuseppe> .hello gscrivano
16:07:13 <zodbot> giuseppe: gscrivano 'Giuseppe Scrivano' <gscrivan@redhat.com>
16:07:26 <jberkus> oh
16:07:51 <jberkus> #chair dustymabe ashcrow jbrooks miabbott giuseppe walters
16:07:51 <zodbot> Current chairs: ashcrow dustymabe giuseppe jberkus jbrooks miabbott walters
16:07:51 <centbot> Current chairs: ashcrow dustymabe giuseppe jberkus jbrooks miabbott walters
16:08:09 <jberkus> #topic CentOS Atomic Host update
16:08:47 <jbrooks> We have an imminent update to 1710
16:08:59 <jbrooks> The media is in place, I'm sending out an announcement this am
16:09:44 <jbrooks> I think the biggest change is that the version of rpm-ostree in this release will allow you to override pkgs when layering
16:09:54 <jbrooks> I'll mention that in my announce post
16:10:04 <jberkus> cool
16:10:31 <ashcrow> miabbott: does the issue we looked at this morning this release?
16:11:03 <miabbott> ashcrow: probably not
16:11:09 <ashcrow> *docker config issue
16:11:11 <ashcrow> ok
16:11:26 <miabbott> vanilla centos ah should have the same bits as rhel and we haven't see that issue on rhel
16:11:30 <miabbott> but i could be proved wrong
16:11:53 <jbrooks> With this release, they should again be in sync
16:12:00 <ashcrow> awesome
16:12:44 * jberkus tries to think of how to phrase that for the announcement
16:12:48 <jberkus> ok
16:13:11 <jberkus> #topic simplifying atomic install --system
16:14:48 <ashcrow> A little work has been done in that area. --system is no longer required with the latest builds of the atomic command
16:14:49 <jberkus> so, one thing which has come out of the discussions about possibly putting docker in a system container (more on that when we're done collecting data)
16:15:02 <jberkus> ashcrow: oh?  what about --storage=ostree?
16:15:09 <ashcrow> I believe giuseppe is looking at making a less verbose default for system-package as well
16:15:19 <jberkus> giuseppe: ?
16:15:21 <jbrooks> That --storage bit isn't necessary even now
16:15:29 <jbrooks> --system takes care of that
16:15:42 <giuseppe> ashcrow, jberkus, we don't need --system for images that set a docker label
16:16:04 <giuseppe> for images like etcd, it is still necessary, since it can be installed as a Docker container as well
16:16:32 <ashcrow> giuseppe: Hrm, ok.
16:16:37 <jbrooks> I wonder, though, that if you want to run etcd as a docker container, you could just use docker to run
16:16:54 <jbrooks> vs atomic
16:17:00 <giuseppe> jbrooks, it won't honor the atomic labels
16:17:08 <ashcrow> We still need to find a way to make system containers less verbose for the common case.
16:17:09 <giuseppe> that is the only difference I think
16:17:21 <dustymabe> and the user is lost
16:17:28 <ashcrow> giuseppe: Could you create a card to look at this more indepth?
16:18:05 <giuseppe> sure, but what do we mean with "less verbose"?  At the moment it is just atomic install --system $IMG_NAME
16:18:22 <ashcrow> giuseppe: IF the image has the label, right?
16:18:33 <jberkus> that's fine if that's all that's required now.  we're still using a more verbose syntax in our examples
16:18:44 <giuseppe> if the image has no label, with the label it is "atomic install $IMG_NAME" :-)
16:19:05 <ashcrow> giuseppe: ok I misunderstood "or images like etcd, it is still necessary"
16:19:31 <ashcrow> then it sounds like we are in a pretty good place.
16:19:37 <ashcrow> We should start using the simpler commands in docs too
16:19:45 <jberkus> ashcrow: could you update your blog post on the etcd system container with information about the labels?  and the simpler syntax?
16:19:46 <giuseppe> ashcrow, yes with etcd it is necessary to specify --system, otherwise it is installed as a Docker container.  But with CRI-O and Docker, it is not necessary
16:20:06 <ashcrow> jberkus: sure
16:20:40 <giuseppe> we are still suggesting --system-package=no as otherwise we try to install an .rpm, it should be fine with last versions, but it was causing an issue on Atomic Host before, as we tried to install the rpm there as well
16:21:04 <jberkus> #action ashcrow to update blog post to show simpler syntax for system install, talk about labels
16:21:08 <ashcrow> giuseppe: so we should still use --system-package=no then, correct?
16:22:01 <giuseppe> I think we can start avoiding it, the issue has been fixed in atomic
16:22:06 <ashcrow> ok
16:22:32 <giuseppe> also, I am trying to be careful that images I know of do not require --set=FOO=BAR so that the default installation just works
16:22:33 <jberkus> btw, everyone, I plan to take up the whole "docker as a system container" discussion after American Thanksgiving.  We have some survey data, but it's both not enough (40 respondees, some of them RH staff), and contradictory.
16:22:33 <ragekage> should cockpit/ws be installed with --system?
16:22:57 <jberkus> if you have a way to get more users to fill out the survey, then please do
16:23:14 <dustymabe> jberkus: we just have to keep promoting it
16:23:16 <jberkus> https://goo.gl/forms/uExzqoMHnKlfTchI2
16:23:42 <giuseppe> ragekage, no
16:24:06 <jberkus> why isn't cockpit/ws a system container?
16:24:16 <jberkus> anyway, next topic
16:24:38 <jberkus> #topic a better place for system containers?
16:24:46 <jberkus> https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-November/msg00023.html
16:24:49 <jberkus> dustymabe: ?
16:24:54 <jbrooks> Really, an additional place for them
16:25:00 <jbrooks> Not taking anything away
16:25:31 <jbrooks> The fact is, though, that we're using a bunch of private namespaces to demo system containers in https://github.com/projectatomic/atomic-system-containers
16:25:33 <dustymabe> jberkus: yeah. i don't feel like we got resolution on this topic on the list
16:25:43 <jbrooks> And I'd love auto-build on docker hub in the projectatomic namespace
16:26:02 <jberkus> why do we need a separate namespace?  why wouldn't they just be in the general namespace?
16:26:08 <jbrooks> Like, I don't think we've had a containers release on fedora since aug?
16:26:19 <jberkus> jbrooks: that's a bigger problem
16:26:42 <jbrooks> But it's part of why I'd like to have them built in projectatomic, in addition to wherever else
16:26:50 <jberkus> ok
16:27:03 * jberkus doesn't have an issue with pushing containers to more places
16:27:06 <jbrooks> Like, I have a kubeadm system container in PA's github, but not accepted into fedora
16:27:18 <jbrooks> I want to point ppl to a non-jasonbrooks namespace to try it out
16:27:23 <dustymabe> so.. I have a few issues.
16:27:28 <ashcrow> jbrooks: agreed
16:27:31 <ashcrow> Side note: There was a proposal to have a latest namespace added to fedora registry as well
16:27:37 <dustymabe> #1 pa dockerhub is a tirefire
16:27:52 <dustymabe> and I'm partly to blame for that
16:28:08 <jbrooks> as is my personal namespace ;)
16:28:15 <ashcrow> dustymabe: For #1 didn't we already agree in a meeting a month or so ago that we'd start fresh in projectatomic namespace on docker hub?
16:28:17 <dustymabe> jbrooks: yes, but that is expected
16:28:18 <jberkus> dustymabe: it would take me about an hour to purge everything not being updated
16:28:30 <jberkus> ashcrow: fedora namespace
16:28:33 <ashcrow> jberkus: ahh
16:28:35 <ashcrow> ok
16:28:37 <dustymabe> ashcrow: I don't know about that. I know in fedora land we decided to start fresh with the fedora namespace
16:28:48 <jberkus> there's stuff in pa namespace that's actively being used
16:28:52 <dustymabe> jberkus: sure, but there's no governance there
16:29:01 <jberkus> dustymabe: you know the solution to that
16:29:01 <ashcrow> I'm all for doing the same (sans actively used items) for projectatomic namespace
16:29:24 <jbrooks> Yeah, make everything automatic builds
16:29:30 <dustymabe> jberkus: what I proposed is that we include some sort of indicator to let people know these images shouldn't be used for production
16:29:48 <jberkus> dustymabe: oh, yeah, and we got into a tagging discussion
16:29:58 <dustymabe> jberkus: tagging/naming
16:30:18 <jberkus> dustymabe: Two Hard Things in Computing
16:30:30 <jberkus> naming stuff, cache invalidation, and off-by-one errors
16:30:38 <maxamillion> dustymabe: o/
16:30:38 <ashcrow> lol
16:30:42 <maxamillion> dustymabe: what's up?
16:31:02 <dustymabe> maxamillion: we are discussing https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-November/msg00023.html
16:31:16 <jberkus> anyway, I'm happy with a :devel tag, as long as it's :#.#devel
16:31:32 <maxamillion> dustymabe: cool
16:31:53 <ashcrow> jberkus: I'm OK with that tagging style as well.
16:31:55 <jbrooks> jberkus, devel instead of latest?
16:31:56 <jberkus> maxamillion: has there actually not been a FLIBS release since August?  I was assuming there just wasn't an announcement
16:32:00 <ashcrow> giuseppe / jberkus: ^^
16:32:07 <jberkus> jbrooks: latest can be production
16:32:07 <ashcrow> *jbrooks ^
16:32:15 <dustymabe> *NO*
16:32:23 <jbrooks> But we're putting production images in projectatomic?
16:32:27 <giuseppe> in what cases would we need different versions for :devel?
16:32:29 <dustymabe> i don't want anyone pulling production stuff from pa namespace on docker hub
16:32:34 <jbrooks> I don't think we're trying to do that, necessarily
16:32:49 <ashcrow> Yeah, we'd only be using it for autobuilds (IE: devel)
16:32:51 <maxamillion> jberkus: there's has been, but we've had various technical difficulties so we've definitely missed a couple
16:32:59 <jbrooks> I just want ppl to be able to run our images w/o building everything themselves
16:33:08 <maxamillion> jberkus: I'm working right now to fix a lot of stuff, but I just keep finding bug after bug
16:33:16 <jberkus> maxamillion: :-(
16:33:19 <jbrooks> They can get rhel for production, or something
16:33:45 <jligon> .hello jligon
16:33:46 <zodbot> jligon: jligon 'Jeff Ligon' <jligon@redhat.com>
16:33:48 <dustymabe> yeah so there are two problems we are trying to solve
16:33:49 <jberkus> jbrooks: sorry, "stable", rather than "production"
16:33:58 <jberkus> #chair maxamillion jligon
16:33:58 <zodbot> Current chairs: ashcrow dustymabe giuseppe jberkus jbrooks jligon maxamillion miabbott walters
16:33:58 <centbot> Current chairs: ashcrow dustymabe giuseppe jberkus jbrooks jligon maxamillion miabbott walters
16:34:04 <jbrooks> If we have a stable branch in the repo, ok
16:34:08 <jbrooks> But we don't, do we?
16:34:11 <dustymabe> 1. developers can get the latest upstream images for a particular system container
16:34:22 <dustymabe> 2. they get automatically built
16:34:38 <dustymabe> but I don't want them to use these images in production
16:34:44 <jbrooks> That's up to them
16:34:45 <dustymabe> hence the discussion about 'devel' in the name
16:35:01 <jbrooks> They can do what they want, we don't need to weigh in
16:35:15 <jbrooks> We describe accurately what the images are, and that's enough
16:35:23 <dustymabe> sure, but we can have an opinion
16:35:27 <ashcrow> I think it's fair to warn them they are autobuilds but we can't stop people from using the bits
16:35:31 <dustymabe> it's like running fedora rawhide
16:35:37 <jberkus> right.  the relevant question is "are they tested or not"?
16:35:40 <jbrooks> Or like running fedora
16:35:40 <dustymabe> if you do it, you are doing it at your own risk
16:36:02 <dustymabe> jbrooks: I wouldn't say it's like Fedora
16:36:08 <dustymabe> Fedora does get tested and is released
16:36:09 <jbrooks> Do we warn ppl not to consume our sources?
16:36:17 <jbrooks> Like, in the repo itself
16:36:20 <dustymabe> Fedora rawhide would be a good example though
16:36:48 <jbrooks> Whatever, I just want them built and available
16:37:04 <jbrooks> The message can say whatever
16:37:20 <jbrooks> It'd be easier to let us use "latest" so ppl can leave off the label
16:37:41 <jbrooks> But the main thing is having the autobuilds attached to the repo
16:37:43 <jberkus> it's generally understood in Dockerland that :latest is often unstable
16:37:56 <dustymabe> jberkus: ??
16:38:01 <ashcrow> jbrooks: are you in favor of $IMAGE-devel:latest over $IMAGE:#.#devel?
16:38:10 <dustymabe> not sure that matches with my expectation
16:38:13 <ashcrow> jberkus: many times that is true
16:38:16 <jbrooks> projectatomic = devel
16:38:28 <jbrooks> We can put that in the readme or whatever
16:38:32 <ashcrow> jberkus: a good portion of them are autobuilds from github repos and if you want a specific version you use a tag
16:38:41 <jberkus> dustymabe: hence "in Dockerland".  You are, when it comes down to it, not a typical Docker-Docker-Docker user
16:38:54 <jbrooks> I don't think anyone is getting the impression that project atomic is a production support org
16:39:10 <dustymabe> jbrooks: until people come here and ask us questions
16:39:24 <dustymabe> i know it's not "support"
16:39:32 <dustymabe> but how many questions have we had about atomic registry
16:39:33 <jbrooks> ppl ask me q's about my own namespace, too
16:39:47 <ashcrow> I get asked questions about giuseppe's :-)
16:39:49 <jbrooks> We presented that on our front page
16:40:01 <jberkus> dustymabe: users asking questions is a good thing
16:40:05 <jbrooks> As just as much a project/product as the atomic host
16:40:09 <jbrooks> Even though it wasn't
16:40:40 <dustymabe> so let me ask this
16:40:43 <jbrooks> Anyway, community q's etc is different from production support
16:41:08 <dustymabe> how many places will I be able to pull the system container for etcd from?
16:41:26 <dustymabe> and for each of those places what will be the contents of the container
16:41:50 <jbrooks> centos, fedora, dockerhub
16:41:55 <ashcrow> dustymabe: today you can pull it from 3 (or maybe 4)
16:41:56 <dustymabe> what will be the OS? when was it last updated? what will be the source for etcd (tar.gz, rpm)?
16:42:10 <jbrooks> plus innumerable personal namespaces
16:42:29 <jbrooks> Look at the dockerfile
16:42:42 <ashcrow> One of the great things about containers is that, as long as the underlying bits are updated, the built on OS is less important. IE centos based image running on fedora.
16:42:42 <jbrooks> When last updated, look at the last commit
16:43:03 <ashcrow> though I do understand what you are getting  at dustymabe. For things that are supported they do need to have those answers.
16:43:10 <jberkus> all the more reason to have an official image on dockerhub
16:43:13 <ashcrow> As opposed to someone looking themselves
16:43:24 <dustymabe> 11:42:42     jbrooks | When last updated, look at the last commit ?
16:43:25 <jbrooks> And support, you pay for
16:43:41 <dustymabe> jbrooks: if you don't update a system container commit for 6 months we are going to have CVEs in the image?
16:43:53 <jberkus> dustymabe: hence autobuild
16:44:00 <jbrooks> dustymabe, Well, we could do recurring commits to bump the build
16:44:02 <dustymabe> jberkus: it autobuilds based on git commit
16:44:03 <jbrooks> If we want
16:44:15 <ashcrow> dustymabe / jbrooks: The answer is a probably yes. However, we coudl rebuild the underlying automatically without any code changes as well.
16:44:16 <dustymabe> i'm just saying these are all things we have to think about now
16:44:37 <jberkus> ok, it sounds like there's way more issues here than we're going to resolve during the meeting
16:44:45 <jbrooks> Right now we haven't established a rep for being an up to date production caliber repo
16:44:52 <dustymabe> i'm going to shut up now
16:44:52 <giuseppe> we can autobuild all the system container images like every 24h, it doesn't really need to be updated immediately
16:44:55 <jbrooks> So we don't have to worry about giving the wrong impression
16:44:56 <jbrooks> :)
16:45:02 <jbrooks> We can only go up from here
16:45:03 <jberkus> where's a good place to post a list of issues so that we can take them apart individually?
16:45:03 <giuseppe> this is what I am doing right now for gscrivano/$IMAGE
16:45:03 <ashcrow> I'd rather us not push this out a 2nd or 3rd time
16:45:31 <dustymabe> i'm going to shut up now. this problem is not as easy as everyone makes it out to be though
16:45:36 <jbrooks> This was no big deal when atomicapps wanted to use the namespace, why is it a big deal now?
16:45:44 <ashcrow> dustymabe: I don't think anyone is meaning it's easy :-)
16:45:47 <dustymabe> jbrooks: i think that was a mistake personally
16:45:56 <jbrooks> It was a lot nicer than not having it
16:46:10 <jbrooks> What was the actual negative fallout of how atomicapp used it?
16:46:18 <jbrooks> I saw none
16:46:49 <dustymabe> the one thing there that is different is atomicapp wasn't actually an application that was going to run for a long time
16:46:59 <dustymabe> it just bootstrapped another app
16:47:06 <dustymabe> so security issues.. meh
16:47:11 <jbrooks> This is like downloading code and running make install
16:47:20 <jbrooks> Anyone could do that and run it for years
16:47:26 <jbrooks> That doesn't mean that's a good idea
16:47:53 <jbrooks> But it also doesn't mean that we should make things that we want ppl to try out harder to try out
16:48:06 <ashcrow> jberkus: to answer your question an issue would be the best place for that. However, I fear we will keep coming back to this in meetings.
16:48:07 <jbrooks> Just because they might use them irresponsibly
16:48:28 <jbrooks> jberkus,  How do we vote on things in PA?
16:48:31 <dustymabe> jbrooks: if the openshift-ansible installer is using these images then the users don't even know they are using them
16:48:36 <jberkus> ashcrow: yeah, but right now there's like 6 different issues here, namespace, tagging, autobuild functionality, etc.
16:48:49 <jbrooks> Right, and currently that's not even in a project resources
16:49:00 <jberkus> ashcrow: I don't see us coming to a conclusion without taking each issue on and resolving it
16:49:13 <jberkus> jbrooks: either this meeting or on atomic-devel
16:49:30 <jberkus> jbrooks: we've never taken a vote on anything, so there isn't a formal procedure
16:49:30 <dustymabe> jberkus: I think we are just going to have to agree to disagree
16:49:32 <dustymabe> which is fine
16:49:52 <jbrooks> jberkus, I propose we set up autobuilds on projectatomic namespace for each container in https://github.com/projectatomic/atomic-system-containers, tagged latest
16:49:53 <dustymabe> you guys can put it there :), i'm just not a fan
16:50:21 <ashcrow> dustymabe: thank you :-)
16:50:46 <ashcrow> jbrooks / jbrooks: Let's include a note they are autogenerated from github AND do this after cleaning out unused images from the namespace
16:50:58 <jbrooks> ashcrow, +1
16:51:03 <jberkus> jbrooks: WFM.  you or ashcrow should write an announcement for the blog etc.
16:51:20 <jberkus> ok
16:51:23 <ashcrow> jberkus: Sure, jbrooks and I will work on that together.
16:51:29 <jbrooks> cool
16:51:46 <ashcrow> dustymabe: Thank you for agreeing to disagree.
16:51:48 <jberkus> #action ashcrow jbrooks to write blog about system containers in projectatomic namespace
16:52:03 <jberkus> #action jberkus to purge unused images from projectatomic dockerhub
16:52:17 <jberkus> who's dealing with the technical bits for making the image push happen?
16:52:24 <ashcrow> dustymabe: And also thank you for raising the issues.
16:52:52 <ashcrow> jberkus: That I think we need to figure out first. I'm happy to start the investigation.
16:53:01 <giuseppe> who has access to projectatomic on docker.io?
16:53:13 <ashcrow> giuseppe: that's the first part of the investigation :-P
16:53:31 <jberkus> #action ashcrow to figure out how to auto-push images to dockerhub from atomic-system-containers
16:53:43 <jberkus> giuseppe: a bunch of folks.  Including me
16:53:49 <jbrooks> It sounds like dusty does -- did he leave the channel?
16:53:56 <ashcrow> I believe so
16:55:11 <jberkus> ok, sounds like a plan
16:55:17 <jberkus> #topic open floor
16:55:25 <jberkus> does anyone have anything in the last five minutes?  I do
16:55:30 <walters> i've been working on https://github.com/projectatomic/rpm-ostree/issues/1081
16:56:00 <walters> TL;DR - experimenting with changing rpm-ostree to pull RPMs always on the wire and embed the "image" data in an extra RPM that gets injected into the repo
16:56:24 <walters> this is obviously a pretty fundamental change to Atomic Host so i'm interested in high level feedback; for now just an experiment
16:56:27 <jberkus> walters: what does this mean for users?
16:56:54 <walters> jberkus, one concrete thing is for people who already have tooling to mirror RPMs (a lot do), mirroring AH becomes easy
16:57:09 <walters> mirror/snapshot/promote
16:57:59 <walters> another thing is we'll fall less into the slower "archive" fetch path for things like rebasing from stable to updates-testing
16:58:48 <walters> the bigger picture here is part of https://github.com/projectatomic/rpm-ostree/issues/405
16:58:51 <jberkus> walters: what's the downside?
16:59:33 <walters> less alignment with others using libostree is a notable one
16:59:47 <walters> but, hard to do both
17:00:16 <jberkus> can you sum up the issues in a post to atomic-devel?
17:00:39 <walters> i plan to post when it's farther along, just noting here it exists
17:00:44 <jberkus> ok
17:00:47 <walters> exists as an idea and some prototype code
17:00:48 <jberkus> so, one more thing
17:01:22 <jberkus> Red Hat has hired another container community person.  You'll start seeing her here and on the mailing list probably by next meeting.
17:01:28 <ashcrow> awesome!
17:01:49 <jberkus> Sanja Bonic
17:02:07 <walters> cool
17:02:09 <jberkus> she's in Europe, which will make it easier for us to be active there
17:02:58 <jberkus> she has a fair amount of community-building experience, writes Go, and is an enthusiastic OpenShift dev
17:03:42 <jberkus> more when she's in a meeting and I can introduce her
17:04:22 <jberkus> #endmeeting