15:01:17 #startmeeting RDO meeting - 2018-08-29 15:01:17 Meeting started Wed Aug 29 15:01:17 2018 UTC and is due to finish in 60 minutes. The chair is jpena. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:18 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:20 The meeting name has been set to 'rdo_meeting___2018_08_29' 15:01:24 o/ 15:01:25 o/ 15:01:31 #topic roll call 15:01:35 #chair leanderthal number80 15:01:35 Current chairs: jpena leanderthal number80 15:01:49 remember, the agenda is available at https://etherpad.openstack.org/p/RDO-Meeting in case you want to add any last-minute topic 15:01:59 o/ 15:02:09 o/ 15:02:21 #chair baha ykarel 15:02:22 Current chairs: baha jpena leanderthal number80 ykarel 15:02:55 let's start with the agenda, we have many topics to cover 15:03:03 #topic Policy for abandoning packages proposal 15:03:19 ykarel, number80: is ^ yours? 15:03:33 not mine 15:03:34 o/ 15:03:41 #chair mjturek 15:03:42 Current chairs: baha jpena leanderthal mjturek number80 ykarel 15:04:04 Yep 15:04:18 We have cases where packages lose their maintainers and are not replaced 15:04:24 So I suggest few things: 15:04:41 1. ping once a year, maintainers to check if they're still active or not 15:05:10 2. have a proper procedure to abandon and transition packages to someone else (and announce it if there are no candidates) 15:05:29 So what do you think and what's missing in the headlines? 15:07:19 Nobody? I guess I will then follow up in the mailing list :) 15:07:51 #action number80 create a thread about abandoning packages policy on the rdo-dev list 15:08:30 I think both options are valid... It's more about how to manage packages when the initial maintainers are no longer responsive 15:08:38 so probably option 1 is a bit better to me 15:09:52 so a year is not much time 15:10:09 yearly maintainer ping might be worth a try 15:11:31 proper procedure to abandon and transition packages... other than creating respective rdoinfo review? 15:11:31 wouldn't it need to be twice yearly? 15:11:42 ack let's try that 15:11:43 OK 15:12:01 leanderthal: we can change the cadence if needed 15:12:05 fair 15:12:17 or maybe we could go with a less intrusive way of examining builds/distgits and detecting inactivity 15:12:29 jruzicka: at my non-surprise, people don't know what to do, so documenting it is useful :) 15:12:55 number80, so basicaly that translates to documenting what to do... sounds useful :) 15:12:58 jruzicka: if we can exploit gerrit data, we can target people pinged 15:13:09 s/pinged/to be pinged/ 15:13:47 if a package hasn't been updated for some time and there is no activity from the maintainer somewhere, we might detect it and make someone check 15:14:12 number80, yes gerrit data, distgit/patches branch commits, builds... 15:14:30 jruzicka: builds are now made by a bot so not relevant here :) 15:14:39 right :) 15:15:11 anyway a solution not requiring maintainer actions if (s)he's active is preferred here 15:16:01 ack 15:16:04 documenting what to do when mainter is gone sounds almost unevitable 15:16:13 hell yeah :) 15:16:58 shall we move on to the next topic? 15:17:09 we could copy fedora unresponsive maint process? 15:17:36 yessssss 15:17:39 +1 15:18:17 apevec: we could adapt it 15:19:35 exactly. 15:20:28 I have enough material to shape something for vote next week then :) 15:21:02 #topic Release preparations 15:22:19 We have repositories ready (all 3 platforms) and same for centos-release-openstack-rocky 15:22:39 leanderthal: do you need any help with the release announce? 15:23:01 number80, of course 15:23:14 i have this https://www.rdoproject.org/rdo/release-checklist/ 15:23:18 #link https://www.rdoproject.org/rdo/release-checklist/ 15:23:26 Yup 15:24:24 and i've started https://etherpad.openstack.org/p/rdo-rocky-release 15:24:26 #link https://etherpad.openstack.org/p/rdo-rocky-release 15:24:31 \o/ 15:24:48 Ronelle Landy proposed rdo-jobs master: Add subnodes and primary node IPs to yaml file https://review.rdoproject.org/r/16013 15:25:33 #action all help with the release announcement 15:25:37 who is willing / able to contribute to the release announcement? this will be one of my main projects at ptg (the other one being the interviews) 15:26:43 release announcement should go out before ptg? 15:26:51 also, can we take a minute to squee for that sentence you made earlier, number80 ? 15:27:02 #info We have repositories ready (all 3 platforms) and same for centos-release-openstack-rocky 15:27:05 SQUEEEEEE 15:27:14 Yay \o/ 15:27:18 apevec, no, it'll go out during or immediately after ptg 15:27:23 if CI works, we can release tomorrow? 15:27:28 oh 15:27:36 Nicolas HICHER proposed rdo-jobs master: DNM: use hostvar to set /etc/nodepool/provider https://review.rdoproject.org/r/15919 15:27:36 apevec, i'd LOVE to do it before PTG 15:27:37 * ykarel having some network issues 15:27:51 is it possible? 15:27:52 Nicolas HICHER proposed rdo-jobs master: DNM: use hostvar to set /etc/nodepool/provider https://review.rdoproject.org/r/15919 15:28:01 leanderthal, upstream GA is tomorrow 15:28:20 ykarel, ^ how is CI doing, any blockers for release tomorrow? 15:28:37 apevec, just some NODE_FAILURES started 15:28:40 rest is good 15:28:42 it'd be super keen to do the announcement tomorrow, but highly unlikely due to gathering the information together 15:28:49 apevec, upstream GA postponed? 15:29:02 wasn't that today? 15:29:16 ykarel, schedule still has tomorrow 15:29:28 https://releases.openstack.org/rocky/schedule.html#r-release 15:29:59 Nicolas HICHER proposed rdo-jobs master: Add vexxhost job and nodeset https://review.rdoproject.org/r/15895 15:30:09 leanderthal, yeah, also it usually takes time to get SIG rpms signed by centos and published on mirror.c.o 15:30:22 mmm may be i have misread earlier, was on 29th 15:30:59 min rdo ga = upstream ga + time to rebuilds rpms in CBS + CI time + centos signing and sync to mirror.c.o 15:31:04 leanderthal, ^ 15:31:17 for one release, it was <12h 15:31:21 apevec, also promotion to -testing and then -release 15:31:28 number80, ^ or was it even less? 15:31:40 ykarel, yeah, that's "CI time" 15:31:41 apevec, that was two years ago - it was awesomeness. but the release announcement doesn't have the same speed 15:31:45 due to gathering the info 15:31:46 apevec, ohhk 15:32:44 yeah, we could start announcement draft earlier for next GA 15:33:11 agreed 15:33:28 apevec: no less than 12h but if we had repo, we could have done within 2h 15:33:40 so it's possible to break the record this time 15:33:57 yeah we can try that 15:34:06 setting new targets 15:34:23 ah, we already have http://mirror.centos.org/centos/7/cloud/x86_64/openstack-rocky/ ! 15:34:45 with RC builds 15:34:55 yes that was published today 15:35:01 cool! 15:35:23 we only have few candidates, that i will be proposing patch in few minutes 15:35:33 so we are in sync 15:35:37 :) 15:35:51 nice 15:35:53 but CI :( 15:36:16 seeing NODE_FAILURES 15:37:14 not nice :( 15:37:35 I hope it's not rdocloud weekly outage coming up 15:38:07 me too hoping the same 15:39:04 next topic? 15:39:50 yup 15:40:00 #topic Relationship with rpm-packaging project 15:40:04 that's mine 15:40:35 so you're probably aware that there is an upstream rpm-packaging project, where we are collaborating primarily with people from SUSE, but also from some other companies 15:41:18 we've been successful in reusing some tools created by that project, but we've never been able to reuse the spec file templates generated by the project 15:41:50 the only one we reuse directly is openstack-macros 15:41:54 in rdo trunk 15:41:58 so the RDO community involvement has always been like "half-done" 15:42:26 we tried to reuse more for python3 poc 15:42:42 during the last cycle, we've only seen reviews/commits from ykarel or me, and we need to consider how we want to collaborate there (if at all) 15:42:51 but looks like maintainers lean to add py3 support directly 15:43:14 jpena, I think it makes sense to continue contributing to common tooling 15:43:23 where it makes sense like pymod2pkg 15:43:55 but for spec.j2 15:44:50 leaving the spec.j2 side would mean stopping the 3rd party CI jobs, I assume 15:44:58 so we'd be effectively pulling off 15:45:10 yeah, we wouldn't have a use-case to support it 15:45:44 yeah 15:46:18 At some point, we can't do everything so focusing on tooling is probably the most sensible path 15:46:25 do you think we should discuss it on the mailing list, or can we make a decision now? 15:47:02 Expanding the discussion on the list wouldn't hurt but I'd limit it in time 15:47:12 i recommend discussing ^ that. 15:47:21 yes. start the discussion with a deadline 15:47:32 ok, sounds like a plan 15:47:52 #action jpena will start discussion on rdo-dev list about rpm-packaging involvement, with a deadline to decide 15:47:59 something along the lines of, "this is what we'd like to do, we're making the decision at the rdo meeting on such and such date; please discuss here and / or attend the meeting to help decide" 15:48:23 i recommend two weeks except that it's right over ptg, so..... 15:49:15 let's see if we get somewhere in one week 15:49:29 sounds good 15:49:30 and let's move to the next topic, we have lots to cover and little time :D 15:49:30 awesomeness 15:49:42 #topic Patch for introducing job for ppc64le container builds 15:49:42 let's move on, 10min left and few more topics 15:49:51 mjturek, baha ^^ 15:50:00 hey jpena pretty straight forward 15:50:12 have a patch available that should introduce the job 15:50:21 would like some eyes on it as it's pretty ugly right now 15:50:24 https://review.rdoproject.org/r/#/c/15978/ 15:51:48 mjturek, baha - also email devs list about this one 15:51:49 adding few reviewers 15:51:54 in gerrit 15:52:01 awesomeness, thx apevec 15:52:18 #action CI reviewers to check https://review.rdoproject.org/r/#/c/15978/ 15:52:39 thanks all 15:52:49 #topic Hardware for building octavia-tempest-test-golang package 15:53:01 so baha had emailed about this package 15:53:16 and the resolution seemed to be that it couldn't be built as there's no hardware for it in RDO 15:53:27 wondering who we could talk to about introducing power hardware into the cloud 15:53:40 and if that's something you all are open to 15:53:57 me and ..... leadership team 15:54:12 mjturek, let's have a meeting about this 15:54:23 sounds good 15:54:24 mjturek, alternative was to build that pkg in CBS 15:54:36 it's actually annoying subpkg 15:54:36 is that possible? ^ 15:54:39 That was my thought. Centos cloud has access to power nodes, and it's only one package 15:54:42 just for testing 15:55:02 apevec that would be nice! 15:55:11 it's not changing that frequently? 15:55:11 did you two ask on #centos-devel ? 15:55:24 leanderthal, CBS is multiarch 15:55:27 We figured we'd come here first, since it's for the delorean repo 15:55:38 ooOOOoo 15:55:39 right 15:55:52 https://lists.rdoproject.org/pipermail/dev/2018-August/008884.html thread here for those curious 15:56:10 package name is actually python-octavia-tests-tempest-golang 15:57:38 leanderthal: still open to introducing power hardware into rdo though, ping me after and we can discuss 15:57:42 golang? 15:57:57 it's a single httpd server in golang, used for tests 15:57:59 it's basically static https://github.com/openstack/octavia-tempest-plugin/commits/master/octavia_tempest_plugin/contrib/httpd/httpd.go 15:58:07 jpena, yeah, silly isn't it 15:58:09 My left eyebrow raised so high that it touched my hair 15:58:14 :) 15:58:19 number80, picture! 15:58:41 mjturek, definitely, but i'm off in less than a minute - i'll ping you tomorrow 15:58:47 jpena, I think we could just create a srpm from that 15:58:56 no worries at all leanderthal 15:59:01 and have it in deps 15:59:11 my gut reaction to this is: let's just rebuild it as a dep. We'd have to fix the octavia spec not to require a fixed version, but that should be enough 15:59:24 yep 15:59:25 https://github.com/rdo-packages/octavia-distgit/blob/rpm-master/openstack-octavia.spec#L144 15:59:49 right 15:59:53 cool! 15:59:59 who takes ownership? 16:01:06 jpena: correct me if I'm wrong, but rebuilding it would take place in CBS? should we reach out to centos-devel for help here? 16:01:31 jpena, i need to scoot as it's the end of my day, but my topic is coming up; it needs to be discussed here and tomorrow i'll email the lists 16:01:40 i'll read the notes tomorrow before i email 16:01:47 leanderthal: ack 16:01:58 mjturek, no, we can add it as any other dep in cloud sig tags 16:02:05 via rdoinfo deps.yml 16:02:27 apevec: so that would require a new spec in rdo-common, right? 16:02:43 yes, we need to right a new spec to build only that go file 16:02:58 basically extract it from octavia plugin spec 16:03:28 ok, in the absence of other volunteers, I can have a look at that 16:03:58 thank you jpena 16:04:02 #action jpena to extract octavia-tempest-test-golang to a separate dep 16:04:10 and octavia plugin even has a release now! https://github.com/openstack/octavia-tempest-plugin/releases 16:04:27 Thank you very much! 16:04:30 apevec: that's not even in the tempest plugin, it's part of the octavia repo 16:04:49 we're late! 16:04:52 #topic propose to shift test days to M1 / M3 instead of M2 / GA 16:05:09 jpena, it is in tempest plugin https://github.com/openstack/octavia-tempest-plugin/blob/master/octavia_tempest_plugin/contrib/httpd/httpd.go 16:05:24 #undo 16:05:25 Removing item from minutes: #topic propose to shift test days to M1 / M3 instead of M2 / GA 16:05:37 since we are over time, let's move this last topic to next week? 16:06:07 also Rain left 16:06:32 ah she said to still discuss it? 16:06:38 I'd say +2 :) 16:06:39 she said she wanted this topic discussed in the meeting 16:06:46 let's get it back quickly 16:06:51 #topic propose to shift test days to M1 / M3 instead of M2 / GA 16:07:05 make sense 16:07:11 TL;DR: there's a lot to do for GA, no time for tests. So proposal: test M1/M3 instead 16:07:15 I'm +1 to that 16:07:38 anyone else? 16:07:40 so for Stein that would be end of Oct and early March 16:07:46 +1 16:08:10 NB Stein is longer cycle upstream https://releases.openstack.org/stein/schedule.html 16:08:18 GA is early April 16:08:55 looks ok to me 16:09:02 since nobody is opposing... 16:09:09 +1 16:09:11 shipit 16:09:12 #agreed test on M1 / M3 instead and cancel rocky test days GA next week 16:09:21 #topic open floor 16:09:32 we already have a chair for next week, anything else before we run? 16:09:47 Yes one more thing 16:10:05 Kudos to ykarel for driving his first release by himself :) 16:10:15 ykarel++ 16:10:56 * number80 is done 16:11:03 let's finish, then, it's late 16:11:05 #endmeeting