16:57:57 <tdawson> #startmeeting CentOS PaaS SIG
16:57:57 <centbot> Meeting started Wed Mar 29 16:57:57 2017 UTC.  The chair is tdawson. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:57:57 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:58:02 <tdawson> #topic roll call
16:58:54 * _ari_ here
17:00:35 <rtnpro> Hi
17:01:32 <tdawson> Oh ... I was about to ask him if he was here for the meeting ... I guess not.
17:01:34 * sdodson here
17:02:21 <tdawson> #chair tdawson sdodson _ari_
17:02:21 <centbot> Current chairs: _ari_ sdodson tdawson
17:02:40 <tdawson> We're a little slim today, but thats ok
17:02:46 <tdawson> #topic OpenShift on CentOS Current Status
17:02:48 <bamachrn> tdawson: rtnpro is here for rpms updates
17:03:07 <rtnpro> Hi
17:03:16 <tdawson> rtnpro: Hi
17:03:26 <rtnpro> bamachrn, shall I proceed with the updates?
17:03:56 <tdawson> So, we don't have any exciting rpm updates ... We're still working on the automation stuff
17:03:59 <bamachrn> rtnpro: wait, topic is openshift update
17:04:14 <rtnpro> bamachrn, ok
17:04:40 <tdawson> rtnpro: bamachrn: Oh, you're here for the minishift rpm updates?
17:05:34 <rtnpro> tdawson, no, for the container image rebuild feature on container pipeline on RPM updates
17:06:27 <tdawson> rtnpro: Oh, OK ... that's about third on the agenda ... but the other two should go quick.
17:06:41 <rtnpro> tdawson, ok
17:07:00 <tdawson> Normal rpms, no real updates, except automation ... I'll let _ari_ talk about that during the automation section.
17:07:35 <tdawson> Moving on to Documentation ... also ... no new issues ... herlo is working on another blog, but it isn't done yet.
17:08:14 <herlo> oh, hello
17:08:29 <herlo> and yep, not started yet. Soon though. :)
17:08:32 <tdawson> I know I'm moving fast on those two, but I wanted to get to Automation ... see how that's going.
17:08:50 <_ari_> I can go if you want
17:09:14 <tdawson> _ari_: Yep ... how is the automation going?
17:09:38 <_ari_> So I changed things to use the new version scheme going and just got skuznets container rpm generation to work
17:09:42 <_ari_> it is pretty slick
17:09:58 <_ari_> I need to change the playbooks and retest
17:10:08 <_ari_> I will have it wrapped up by the end of the day
17:10:20 <tdawson> _ari_: Cool
17:10:51 <tdawson> _ari_: Are you currently working on the 1.5 builds or 1.6, or both?
17:10:51 <_ari_> tdawson: then you can just call that job to build the rpms for releases
17:11:03 <_ari_> isn't it 3.6
17:11:12 <tdawson> yep ... habit
17:11:18 <_ari_> yes 3.6
17:11:29 <_ari_> I will also make the changes for bleeding edge master as well
17:11:38 <_ari_> skuznets gave me those instructions
17:11:44 <tdawson> Cool
17:11:57 <_ari_> At some point this method will work for openshift-ansible as well
17:12:06 <_ari_> for now doing the old method there
17:12:25 <tdawson> _ari_: Well, that wasn't as complicated as the old origin method
17:12:33 <_ari_> no not at all
17:14:28 <tdawson> _ari_: Awesome work, and thank you for all of that. ... anything else?
17:14:56 <_ari_> tdawson: no that is all and you are welcome!
17:15:11 <tdawson> _ari_: So, will this be happening on a regular basis, like daily, or weekly, or is it a "push this button to build" ?
17:16:39 <_ari_> tdawson:  the bleeding edge one will happen daily and push button I assume the release would be only when we need one ready or what I can do is run that daily and do the CBS release part when we are ready
17:17:27 <_ari_> sound good?
17:17:45 <_ari_> or actually I can do scratch of cbs daily
17:18:09 <tdawson> _ari_: I like the bleeding edge ... for the release, maybe go fo rthe push button right now ...
17:18:20 <tdawson> _ari_: Oh, a scratch daily would be good.
17:18:21 <_ari_> sounds good
17:18:42 <tdawson> _ari_: Maybe a scratch daily, with a button for a real build.
17:18:46 <_ari_> ok I will make that as the usual option to do scratch and then when you want to release we would just not supply that
17:18:51 <_ari_> perfect
17:19:51 <tdawson> Sounds great
17:20:41 <tdawson> OK, moving on to images and image building
17:21:03 <tdawson> rtnpro: what's up?
17:22:14 <tdawson> bamachrn: Or do you know what rtnpro wants to discuss?
17:22:34 <rtnpro> tdawson, hey
17:22:52 <rtnpro> tdawson, so, we have been working on this feature for CCCP for some time
17:23:12 <rtnpro> i.e., rebuild container images on package update for a container
17:23:52 <tdawson> rtnpro: I'd heard of that work, how is it going?
17:23:59 <rtnpro> we've got a PR for it up and functional at: https://github.com/CentOS/container-pipeline-service/pull/197
17:24:21 <rtnpro> hopefully, tomorrow, I will be able to post a demo video for it
17:24:42 <tdawson> rtnpro: Very cool
17:25:14 <rtnpro> initially, we were trying to leverage fedora's anitya
17:25:36 <rtnpro> however, there were some limitations at anitya's side which prevented us from using it
17:26:23 <rtnpro> nevertheless, the functionality is almost event driven (apart from the polling upstream repos part)
17:26:39 <tdawson> nice
17:26:58 <rtnpro> <eof>
17:27:03 <rtnpro> any questions?
17:27:31 <tdawson> rtnpro: Will this be able to help or affect our atuomatic building?
17:27:37 <tdawson> That came out wrong
17:28:03 <rtnpro> tdawson, I do not follow
17:28:21 <tdawson> rtnpro: I guess I have two questions.  First, does this mean when we do our package update in Paas, the resulting CentOS images will automatically get updated?
17:28:37 <rtnpro> tdawson, yes
17:28:43 <tdawson> Cool
17:29:17 <tdawson> rtnpro: And the second question is sort for you and _ari_ ... would you be able to use this to create new images we can test?
17:29:27 <tdawson> _ari_: Or do you already have something in place for testing in images?
17:30:22 <_ari_> tdawson: we can build images given skuznets scripts he gave me the info to do that but I would have to look at how we use those to pull from in the e2e testing
17:30:43 <_ari_> tdawson: is there a current place you dump images for testing
17:31:20 <tdawson> _ari_: I don't.  My only image testing I do is totally local
17:31:39 <_ari_> tdawson: let me see what I can come up with.
17:31:43 <rtnpro> tdawson, in container pipeline, we do have a hook to run custom test scripts on built image
17:32:07 <_ari_> tdawson: can images just get built and tested there
17:32:07 <rtnpro> tdawson, _ari, would that be useful?
17:32:13 <_ari_> yes!
17:32:28 <_ari_> Then our e2e testing could just point to that registry where they live
17:32:34 <_ari_> rtnpro: would that work?
17:32:43 <rtnpro> _ari_, not many are using the test hook ATM, but it's definitely worth a try
17:32:54 <rtnpro> _ari_, yes
17:33:26 <_ari_> rtnpro: I mean even if you are creating these images I can point the config to pull them from there so I can use them for the e2e conformance tests
17:33:53 <rtnpro> _ari_, that will also work
17:34:44 <_ari_> then we are using the proper image build pipeline and I can use them for testing
17:34:54 <_ari_> rtnpro: do you version these to match the release
17:36:16 <rtnpro> _ari_, the images are tagged as specified in the desired-tag key in container-index entry AFAIK
17:36:52 <_ari_> ok we can work out the details when I get there most likely in the next week or so
17:37:04 <_ari_> rtnpro: thanks!
17:38:02 <tdawson> Anything else dealing with images and/or image building?
17:38:18 <_ari_> nope
17:38:31 <rtnpro> ok
17:38:46 <tdawson> rtnpro: Thank you very much for that update
17:38:53 <tdawson> Moving on to Multi-arch
17:38:57 <rtnpro> tdawson, welcome
17:40:20 <tdawson> I think we're going to have to ge tthe -extras repo put into our futures build.  I just cant get around the different golang arches kicking each other out of the repos.
17:41:08 <tdawson> I'll put that on the higher priority so it doesn't interfere with _ari_'s automatic 3.6 builds.
17:41:25 <tdawson> Other than that, I don't think we have any other multi-arch news.
17:42:06 <tdawson> Moving on to the seperate repo work
17:42:20 <tdawson> We now have our -testing repo's for our different repos.
17:42:33 <tdawson> https://buildlogs.centos.org/centos/7/paas/x86_64/
17:43:35 <tdawson> We haven't got any of the "released' repo's yet, or yum.config files setup yet.
17:44:03 <tdawson> There was one question that came up that I thought I'd bring up here instead of just assuming.
17:44:46 <tdawson> Would we want a "common" repo, and then each of these different repo's would have just their differences in them, or should each repo have all it's dependencies in it?
17:45:03 <sdodson> what would go in there?
17:45:06 <tdawson> I'm leaning towards each repo has all of it's dependencies in it.
17:45:15 <sdodson> Yeah, I think that's better.
17:45:41 <tdawson> sdodson: Well, I think everything needed to install the origin and openshift-ansible packages.
17:46:04 <tdawson> So it would have to have openvswitch, ansible, and those packages dependencies.
17:47:30 <tdawson> The thing I worry about with a common repo, is falling into the problem we are currently stuck with, some package needs to stay at an older version of something but everything else has moved on to the newer version.
17:48:27 <sdodson> I think it's better to have wholely contained repos, it's not common but we have used different versions of ansible for different releases of origin. 1.0 and 1.1 use ansible 1.9, 1.2 and later use 2.2
17:48:54 <tdawson> sdodson: OK, I'm fine with that.
17:49:45 <tdawson> I'll start getting those ready this week.
17:49:46 <sdodson> Clayton was really wanting docker in there, but I think that's another question.
17:49:56 <sdodson> docker really comes from extras not origin/ocp channels
17:50:03 <sdodson> but i understand his motives
17:50:11 <tdawson> sdodson: For origin 1.3, I've put the older docker in it.
17:50:27 <sdodson> +1 to including docker in the repos too
17:51:39 <tdawson> sdodson: I'm a little concerned about putting the newer docker in, cuz then it might get out of date if we don't keep it maintained as well as extras does.
17:52:05 <tdawson> sdodson: But if an older release gets stuck on an older docker, I'm fine putting it in there.
17:52:20 <sdodson> tdawson: that sounds fine to me
17:53:00 <tdawson> sdodson: We'll start with that, and if we're finding out we need to include docker in the newer repos, we'll deal with it at that point.
17:53:16 <tdawson> Oh, we're running short on time
17:53:27 <tdawson> Last subject, minishift
17:54:23 <tdawson> lalatenduM: any repot on minishift?  I didn't see any emails this week
17:55:18 <tdawson> I'll assume it's progressing good. :)
17:55:26 <tdawson> Well, we're out of time, thanks for the good discussions today
17:55:36 <tdawson> I'll send out notes.
17:55:47 <sdodson> tdawson: thanks for running the meeting!
17:56:00 <tdawson> You're very welcome
17:56:05 <tdawson> I'll talk to ya'll next week.
17:56:14 <tdawson> #endmeeting