15:01:13 <jpena> #startmeeting RDO meeting - 2017-03-15
15:01:13 <zodbot> Meeting started Wed Mar 15 15:01:13 2017 UTC.  The chair is jpena. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:13 <zodbot> The meeting name has been set to 'rdo_meeting_-_2017-03-15'
15:01:14 <openstack> Meeting started Wed Mar 15 15:01:13 2017 UTC and is due to finish in 60 minutes.  The chair is jpena. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:18 <openstack> The meeting name has been set to 'rdo_meeting___2017_03_15'
15:01:22 <jpena> #topic roll call
15:01:24 <rdobot> [sensu] NEW: master.monitoring.rdoproject.org - check-delorean-mitaka-current @ http://tinyurl.com/zsd5jkc |#| Build failure on centos7-mitaka/current: networking-bigswitch: http://trunk.rdoproject.org/centos7-mitaka/report.html
15:01:27 <chandankumar> \o/
15:02:05 <jpena> #chair chandankumar
15:02:05 <zodbot> Current chairs: chandankumar jpena
15:02:06 <openstack> Current chairs: chandankumar jpena
15:02:14 <amoralej|lunch> o/
15:02:15 <jpena> dmsimard: can you mute the openstack bot?
15:02:19 <jruzicka> ʕ•ᴥ•ʔ
15:02:27 <jpena> #chair jruzicka amoralej
15:02:27 <zodbot> Current chairs: amoralej chandankumar jpena jruzicka
15:02:28 <openstack> Current chairs: amoralej chandankumar jpena jruzicka
15:02:39 <jruzicka> well this is redundant. well this is redundant.
15:02:48 <amoralej> :)
15:03:03 <apevec> o/
15:03:12 <jpena> #chair apevec
15:03:12 <zodbot> Current chairs: amoralej apevec chandankumar jpena jruzicka
15:03:13 <apevec> which bot is serving us today?
15:03:13 <openstack> Current chairs: amoralej apevec chandankumar jpena jruzicka
15:03:17 <apevec> TWO!
15:03:31 <dmsimard> \o
15:03:33 <apevec> we need to decide which one to keep
15:03:48 <jpena> remember, if you need to add any last minute topic to the agenda, do so at https://etherpad.openstack.org/p/RDO-Meeting
15:03:52 <jpena> #chair dmsimard
15:03:53 <openstack> Current chairs: amoralej apevec chandankumar dmsimard jpena jruzicka
15:03:58 <jruzicka> apevec, we have better control over zodbot, no?
15:04:07 <apevec> not realy
15:04:12 <apevec> that's fedora infra bot
15:04:15 <dmsimard> we probably have better control over openstack bot :p
15:04:16 <jruzicka> oh
15:04:26 <jruzicka> openstack bot it is then
15:04:32 <apevec> we should register in openstack infra to have official rdo meeting
15:04:38 <jruzicka> (illusion of) control is important
15:04:40 <apevec> now it gets logged as ad-hoc
15:05:03 <apevec> jruzicka, it is via openstack-infra lots-of-yamls repo
15:05:18 <jruzicka> yup, that's OK I guess
15:05:32 <apevec> control is just one git review away
15:05:32 <jruzicka> is zodbot used for anything else?
15:05:40 <apevec> karma
15:05:41 <jruzicka> yes, sufficient :)
15:05:46 <jruzicka> jschlueter++
15:05:50 <jpena> so... shall we start with the agenda?
15:05:52 <apevec> whoowns
15:06:05 <apevec> (looks up in fedora pkgdb)
15:06:09 <apevec> yeah let's start
15:06:16 <rbowen> o/
15:06:20 <jpena> #chair rbowen
15:06:21 <openstack> Current chairs: amoralej apevec chandankumar dmsimard jpena jruzicka rbowen
15:06:37 <jpena> #topic As an FYI, we're adding new python-collectd-gnocchi package which requires opstools sig repo in rdo-release either for Ocata or PIke
15:06:48 <leifmadsen> o/
15:06:49 <jpena> who added this topic? ^^
15:06:53 <apevec> so it will not be FYI
15:06:59 <apevec> we need some decision here
15:07:06 <apevec> it was pradk
15:07:26 <apevec> asking on IRC, then mrunge chimed in from opstools
15:07:37 <pradk> o/
15:07:41 <apevec> collectd-gnocchi depends on collectd
15:07:49 <apevec> suprisingly!
15:07:56 <pradk> :)
15:07:57 <leifmadsen> lies!
15:08:01 <apevec> and collectd is in opstools SIG repo
15:08:18 <pradk> there was some circular dep repo issue i believe
15:08:21 <apevec> so if we add collectd-gnocchi to RDO
15:08:30 <apevec> we need to add repo dep to opstools repo
15:08:38 <pradk> as opstools sig requires rdo back
15:08:39 <apevec> but opstools depends already on RDO
15:08:51 <apevec> b/c os osops-tools-monitoring-oscheck
15:08:58 <apevec> which depends on all clients
15:09:13 <apevec> so yeah it's circular dep which is bad
15:09:17 <apevec> we can:
15:09:32 <apevec> 1) ad collectd-gnocchi to opstools SIG
15:09:54 <apevec> but opstools is depending on RDO Newton while collectd-gnocchi needs Ocata
15:10:11 <apevec> or 2) move oschecks to RDO
15:10:24 <apevec> mrunge, ^ wdyt ?
15:10:39 <apevec> I vote for 2)
15:10:57 <apevec> everything else in opstools SIG is independed of Openstack afaict
15:11:31 <amoralej> apevec, but probably they have other packages that depends on oschecks?, so even if we add it to RDO, they still need to depend on RDO repo
15:11:51 <apevec> yes, they could keep dep on RDO repo
15:12:03 <apevec> it's about avoiding circular dep
15:12:19 <jpena> osops-tools-monitoring is hosted in the OpenStack git, so it makes sense to move it to RDO
15:12:29 <apevec> yep, that's also good point
15:12:56 <apevec> pradk, anything else on this topic?
15:13:17 <apevec> I can take action to talk to opstools SIG folks at their meeting and propose the move
15:13:17 <pradk> apevec, and can we get this into ocata
15:13:31 <pradk> or is it too late for that
15:13:32 <apevec> pradk, deps wise yes, but man, you're late :)
15:13:34 <pradk> we're fine with pike
15:13:41 <pradk> agreed :)
15:13:58 <pradk> no pressure, if we can get it into pike we're happy
15:14:09 <apevec> oh yes, for 2) we need to add deps on opstools SIG
15:14:32 <jpena> apevec: I don't get this ^^
15:14:39 <apevec> hmm, then we still have circular dep
15:14:55 <apevec> jpena, I just found flaw in my proposal
15:14:59 <apevec> damn
15:15:27 <jpena> I don't see anything in osops-tools-monitoring-oschecks that depends on the osptools SIG repo
15:16:06 <apevec> yeah, it's pretty independent collection of script afaict
15:16:23 <jpena> so why would adding it require to add deps on opstools SIG?
15:16:47 <apevec> no, it's back to original collectd-gnocchi plugin
15:16:55 <jpena> ahh ok
15:16:56 <apevec> which has runtime dep on collectd
15:17:22 <apevec> ok, now I have it:
15:17:35 <apevec> we oschecks moved, opstools can drop dep on RDO
15:17:46 <apevec> that's how we avoid circular dep
15:18:00 * apevec needs afternoon green tea or coffee
15:18:02 <trown> o/
15:18:12 <apevec> alright, I'm recording action
15:18:26 <amoralej> opstools doesn't have other packages depending on oschecks?
15:18:30 <apevec> #action apevec  talk to opstools SIG folks at their meeting and propose the moving oschecks to RDO
15:18:41 <amoralej> if so they can't remove their dep on rdo
15:18:53 <apevec> amoralej, I'll discuss that on their meeting
15:18:57 <amoralej> ok
15:19:23 <apevec> anything else?
15:19:56 <jpena> nope, next topic?
15:22:46 <jpena> #topic Project creation process in review.rdoproject.org is now based on reviews in config repo
15:23:07 <apevec> yes! Much goodies after SF upgrade
15:23:20 <jruzicka> woohoo!
15:23:21 <jpena> after yesterday's review.rdo upgrade to SoftwareFactory 2.3.0, we can now create projects using a Gerrit review \o/
15:23:27 <jruzicka> link or it didn't happen
15:23:33 <amoralej> #info first project created with new process https://review.rdoproject.org/r/#/c/5827/
15:23:53 <amoralej> worked fine
15:23:59 <apevec> excellent
15:24:14 <amoralej> now we need to decide how to organize the resources
15:24:16 <apevec> kudos to fbo, tristanC  and rest of SF team!
15:24:17 <jpena> The migration script created a huge yaml file, and fbo proposed https://review.rdoproject.org/r/#/c/5818 with an initial refactor
15:25:15 <apevec> jpena, that's only example covering part of it?
15:25:27 <jpena> that, and https://review.rdoproject.org/r/#/c/5827/
15:25:30 <amoralej> apevec, yes
15:25:54 <amoralej> in the comments there is some discussion about the best approach
15:26:03 <jpena> we need to create a set of human-manageable files, so we are trying to discuss the best way to do it
15:26:15 <apevec> hmm " included group have been discarded " ?
15:26:30 <chandankumar> amoralej: are we using some kind of auto generated yaml template to create this rdo-infra-releng.yaml ?
15:26:30 <apevec> so we can't use sub groups?
15:26:44 <apevec> like we had "rdo-provenpackager" ?
15:26:55 <amoralej> not yet chandankumar, but the idea is to create a template once we decide how to do it
15:28:17 <apevec> amoralej, what we need to decide?
15:28:42 <amoralej> creating a file for each package, for each type of resource, for project?
15:28:50 <amoralej> last proposal is one per-package
15:29:01 <chandankumar> something like reno will work integrated with tox.
15:29:34 <apevec> amoralej, what is package vs project vs resource type?
15:29:40 <apevec> can you give an example?
15:30:15 <amoralej> per-package file, rdo-glance.yaml, rdo-glanceclient.yaml, maybe consolidate all puppet-* in a single rdo-puppet.yaml
15:30:27 <amoralej> per-type files, groups.yaml, acls.yaml, repos.yaml
15:30:36 <amoralej> per-project file, rdo-glance.yaml would containg glance, glanceclient and glance_store, i.e.
15:31:01 <apevec> I kind of like last one
15:31:20 <apevec> acl should be the same per-project right?
15:31:32 <apevec> e.g. all neutron would have same core group
15:31:42 <amoralej> per-package is nice to have easy templates when adding new packages
15:31:49 <amoralej> we don't need to think where to put it
15:31:52 <apevec> but per-package would be easier to automate
15:31:55 <apevec> yeah
15:31:57 <amoralej> yeah
15:32:27 <jpena> I prefer per-package because it requires less brain power to reuse
15:32:45 <jpena> if you have to think were to put the new project, two different people can come up with different ideas
15:32:49 <amoralej> apevec, i like to per-package with exception for puppet that share tha same acls, afaik
15:32:52 <jpena> s/were/where/
15:33:06 <apevec> jpena, +1 less.brain++ :)
15:33:42 <apevec> alright, next question: how do we keep acls in sync w/ rdoinfo?
15:33:55 <apevec> or can we now drop maintainers in rdoinfo?
15:34:02 <apevec> to have single-source-of-truth
15:34:34 <apevec> is acl info exported via SF API ?
15:34:38 <jpena> DLRN uses the maintainers list in rdoinfo
15:35:18 <apevec> jpena, right, so we need to keep it there
15:35:28 <apevec> but then need to automate sync to acl
15:35:47 <apevec> and declare rdoinfo is canonical source
15:35:59 <amoralej> not only for acl syncs, but even for new projects creation, so that new projects are automatically proposed when added to rdoinfo
15:36:08 <apevec> right
15:36:16 <number80> do we know what's the status of RDO nodes in ci.centos.org?
15:36:42 * number80 sees " (pending—All nodes of label ‘rdo’ are offline)
15:37:04 <chandankumar> amoralej: one question so for adding a new package in rdo, we need to send two reviews one with rdo-project.yml and updating rdo.yml?
15:37:09 <apevec> number80, 5h ago eta on centos-devel was ~3h
15:37:23 <apevec> number80, try pinging over there
15:37:40 <number80> ack, I thought this was finished
15:37:49 <jpena> ok, let's try to summarize the discussion
15:37:54 <apevec> chandankumar, no, it would be rdoinfo only
15:37:55 <amoralej> chandankumar, ideally only to rdoinfo and that would send a review to add rdo-project.yaml
15:38:04 <apevec> then have automation syncing to SF config
15:38:36 <jpena> 1- We will have per-package yaml files in the config repo
15:38:50 <jpena> 2- rdoinfo will be the single source of truth for maintainers info
15:39:06 <amoralej> #agreed we will create per-package yaml files in the config repo
15:39:14 <amoralej> ^ even for puppet-*?
15:39:18 <jpena> 3- We will add automated tooling so, anytime a new package is created in rdoinfo, we get a config review to create the project
15:39:31 <chandankumar> got that.
15:39:42 <apevec> amoralej, puppet-* could be exception
15:39:47 <jpena> amoralej: we will still have some default groups (rdo-superusers, rdo-provenpackagers, opm), so the automated tooling can work on that
15:40:08 <amoralej> yes
15:40:27 <amoralej> #agreed a single file rdo-puppet.yaml will be used for all puppet packages
15:40:43 <jpena> the tooling will have to figure out the namespace for new packages, btw
15:40:58 <amoralej> #agreed rdoinfo will be the single source of truth for projects modifications and additions
15:41:14 <apevec> jpena, we can add some logic in automation
15:41:24 <apevec> e.g. default to openstack unless puppet-*
15:41:42 <rdogerrit> Merged config: Add rdo-infra/releng to zuul layout and replication  https://review.rdoproject.org/r/5830
15:41:55 <apevec> and since it's review, still can be amended
15:41:55 <jpena> apevec: yes, that's what I was thinking about. Hopefully we won't add more complexity
15:42:30 <apevec> jpena, luckily for us, bots are not smart enough and still need human supervision :)
15:43:47 <jpena> ok, I think we're done with the topic. I'll work on the rdoinfo->config script
15:43:52 <amoralej> #agreed We will add automated tooling so, anytime a new package is created in rdoinfo, we get a config review to create the project
15:44:15 <rdogerrit> Merged openstack/neutron-lbaas-dashboard-distgit: Copy only new ngloadbalancersv2 panel  https://review.rdoproject.org/r/5825
15:44:25 <amoralej> #action jpena will start working in the rdoinfo2config tool
15:44:43 <jpena> next?
15:45:03 <amoralej> yeah
15:45:30 <jpena> #topic (Announce) Test day schedule posted - https://www.rdoproject.org/testday/ Next one April 20
15:45:35 <jpena> rbowen, the stage is yours
15:45:45 <rbowen> That's really the whole announcement
15:45:50 <rbowen> That I posted the test day schedule. :-)
15:46:05 <rbowen> I haven't put up the individual pages yet. Working on that.
15:46:05 <apevec> and usual: please check test plan if you can
15:46:09 <apevec> and update it
15:46:15 <rbowen> SO once those are up, help out with ... what apevec said.
15:46:33 <apevec> one we're missing: test using upstream install manual
15:46:50 <rbowen> Yes. chandankumar mentioned that last week, and that's a great thing to add.
15:46:57 <apevec> yeah it was proposed few times
15:47:11 <apevec> let's make it real this time
15:47:29 <chandankumar> apevec: is it possible to automate that also scrapping commands and config for doc book?
15:47:37 <chandankumar> *from
15:47:45 <rdogerrit> Merged openstack/mistral-distgit: New release 4.0.0-2  https://review.rdoproject.org/r/5759
15:47:45 <rdogerrit> Merged openstack/kolla-distgit: Update to 4.0.0  https://review.rdoproject.org/r/5815
15:47:48 <apevec> chandankumar, funny you meantion that, there is a tool
15:47:52 <rbowen> I think we also want to start emphasizing TripleO over Packstack on test days.
15:47:54 <apevec> dmsimard, ^ what was the name?
15:47:57 <apevec> rst2bash ?
15:48:04 <dmsimard> uhhhhhhh
15:48:11 <dmsimard> there's bash 2 rst
15:48:16 <dmsimard> sphinx thing that oooq uses
15:48:28 <dmsimard> rst2bash is the other way around, something that openstack docs uses
15:48:33 <apevec> yeah that
15:48:44 <apevec> chandankumar, ^ if you want to play with it :)
15:48:46 <dmsimard> https://github.com/openstack/rst2bash
15:49:13 * chandankumar adding to todo list.
15:49:47 <rbowen> Who is going to add upstream docs testing to the test plan?
15:50:11 <chandankumar> rbowen: i will take care of that.
15:50:22 <rbowen> ok. I was about to say "ok, I'll take it." :-)
15:50:35 <rbowen> #action chandankumar to add upstream docs testing to test day plan.
15:50:36 <rbowen> :)
15:51:04 <rdogerrit> Merged puppet/puppet-tripleo-distgit: Add dependency on puppet-qdr  https://review.rdoproject.org/r/5831
15:52:14 <jpena> great, so we're almost done
15:52:18 <jpena> #topic chair for next meeting
15:52:23 <jpena> Any volunteers?
15:53:29 <amoralej> i can do it
15:54:27 <jpena> great!
15:54:34 <jpena> #action amoralej to chair the next meeting
15:54:39 <jpena> #topic open floor
15:54:52 <jpena> anything else to discuss?
15:55:44 <chandankumar> jpena: just few updates on tempest oooq
15:56:35 <chandankumar> oooq-extras got the support of using tempest_version while running tempest for specific release https://review.openstack.org/444181
15:56:55 <chandankumar> and one more thing
15:57:21 <chandankumar> if we are using jinja templates anywhere in ci or code we can validate that also https://review.openstack.org/#/c/441599/
15:57:40 <chandankumar> that's it from myside.
15:58:36 <rdogerrit> Pradeep Kilambi created openstack/ceilometer-distgit: Fix ceilometer log permissions  https://review.rdoproject.org/r/5832
15:59:14 <rdobot> [sensu] NEW: master.monitoring.rdoproject.org - check-delorean-master-head-current @ http://tinyurl.com/hcnq3ll |#| Build failure on centos7-master-head/current: nova, gnocchi, cliff, networking-bagpipe: http://trunk.rdoproject.org/centos7-master-head/report.html
15:59:34 <jpena> so we're done!
15:59:37 <jpena> #endmeeting