04:01:42 <jbrooks> #startmeeting CentOS Atomic SIG
04:01:42 <centbot> Meeting started Tue Aug  1 04:01:42 2017 UTC.  The chair is jbrooks. Information about MeetBot at http://wiki.debian.org/MeetBot.
04:01:42 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
04:02:06 <jbrooks> OK, this might be a quick one, I don't know if we have jberkus, or anyone else
04:02:15 <jbrooks> #topic downstream release
04:03:02 <jbrooks> A quick update on this for the log, kbsingh did a build of the tree today at https://buildlogs.centos.org/centos/7/atomic/x86_64/repo/
04:03:02 <bamachrn> jbrooks, this is about atomic-container releases right?
04:03:16 <jbrooks> bamachrn, Right.
04:03:25 <jbrooks> Well, we've traditionally only talked about the atomic host
04:03:57 <jbrooks> But in fedora's atomic sig, which I'm involved in as well, and Josh Berkus is also, we deal w/ the host and with the container registry
04:04:17 <jbrooks> And we thought a similar arrangement might be fruitful here on the centos side of things
04:04:54 <jbrooks> bamachrn, Does that sound worthwhile to you?
04:05:39 <jbrooks> We're keen to help promote the container work as part of the overall atomic story
04:05:46 <bamachrn> jberkus, yes, I heard kbsingh and mzee1000 working on this
04:06:27 <jbrooks> KB can't make this meeting time, but we wanted to have a time that would work for the community members in this time zone
04:06:52 <bamachrn> jbrooks, agree, I asked mzee1000 to join
04:07:04 <jbrooks> Cool #chair bamachrn mzee1000
04:07:04 <mzee1000> hi
04:07:10 <bamachrn> to get an idea about where we are for this
04:07:11 <jbrooks> Welcome, thanks for coming
04:07:38 <jbrooks> #topic containers
04:07:40 <bamachrn> mzee1000, about atomic-container we were working, where are we on that
04:07:55 <jbrooks> Now, is that the name for the minimal image?
04:08:10 <bamachrn> jbrooks, yes
04:08:24 <jbrooks> Right, it's only living in one of KB's repos currently, right?
04:08:31 <bamachrn> yup
04:08:31 <mzee1000> bamachrn: we do have a tarball for this
04:08:54 <mzee1000> and a script to generate the same, yes in KB repo and my fork of it
04:09:04 <jbrooks> What are the next steps for making that an official image?
04:09:37 <mzee1000> Well we need to put the tarball, and a dockerfile in same repository and we should be good
04:09:43 <mzee1000> like it happens for rest of images
04:09:52 <mzee1000> centos base images i mean
04:10:06 <jbrooks> Got it
04:10:21 <jbrooks> I was thinking about moving over to it for the kubernetes images I maintain
04:10:36 <jbrooks> I have a Q about those that I wanted to run by you guys, in fact
04:11:35 <jbrooks> But before I digress further, should we record any action items to track related to the atomic-container images?
04:12:14 <jbrooks> We should probably write a blog post or something letting people know about them
04:12:26 <bamachrn> jbrooks, I believe we can have a better update next week with blogs
04:12:34 <bamachrn> yup
04:12:39 <jbrooks> Sounds good
04:12:56 <mzee1000> We could however, work on getting the process for tarball + dockerfile done
04:13:09 <mzee1000> so we can start releasing
04:13:42 <jbrooks> Are you working on that, mzee1000, or do you need help w/ it?
04:14:56 <jbrooks> I looks like they'll live at https://github.com/CentOS/sig-cloud-instance-images/tree/CentOS-7/docker
04:15:17 <mzee1000> jbrooks: yes i am oh ok that sounds good
04:15:17 <jbrooks> w/ branches for the different versions?
04:15:59 <mzee1000> i will need to look at how the asc works though
04:16:23 <bamachrn> This is the same place as centos base images
04:16:29 <mzee1000> bamachrn: yes
04:17:40 <bamachrn> jbrooks, we will look into this, you had some questions about the kubernetes images?
04:17:40 <mzee1000> I can work on pushing tar ball with dockerfile into repo once, but we probably want to automate the process
04:18:35 <jbrooks> bamachrn, Yes, my images include the rpms in centos extras, but I'd like to maintain a second set that track the newer rpms for the virt sig
04:18:47 <jbrooks> I was wondering about the best way to do that, w/ our infra
04:19:15 <jbrooks> #info https://github.com/CentOS/CentOS-Dockerfiles/tree/master/kubernetes
04:19:50 <jbrooks> Maybe branches? Does the build pipeline look at those automatically?
04:19:59 <bamachrn> jbrooks, in our current container pipeline it tracks for the RPM changes as well, I believe we need to figure out about setting different repo.
04:20:42 <bamachrn> jbrooks, yes, but you said about tracking both repos in same time?
04:20:57 <bamachrn> centos extras/ virt sig
04:21:06 <jbrooks> Yes, so that one could either use the version of kube from extras or the one from virt sig
04:21:29 <jbrooks> Also, it'd be nice if you could grab the image based on the tag
04:21:41 <jbrooks> w/ the version # in the tag
04:22:13 <jbrooks> But that's not essential
04:22:17 <bamachrn> jbrooks, ah! got it. different versions of RPM == different tagged images
04:22:34 <jbrooks> right, because extras has kube 1.5.x and the virt sig now has 1.7.x
04:23:28 <jbrooks> I'm tempted to just forget about the earlier one, and focus on the latest, but I imagine some might want the older ones
04:23:31 <bamachrn> jbrooks, that's doable, but we don't change tags of images automatically yet. so may be we have to have two sets of entries in index.
04:24:18 <jbrooks> bamachrn, And you think it'd be best to create a new entry in CentOS-Dockerfiles for the sig-based version?
04:24:32 <jbrooks> like kubernetes-sig or something
04:24:44 <bamachrn> jbrooks, that would great +1
04:24:53 <jbrooks> OK, I'll send a PR that way
04:25:41 <jbrooks> I noticed that some images in the registry have version tags, like datamodel/gremlin:1.2.0
04:25:49 <jbrooks> centos/elasticsearch:2.4.0
04:26:07 <jbrooks> Is there a standard for how that works?
04:26:08 <mzee1000> indeed, those tags are maintsined by users
04:26:43 <bamachrn> jbrooks, yup. they are generally the same version tag as the software inside the image
04:26:45 <jbrooks> And is it the Dockerfile.24 naming that makes that happen?
04:26:55 <jbrooks> https://github.com/mohammedzee1000/CentOS-Dockerfiles/blob/2017-04-10_11-32-10-elastic/elasticsearch/centos7/Dockerfile.24
04:27:24 <mzee1000> jbrooks: no desired-tag in index does that
04:27:24 <jbrooks> I see there's also ENV ELASTIC_MAJOR_VERSION="2.4.0" inside the dockerfile
04:27:40 <mzee1000> the dockerfile names are for managing it
04:27:46 <jbrooks> And that's not part of the repo?
04:27:53 <jbrooks> the desired-tag?
04:27:58 <bamachrn> jbrooks, we can name the dockerfile to anything even the "Dockerfile" is not required. but we need to have desired tag in index for that
04:29:02 <bamachrn> jbrooks, https://github.com/CentOS/container-index/blob/master/index.d/datamodel.yml#L20 this is causing the image to be tagged 1.2.0
04:29:17 <mzee1000> no build metadata including tagging etc is part of index
04:29:22 <jbrooks> bamachrn, got it
04:29:38 <jbrooks> OK, good to know
04:30:25 <jbrooks> Those are the Q's I had for today -- are there things that we (volunteering for Josh in his absence) can do to help the container effort?
04:31:55 <bamachrn> jbrooks, nothing from my side, you are raising PR for the updated versions of virt-sig kubernetes right?
04:32:04 <jbrooks> bamachrn, Yes, I'll do that
04:32:52 <jbrooks> So, our plan is to meet again at this time the week after next -- we're intending to do UTC 0400 and UTC 1600 on alternating weeks
04:33:11 <jbrooks> I'll post minutes from this meeting to centos-devel
04:33:21 <bamachrn> sounds good :)
04:34:00 <jbrooks> Cool, I look forward to working more with you both, bamachrn, mzee1000
04:34:07 <jbrooks> #endmeeting