17:00:42 <tdawson> #startmeeting CentOS PaaS SIG
17:00:42 <centbot> Meeting started Wed Jun 28 17:00:42 2017 UTC.  The chair is tdawson. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:42 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:00:46 <tdawson> #topic roll call
17:02:09 * _ari_ here
17:02:14 * jdetiber waves
17:02:22 <richm> hello
17:03:11 <tdawson> Hi _ari_ jdetiber and richm
17:03:27 <tdawson> richm: Aren't you a little early for your meeting that starts right after ours?
17:03:45 <richm> tdawson: I wanted to find out the release schedule for 3.6 upstream
17:05:19 <tdawson> #chair tdawson jdetiber _ari_
17:05:19 <centbot> Current chairs: _ari_ jdetiber tdawson
17:05:25 <tdawson> #topic OpenShift on CentOS Current Status
17:05:29 <tdawson> Starting with rpms
17:05:50 <tdawson> We have tagged openshift-ansible-3.5.82 into release, and it is now on the mirrors.
17:06:14 <tdawson> We have built origin-3.6.0-0.alpha.1 and tagged it into the appropriate places.
17:06:27 <tdawson> We saved alpha.2 for _ari_ and the automation.
17:06:47 <tdawson> But it looks like simply untagging a package doesn't get it out of the testing repo.
17:06:48 <_ari_> tdawson: testing as we speal :)
17:07:21 <tdawson> So I'll have to talk to come centos folk about manually getting the poorly numbered version out.
17:07:26 <tdawson> _ari_: Ya!!
17:08:10 <tdawson> And to answer richm's question ... origin 3.6 will be released on ... I don't know. :(
17:08:19 <tdawson> Does anyone have a better answer than me for that?
17:08:46 <richm> we have other groups such as ovirt that would like to use 3.6 + logging as their logging platform
17:09:20 <richm> and our instructions are based on using ansible to install it via openshift-ansible
17:09:24 * sdodson belatedly arrives
17:09:26 * sdodson reads back
17:09:28 <tdawson> Which sounds like a good idea.
17:09:43 <richm> if there is another way to consume 3.6 upstream, I'm open to suggestions
17:09:49 <tdawson> sdodson: I think you might know better than anyone else a rough timetable for 3.6
17:10:26 <tdawson> richm: Well, this actually is a good place to consume 3.6 ... as long as people don't mind that it's not officially released yet.
17:10:39 <sdodson> It's always up in the air as to what happens with origin but OCP 3.6 code freeze is July 7th so I imagine we'll see origin RC around that time too.
17:11:12 <sdodson> richm: Clayton sort of drives that rather than Centos PaaS SIG driving Origin releases.
17:11:40 <jdetiber> sdodson: tdawson: any reason we couldn't use -future or -testing for a 3.6 alpha build that is consumable?
17:12:00 <tdawson> jdetiber: Yep, they certainly could
17:12:43 <jdetiber> richm: you could provide the repo info for -testing or -future using the openshift_additional_repos var
17:13:00 <sdodson> I don't see any reason we couldn't build a alpha2 + latest commits as long as it doesn't conflict with the release versions that skuznets's CI tooling uses.
17:13:02 <jdetiber> it *should* work
17:13:30 <tdawson> richm: Here is the -testing repo https://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin36/  and here is the future repo https://buildlogs.centos.org/centos/7/paas/x86_64/openshift-future/
17:13:50 <jdetiber> sdodson: shouldn't conflict with skuznet's work since it wouldn't be using -testing or -future
17:14:20 <tdawson> The problem with the -testing repo is origin-3.6.0-0.0.alpha.0.1.x86_64.rpm ... I've got to get that pulled out of there.
17:14:40 <sdodson> I think we should definitely get a new build into testing. We don't even have alpha.2 in there now.
17:15:03 <tdawson> sdodson: Well, when we get to automation, I think _ari_ is waiting to say things about that.
17:15:38 <tdawson> _ari_: Do you want us to jump to the automation part of the agenda?
17:15:38 <_ari_> tdawson: yes that is my plan by the end of the week working out the kinks but pretty close
17:15:41 <_ari_> sure
17:15:44 <jdetiber> tdawson: I'd be happy to do the grunt work on a manual build if needed :)
17:16:08 <_ari_> tdawson: So I am testing building the rpms using steve's scripts
17:16:16 <tdawson> jdetiber: No, I've been purposefully not building the alpha2 so it doesn't conflict with the automation builds.
17:16:22 <_ari_> it seems to be working for the most part just cleaning up playbooks
17:16:43 <tdawson> _ari_: Have you just been building scratch builds thus far?
17:16:47 <_ari_> tdawson: So PR hopefully today with all the changes
17:17:10 <tdawson> _ari_: Very cool
17:17:10 <jdetiber> _ari_: which repo is this in?
17:17:23 <_ari_> tdawson: I tried that in the past with the CBS role that seems to be solid now that I generate the SRPM as part fo the build scripts that steve wrote
17:17:46 <_ari_> jdetiber: https://github.com/CentOS-PaaS-SIG/paas-sig-ci
17:17:57 <jdetiber> _ari_: thanks!
17:18:21 <_ari_> tdawson: the job will have options to kick it with version, scratch, master instead of tag stuff like that
17:20:36 <_ari_> tdawson: that is all I had
17:20:47 <tdawson> _ari_: Thanks for that.
17:20:58 <tdawson> And thanks for all the work you've put into this.
17:21:02 <tdawson> Tell Steve thanks too.
17:21:40 <tdawson> _ari_: One thing that is on the agenda that might affect you is the build target.
17:22:11 <_ari_> tdawson: is that changing
17:22:37 <tdawson> _ari_: It looks like your build target is paas7-openshift-future-el7
17:22:58 <_ari_> tdawson: yes should it be testing
17:23:14 <tdawson> We were wanting to add aarch64 to the other build targets, and add ppc64le to the future build target.
17:23:44 <_ari_> tdawson: ok just let me know then when that changes?
17:23:51 <_ari_> then I or someone can update it
17:24:29 <tdawson> _ari_: Well, it would mean that some builds might break more often, because it would build on ppc64le.
17:25:04 <_ari_> tdawson: how do we normally handle that
17:25:25 <tdawson> Well, we'd have to change things upstream to fix a failed build.
17:25:44 <tdawson> _ari_: Actually ... if you are this close to getting everything done ... I'd rather not rock your boat.
17:25:59 <_ari_> tdawson: I appreciate that
17:26:34 <jdetiber> tdawson: might be good to have a new build target/tags created, but we can discuss when we get to multi-arch :)
17:26:47 <tdawson> jdetiber: Ya, I'm thinking that too.
17:27:48 <tdawson> _ari_: You just keep doing what your doing, we'll think of something for the not-quite working multi-arch builds.
17:28:05 <_ari_> tdawson: sounds good
17:28:16 <bstinson> adding arches to existing tags has been the pattern we've been following so far. but to help make that decision, it would help if we could get a list of packages in each tag, and the arches for which they're all built
17:28:28 <bstinson> that will tell us how much work it will be to do the import process
17:28:52 <tdawson> _ari_: Oh ... some one (possibly two) questions about the automation.
17:29:18 <_ari_> tdawson: yes?
17:29:35 <tdawson> _ari_: Will the builds be scratch builds?  Or will they go directly into the future repo?
17:29:53 <jdetiber> bstinson: that makes me think that a new fresh tag might be the way to go for now, especially since we have the golang disparity...
17:29:54 <tdawson> And if they are scratch builds, how often will you make a non-scratch build.
17:30:00 <_ari_> tdawson: it is an option default is scratch
17:30:32 <_ari_> tdawson: so I guess the question is I can get notified and we do an official build or anyone can that has access
17:30:33 <jdetiber> _ari_: these builds will be triggered on merges to origin/master?
17:30:38 <bstinson> jdetiber: as long as we have a path forward to merge those into the regular tags
17:31:00 <_ari_> jdetiber: they can be but we can't do that for the official build
17:31:01 <jdetiber> bstinson: +1
17:31:27 <_ari_> jdetiber: tdawson plan is to take master and build scratch builds
17:31:35 <jdetiber> _ari_: I was thinking for the -future tag, more official builds should probably go into -testing
17:32:26 <jdetiber> _ari_: It might be nice to be able to track new tags that match the version pattern to automate a build into -testing that could then be promoted
17:32:29 <_ari_> jdetiber: yes but even for future what is the frequency
17:33:15 <jdetiber> _ari_: hmm, okay, maybe just nightly or weekly then :)
17:34:00 <_ari_> jdetiber: I can make adjustments but it wasn't clear the frequency.  master goes to future and tag goes to testing
17:34:07 <jdetiber> _ari_: could we possibly do scratch builds on each merge to master
17:34:42 <tdawson> I think nightly is going to give us way too many builds in cbs and the repos, make it hard to find the released packages.
17:34:59 <_ari_> jdetiber: yes
17:35:00 <jdetiber> tdawson: +1, do you think weekly would be an issue for -future?
17:35:17 <tdawson> I feel better about weekly for -future
17:35:23 <_ari_> jdetiber: default will be scratch builds
17:35:28 <jdetiber> _ari_: great, especially as we start with multi-arch I want to have as tight of a feedback loop on breakage as possible
17:35:52 <_ari_> jdetiber: sounds good to me +1
17:36:27 <tdawson> If it's --scratch, I don't have any problems with daily ... or merge ... whichever works best.
17:36:52 <tdawson> I'd think daily myself, just cuz sometimes several merges come in quickly.
17:38:47 <jdetiber> tdawson: I just worry with daily that it might get difficult to bisect the problem, especially during release crunch time
17:38:56 <tdawson> jdetiber: Ture
17:39:00 <tdawson> true
17:39:19 <tdawson> How about we put off the discussion of how often and which targets until next week.
17:39:24 <jdetiber> +1
17:39:52 <tdawson> Let's let _ari_ get it working how it's setup, and get the first bugs worked out, then we'll worry about things like that.
17:40:11 <_ari_> tdawson: I may not be on the meeting next week with the holiday
17:40:26 <tdawson> Oh ya ... I forgot about the USA holiday
17:40:52 <tdawson> _ari_: Then we'll give you two weeks to get the bugs worked out. :)
17:42:30 <tdawson> _ari_: Anything else before we move to multi-arch ?
17:43:30 <tdawson> Time is running short, so I'm going to move to multi-arch.
17:43:33 <_ari_> tdawson: nope
17:43:56 <tdawson> jdetiber and I have been talking this week about getting ppc64le builds going.
17:44:11 <tdawson> The problem is that they need golang 1.8 to build/run properly.
17:44:50 <tdawson> The bigger problem is that golang 1.8 has some nasty bugs, that would cause problems if we used it generally for our builds on other arches.
17:45:56 <jdetiber> I think we are past the bugs with golang 1.8.3, but there are some behavioral changes that need to be addressed, some we will have to wait for k8s 1.7 for
17:46:07 <tdawson> We've got a proof of concept built on oranges7-test64-common-el7 ... but that is only aarch64 and ppc64le.
17:47:02 <tdawson> We'd been talking about possible getting ppc64le onto the openshift-future build target ... but it's sounding like that's not a good idea.
17:47:50 <tdawson> bstinson: What about if we make an paas7-openshift target that is specificly for multi-arch testing.
17:47:55 <jdetiber> tdawson: I'd like to propose a -multiarch build target/tags, and an associated -common build target/tag for dependencies
17:48:11 <tdawson> Something like paas7-openshift-multiarch
17:48:28 <tdawson> jdetiber: I'd rather not break up it's dependencies ... it's just too much work.
17:48:31 <jdetiber> tdawson: bstinson: dependencies are kind of a pita right now
17:49:19 <jdetiber> tdawson: problem is that we need to make dependencies available for things like openvswitch that consumable by the other SIGs yet
17:49:33 <jdetiber> s/that consumable/that isn't consumable'
17:50:34 <tdawson> jdetiber: But that ends up having a whole build target, for just one package
17:50:45 <bstinson> doing a separate set of tags is workable, we can work out the naming scheme details in a bug
17:51:23 <jdetiber> I'm good with just having tags that can be used for the deps, but we would need a build target that has all the arches, so oranges7 wouldn't work
17:53:14 <jdetiber> but we can discuss all of that more in the ticket :) No need to churn in this meeting
17:53:44 <tdawson> bstinson: jdetiber: OK, sounds good.  I'll create a ticket and I'll make sure to cc jdetiber to the ticket.
17:54:29 <tdawson> We're very short on time ... did anyone have anything for Documentation, images and/or minishift?
17:57:56 <tdawson> OK, new target ticket is here - https://bugs.centos.org/view.php?id=13479
17:58:07 <tdawson> We still need to fill in the end name.
17:58:33 <tdawson> And, we only have a few minutes left, I'm calling it open floor for one minute.
17:58:41 <tdawson> Anything we need to talk about that hasn't been discussed yet?
17:59:27 * tdawson raises his hand.  "What about next week?  Is there going to be anyone here  next week?"
17:59:56 * tdawson points to tdawson "Good question, but we're out of time ... let's discuss it via email."
18:00:08 <tdawson> Talk to ya'll in a week or two.
18:00:17 <richm> hello
18:00:20 <tdawson> #endmeeting