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