15:00:21 <jpena> #startmeeting RDO meeting - 2017-11-22
15:00:23 <openstack> Meeting started Wed Nov 22 15:00:21 2017 UTC and is due to finish in 60 minutes.  The chair is jpena. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:26 <openstack> The meeting name has been set to 'rdo_meeting___2017_11_22'
15:00:40 <jpena> Remember that you can add last-minute items to the agenda:
15:00:43 <jpena> https://etherpad.openstack.org/p/RDO-Meeting
15:00:47 <jpena> #topic roll call
15:00:51 <dmsimard> \o
15:00:58 <amoralej> o/
15:01:19 <rbowen> o/
15:01:19 <number80> o/
15:01:22 <jpena> #chair dmsimard amoralej rbowen
15:01:22 <openstack> Current chairs: amoralej dmsimard jpena rbowen
15:02:32 <adarazs|ruck> o/
15:02:39 <weshay> 0/
15:02:48 <jpena> #chair adarazs|ruck weshay
15:02:49 <openstack> Current chairs: adarazs|ruck amoralej dmsimard jpena rbowen weshay
15:03:08 <jpena> #chair number80
15:03:08 <openstack> Current chairs: adarazs|ruck amoralej dmsimard jpena number80 rbowen weshay
15:04:10 <jpena> let's start with the agenda
15:04:19 <jpena> #topic Queens Test day feedback
15:05:10 <jpena> number80: ^^
15:05:25 <number80> Ok
15:05:36 <rbowen> I was traveling and at an event during the test day times. Did we have anybody actually testing?
15:05:47 <number80> Sadly, not that I know of
15:06:02 <rbowen> I like the idea of a test day leader. But I also think that we need to revisit what we expect to get out of a test day.
15:06:14 <number80> The last 2 test days were not very successful, so I'd like us to improve the situation
15:06:16 <rbowen> The current format/template comes really from before we even had much CI infrastructure.
15:06:16 <number80> *nods8
15:06:38 <rbowen> So figuring out exactly what we're trying to accomplish, and rebuilding the test day "script" around that seems impotant.
15:07:01 <number80> Well, one of the suggested ideas is to collaborate with other projects to have joint test days
15:07:07 <rbowen> so, like, *what* we want to get tested, and *who* we want to be doing that testing, and what kind of results/reports we want to get out of it.
15:07:16 <rbowen> That's interesting. Like what projects?
15:07:19 <number80> for instance, TripleO, but also openstack-ansible who consumes our packages
15:07:24 <rbowen> +1
15:07:55 <number80> the test day leader is to ensure that we have at least someone to take care of animating test days, especially when people are travelling
15:08:04 <number80> it should be a rotating duty
15:08:15 <dmsimard> the timing for this one was a bit odd and probably didn't help
15:08:30 <rbowen> The next one is scheduled for December 14, 15.
15:08:31 <jruzicka> o/
15:08:38 <dmsimard> there's a lot of people testing RDO and TripleO every day so there's a definite fatigue around testing things
15:08:47 <rbowen> #chair jruzicka
15:08:48 <openstack> Current chairs: adarazs|ruck amoralej dmsimard jpena jruzicka number80 rbowen weshay
15:08:55 <dmsimard> the people we want to cater to are outside that
15:09:17 <number80> dmsimard: another feedback I have is that some features are coming very late in the process so they are poorly tested
15:09:41 <number80> So another action is to have every stakeholder working toward getting their features ready and testable
15:09:47 <number80> by test days
15:09:51 <rbowen> I'd like to engage the users list in this more, but when people do show up we need to have a clear set of instructions that they can follow, or possibly a test install of RDO somewhere that they can do things on.
15:10:01 <dmsimard> number80: "features" is kind of vague, what does that even mean ?
15:10:08 <dmsimard> number80: RDO packages whatever upstream  projects produce
15:10:14 <dmsimard> we're not going to go out and ask nova to ship faster
15:10:25 <rbowen> We talked about having a test cloud spun up somewhere that is available for test day. But of course someone has to actually do that.
15:10:44 <dmsimard> rbowen: you know, I like that test install idea
15:10:51 <dmsimard> rbowen: kind of like a one-day trystack ?
15:10:56 <rbowen> Are you volunteering to do it? :-)
15:11:02 <rbowen> Yes, like Trystack, except working. ;-)
15:11:06 <number80> dmsimard: no, but let's say nova wants to support a new hypervisor or new service (e.g placement API), it's up to them to work that we get the proper packages, integration in installers ready
15:11:35 <rbowen> So once we have a Queens2 promotion, we install that somewhere, and then on test day we hand out logins somehow so that people can get on it.
15:11:38 <dmsimard> rbowen: I don't volounteer to stand up a full one-day HA cloud with TripleO but I can spin up a Packstack somewhere, sure
15:11:49 <rbowen> +1
15:11:53 <number80> +1
15:12:02 <dmsimard> rbowen: do we have budget for a bare metal somewhere for a day? :)
15:12:11 <number80> ok, I'd like to summarize proposals
15:12:16 <amoralej> maybe the users should be proposing what they want to test on test days
15:12:29 <dmsimard> amoralej: that's cool too
15:12:31 <rbowen> dmsimard, I'm sure we can manage that.
15:12:44 <dmsimard> rbowen++
15:12:53 <amoralej> and we must focus in making sure there are repos and people supporting on those days
15:12:56 <number80> 1. redefine test scenarios during test days (rbowen engage discussion on user-list?)
15:13:16 <number80> 2. have a test day leader (rotating duty) to animate the test day
15:13:39 <number80> 3. have throw-away cloud so users can use it for tests
15:13:59 <number80> please add other points and let's agree on actions :)
15:14:24 * number80 is +1 to all 3 items
15:14:37 <rbowen> Yes, this definitely seems like the right way forward.
15:14:43 <amoralej> +1 +1 +1
15:14:45 <dmsimard> number80: I think #3 is going to be an especially nice addition because installing openstack is boring
15:14:56 <number80> forgot
15:15:08 <dmsimard> number80: using openstack and testing from that perspective is easier, faster, less time consuming and also more fun
15:15:31 <jruzicka> (+1){3}
15:15:34 <number80> dmsimard: I agree that's an excellent idea
15:15:36 <jpena> +1 to all. But one question about 3: what kind of tests would users be allowed to run?
15:15:40 <amoralej> we could add some of the less used services there taa
15:15:42 <dmsimard> we could even rotate and have like, milestone 1 being packstack, m2 being tripleo, m3 being kolla or something
15:15:45 <jruzicka> I'd especially like 3.
15:15:51 <amoralej> deploying magnum, i.e.
15:15:59 <dmsimard> amoralej: yeah
15:16:07 <number80> Yes
15:16:08 <amoralej> jpena, cloud user use-cases
15:16:18 <dmsimard> jpena: anything ? think trystack
15:16:19 <rbowen> We would want to give some guidance of what tests we want folks to run, but also give them freedom to break things and poke around.
15:16:22 <number80> Well, remember we should own actions :)
15:16:27 <dmsimard> jpena: if they break something, then we know we found a bug
15:16:34 <amoralej> that's why we need to provide something cool, other that creating instances
15:16:38 <rbowen> This would be less likely to be abused than Trystack, because it goes away so quickly.
15:16:41 <dmsimard> rbowen: yeah, totally. If they break things then GREAT
15:16:46 <jruzicka> I thought the point of test days is to break stuff :)
15:16:53 <number80> I can take care of animating the next test days to show example :)
15:16:54 <jpena> dmsimard: ok, so that's from the user perspective. I thought we were even going to give admin rights :D
15:17:10 <amoralej> that'd be fun :D
15:17:23 <amoralej> jpena,
15:17:26 <number80> "Make Test Days Fun Again"
15:17:33 <amoralej> we can provide a image with packstack preinstalled
15:17:43 <dmsimard> jpena: I don't think I would give admin rights lol
15:17:54 <amoralej> so that users can deploy packstack inside an instance if they want admin
15:17:55 <dmsimard> amoralej: that too.
15:17:59 <rbowen> I think we can be selective in giving out admin rights to some people, but not just hand it out like candy. Too much potential for abuse.
15:18:04 <dmsimard> so many great ideas this morning
15:18:06 <dmsimard> let's do that more often
15:18:18 <jruzicka> easily getting a VM to quickly test bugs against sounds useful
15:18:57 <number80> well, we have other topics, so please take actions!
15:19:13 <number80> #action number80 take lead over next test days (dec 14, 15)
15:19:27 <number80> next!
15:19:41 <rbowen> #action Rich will talk with the users list about upcoming test day and start building a list of test scenarios.
15:19:49 <rbowen> #action Rich to update test day pages accordingly
15:19:55 <number80> \o/
15:20:01 <jpena> #topic Upstream LTS releases discussion <== follow-up
15:20:07 <rbowen> dmsimard, You going to build our throw-away cloud?
15:20:24 <number80> Anyone who wants to help?
15:20:30 <jpena> #undo
15:20:31 <dmsimard> rbowen: if you get us budget for a good bare metal for ~48hrs, I can do the first one
15:20:31 <openstack> Removing item from minutes: #topic Upstream LTS releases discussion <== follow-up
15:20:48 <rbowen> dmsimard, Any idea of how much we'd be talkinga bout, roughly?
15:20:49 <dmsimard> and like I proposed, the first one can be packstack, second one tripleo, third one kolla, etc.
15:21:00 <jpena> dmsimard: make it ~ a week, so we can add some stuff after installing
15:21:05 <rbowen> We can talk about that offline I guess.
15:21:12 <dmsimard> rbowen: yeah, let's take that offline
15:21:20 <number80> Thank you :)
15:21:35 <jpena> ok, let's move on
15:21:39 <jpena> #topic Upstream LTS releases discussion <== follow-up
15:22:27 <number80> Ok, so I can already tell that we will have representatives to the next PTG (don't know who yet) to participate in these discussions
15:22:37 <dmsimard> great news
15:23:01 <number80> So the big question from last week was how to handle that in RDO land if it happens
15:23:04 <rbowen> Yay Dublin!
15:23:48 <number80> Correct if I'm wrong, but we all agreed to keep for longer DLRN instance to build stable LTS branches
15:24:08 <amoralej> +1
15:24:14 <jpena> yep, we can do it
15:24:59 <number80> AFAIK, CBS builds won't take us much more resources too, but I think we can defer that until we know if there will be tagged releases or not
15:25:17 <number80> (currently, the trend is nope)
15:25:22 <amoralej> yes, according to feedback in etherpad, i'd say there will not be
15:26:02 <amoralej> so, assuming there are no more tags, should we archive cloudsig repos after regular EOL?
15:26:04 <amoralej> i'd say so
15:26:29 <amoralej> so at EOL, archive cloudsig and keep rdo trunk
15:26:41 <number80> good question, I think we can have a longer transition, especially since some deps are embedded in stable repo
15:26:58 <amoralej> we could keep -testing
15:27:11 <amoralej> which is what we use for deps in rdo-trunk deployments
15:27:27 <number80> Yes, question is to check if CentOS can do it
15:27:34 <amoralej> ok
15:27:48 <number80> +1 to keep -testing repo around
15:28:21 <amoralej> yeah, we need it
15:28:22 <number80> #agree keep DLRN repo running + stable -testing repo to provide deps (and allow us to update them if needed)
15:28:44 <jpena> number80: I think it's "agreed"
15:28:49 <number80> right
15:28:53 <number80> #agreed keep DLRN repo running + stable -testing repo to provide deps (and allow us to update them if needed)
15:29:17 <dmsimard> What exactly are we agreeing on here ?
15:29:27 <dmsimard> The stable/newton branches are gone, what are we keeping alive ?
15:29:57 <number80> dmsimard: if LTS initiative is blessed upstream, what will be our stance towards it
15:30:02 <amoralej> dmsimard, there will be new branches
15:30:09 <dmsimard> ok, sure, but that's like ocata onwards
15:30:13 <dmsimard> at the very least
15:30:14 <dmsimard> correct ?
15:30:29 <dmsimard> it's unlikely that they'll un-EOL newton
15:30:46 <number80> I want us to have a common position, whoever goes there speaking for the group
15:31:39 <number80> Likewise, what do you think about infra group providing hardware requirements if we have to set up a third-party CI for upstream LTS branches?
15:32:10 <amoralej> CI is the big topic
15:32:19 <amoralej> well and people
15:32:30 <dmsimard> Yeah
15:32:44 <dmsimard> We first need to know what coverage is expected
15:33:01 <number80> It will put a strain on our actual infra, so if we have numbers ready, daddy shadowman or any nice sponsors can budget that asap
15:33:16 <number80> (and it takes time to budget hardware)
15:33:35 <dmsimard> number80: We need the interested parties to define what is the extent of third party CI they will require
15:33:49 <number80> dmsimard: maybe upstream can estimate that?
15:33:50 <dmsimard> because as I understood from the thread, it looks like first-party (upstream) is not closed to the idea of running jobs on extended branches
15:34:16 <number80> Yeah, they worried about manpower
15:34:18 <dmsimard> (if that's what the community ends up deciding)
15:34:26 <dmsimard> the manpower to *maintain* those branches
15:34:32 <dmsimard> do backports, make sure they stay healthy, etc
15:35:05 <amoralej> other point is periodic jobs to ensure it keeps working over time with centos updates
15:35:07 <jpena> it would also depend on which type of 3rd party jobs we want to run. A multi-node oooq job is not as resource-heavy as an allinone packstack
15:35:15 <amoralej> we should keep some kind of promotion pipeline
15:35:23 <amoralej> or at least periodic jobs
15:35:24 <number80> Well, I think we can participate to that, but we're not a key actor in that aspect
15:35:41 <number80> +1 amoralej
15:36:16 <number80> dmsimard, jpena: I think rough guesstimates should be enough, no need to have detailed estimates at this stage
15:36:47 <number80> Up to infra group, anyway
15:37:26 * number80 is good on that topic
15:37:55 <jpena> moving on
15:37:59 <jpena> #topic Keeping infra systems up to date: scheduled maintenance windows?
15:38:36 <jpena> We are updating infra systems from time to time, but we're not using any specific schedule
15:39:14 <jpena> Since those systems are externally-facing, we should define some maintenance window where we can regularly patch them
15:39:38 <number80> +1
15:40:02 <amoralej> sounds as a good idea
15:40:03 <jpena> I was thinking about defining two windows (e.g. 1st and 3rd Monday of the month), so we don't bring everything down at once
15:40:16 <jpena> dmsimard: thoughts? ^
15:40:30 <dmsimard> yes
15:40:45 <dmsimard> historically maintenances on sundays have been awful anyway :D
15:41:02 <dmsimard> FWIW the sunday maintenances were not scheduled on those days for fun
15:41:51 <dmsimard> 1) registry certificate was expiring 2) logserver being down means every job in review.rdo, review.openstack (third party), downstream (third party) and ci.centos jobs would fail so it had to be done at a very very quiet period
15:42:29 <dmsimard> but I can see those windows useful for planning maintenances which require downtime
15:42:38 <dmsimard> unplanned maintenances are a fact of life but let's try to plan what we can
15:43:00 <number80> Yes, it will reduce a little bit the strain on you guys
15:43:26 <dmsimard> jpena: let's do tuesdays instead
15:43:35 <jpena> ack. I will prepare something and propose it as a PR to the infra pages in www.rdoproject.org
15:43:49 <dmsimard> jpena: less holidays, we can wrap up preparations on mondays, etc.
15:44:09 <dmsimard> jpena++
15:44:30 <jpena> #action jpena to propose planned maintenance windows
15:44:44 <jpena> anything else in this topic?
15:46:01 <jpena> #topic Hangout/Interviews - https://lists.rdoproject.org/pipermail/dev/2017-November/008393.html - please let Rich know if you want to participate.
15:46:40 <rbowen> This item is mostly just an announcement. If you would like to do an interview about your work in RDO, and/or in upstream, I'd like to start doing these possibly as early as next week, and possibly as often as every 2 weeks.
15:46:58 <rbowen> The goal is to get some good reusable videos, which will also be transcribed into blog posts.
15:47:10 <rbowen> If you are interested in doing this, and missed the PTG video interviews, please let me know.
15:47:19 <rbowen> I'll be posting a schedule/signup to dev@ in the coming days.
15:47:27 <rbowen> /EndOfMessage
15:48:59 <jpena> #topic Quarterly virtual RDO meetup? See https://lists.rdoproject.org/pipermail/dev/2017-November/008394.html
15:49:02 <rbowen> dmsimard suggested we do a quarterly online/virtual RDO meetup. I'd like to get an idea of how many of you would be willing to present in the first one, if we were to have it in February or March. Half-hour presentations, presented via a Hangout.
15:49:51 <rbowen> Don't all volunteer at once. ;-)
15:50:08 <jpena> I was trying to think of a topic to present :)
15:50:35 <rbowen> Ok, well, no urgency. I'll probably start working on it first week of Jan. So think on it, and I'll bring it back up later.
15:50:39 <jpena> sign me up while I come up with something
15:50:44 <rbowen> Sweet.
15:50:45 <rbowen> Thanks.
15:51:01 <amoralej> that should be focused for users or devs?
15:51:06 <number80> Well, the same but I'm out of ideas for now
15:51:06 <amoralej> the presentations, i mean
15:51:07 <rbowen> If we go with the format dmsimard suggested, we'd need 4 presenters, quarterly. Seems like a good place to start.
15:51:21 <amoralej> i like the idea
15:51:25 <dmsimard> 3 or 4
15:51:27 <rbowen> amoralej, My preference would be user-focused.
15:51:35 <dmsimard> user and operator, yes
15:51:39 <rbowen> Yes.
15:51:45 <dmsimard> as little as possible vendor things
15:51:46 <dmsimard> please
15:51:48 * number80 looks at magnum folks
15:52:14 <dmsimard> We should organize a committee to vote on submissions and speakers
15:52:24 <dmsimard> there was something I saw recently.. hang on
15:53:02 <dmsimard> This is the approach one of the Ansible meetups organizes topics for talks https://github.com/keithresar/ansible-minneapolis-meetup-topics/issues
15:53:24 <rbowen> Wow. That's cool.
15:53:26 <number80> or allow people to suggest topics
15:53:26 <dmsimard> I found the method interesting, maybe we could draw inspiration from that
15:53:35 <dmsimard> rbowen: isn't it? :D
15:53:37 <rbowen> #link https://github.com/keithresar/ansible-minneapolis-meetup-topics/issues
15:53:55 <dmsimard> number80: yes, people can suggest topics
15:54:18 <dmsimard> number80: the idea is just to have a list of topics because people don't usually know what to talk about
15:54:24 <dmsimard> so it gives some ideas
15:54:51 <rbowen> ok, we're out of time, so I'll take the topic-brainstorming back to the list.
15:55:03 <amoralej> in a local hack&beers meeting we use trello for something similar
15:55:07 <amoralej> propose/vote talks
15:55:41 <jpena> ok, let's move on then
15:55:48 <jpena> #topic IaaS FOSDEM Devroom, CFP closes next Friday: http://lists.ovirt.org/pipermail/users/2017-November/085073.html
15:56:17 <rbowen> That's just an announcement.
15:56:30 <rbowen> If you're planning to be at FOSDEM, please consider submitting a talk to the devroom.
15:56:34 <strigazi> number80 what do you mean by looks at magnum folks
15:56:45 <rbowen> Also, the CentOS Dojo, if you have content that would be relevant to that.
15:56:59 <rbowen> https://seven.centos.org/2017/10/feb-2-2018-centos-dojo-at-fosdem/
15:57:07 <number80> strigazi: we're looking for presentations at the virtual RDO meetup, so we'd be happy to have one from you ;-)
15:57:42 <number80> rbowen: I'm thinking about having a talk at CentOS dojo, but anyway, I'll be in Brussels around that period like I always do
15:58:22 <rbowen> Well, you have one more week to think about it. :-)
15:59:02 <rdogerrit> Gabriele Cerami proposed rdo-infra/ci-config master: Promoter: promote hash only after other steps completed  https://review.rdoproject.org/r/10531
15:59:14 <jpena> one last topic before we go
15:59:20 <jpena> #topic chair for the next meeting
15:59:24 <jpena> any volunteer?
15:59:45 <amoralej> i can do it
15:59:59 <jpena> #action amoralej to chair the next meeting
16:00:00 <jpena> thanks!
16:00:20 <jpena> let's end the meeting, and continue discussions if needed
16:00:22 <jpena> #endmeeting