#rdo log

15:01:53 <amoralej> #startmeeting RDO meeting (2016-05-11)
15:01:53 <zodbot> Meeting started Wed May 11 15:01:53 2016 UTC.  The chair is amoralej. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:53 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:53 <zodbot> The meeting name has been set to 'rdo_meeting_(2016-05-11)'
15:02:03 <imcsk8> o/
15:02:05 <dmsimard> apevec: jjb is in openstack-infra :)
15:02:06 <amoralej> #topic roll call
15:02:08 <dmsimard> o/
15:02:11 <EmilienM> o/
15:02:13 <chandankumar> \o/
15:02:15 <jpena> o/
15:02:17 <apevec> o/
15:02:17 <elmiko> o/ (sorta)
15:02:23 <eggmaster> \m/ \m/
15:02:31 <imcsk8> rock on!!
15:02:33 <apevec> dmsimard, well, not sure why
15:02:39 <pabelanger> apevec: thanks
15:02:54 <amoralej> #chair imcsk8 dmsimard EmilienM jpena apevec elmiko eggmaster
15:02:54 <zodbot> Current chairs: EmilienM amoralej apevec dmsimard eggmaster elmiko imcsk8 jpena
15:02:56 <apevec> infra team was against adding more namespaces :)
15:03:11 <jruzicka> o/
15:03:17 * dmsimard shrugs, lots of stuff in openstack-infra https://github.com/openstack-infra/
15:03:18 <apevec> openstack/ seems more inclusive I guess
15:03:22 <amoralej> #chair jruzicka
15:03:22 <zodbot> Current chairs: EmilienM amoralej apevec dmsimard eggmaster elmiko imcsk8 jpena jruzicka
15:03:33 <chandankumar> o/
15:03:33 <amoralej> let's go with first topic
15:03:49 <amoralej> #chair chandankumar
15:03:49 <zodbot> Current chairs: EmilienM amoralej apevec chandankumar dmsimard eggmaster elmiko imcsk8 jpena jruzicka
15:04:07 <amoralej> #topic dlrn instance migration - status
15:04:24 <amoralej> jpena, dmsimard, i think you were the ones with actions about this
15:04:28 <rdogerrit> Merged openstack/ironic-python-agent-distgit: Remove Babel and oslo.i18n dependencies  http://review.rdoproject.org/r/1068
15:04:37 <apevec> last week we were stuck on triggerint promotion on ci.centos DLRN?
15:04:41 <jschlueter> o/
15:04:42 <amoralej> yes
15:04:48 <amoralej> #chair jschuleter
15:04:48 <zodbot> Current chairs: EmilienM amoralej apevec chandankumar dmsimard eggmaster elmiko imcsk8 jpena jruzicka jschuleter
15:04:50 <dmsimard> trown figured it out
15:05:05 <apevec> cool, how will it work?
15:05:18 * dmsimard remembers
15:05:21 <apevec> esp. for tripleoci from outside
15:05:49 <apevec> internally for jobs in our promotion pipeline shouldn't be a problem, since it's all inside ci.centos
15:05:59 <dmsimard> basically there is a cron from tripleo CI that checks if all jobs have succeeded and if it is the case, that script connects to DLRN to promote the symlink
15:06:18 <dmsimard> trown figured a way to create a job with a security token so that it can be triggered remotely
15:06:42 <apevec> is there review in progress for that?
15:06:42 <dmsimard> so we will keep that tripleo ci script but s/ssh/curl -x POST/ and that job will be the one to do the promotion
15:07:08 <apevec> this will be for current-tripleo-ci
15:07:23 <apevec> what about rdo promotion ?
15:07:54 <dmsimard> We agreed that the job should *not* be stored in JJB due to security concerns so we repurposed the poc job into a production job :)
15:08:07 <dmsimard> I'm not sure if trown discussed this further with derekh
15:08:17 <apevec> ok, so that's still a blocker
15:08:26 <dmsimard> for rdo promotion everything is backwards compatible, we rely on DNS to promote
15:08:35 <dmsimard> we're connecting to trunk-primary.rdoproject.org
15:08:47 <apevec> ack, so that stays ssh
15:08:50 <dmsimard> so when we change that to the private IP, the job will follow
15:08:51 <dmsimard> yeah
15:09:15 <apevec> so we change it in public DNS to a private IP ?
15:09:31 <dmsimard> well, I mean, that's how it is, right
15:09:35 <dmsimard> there's no public equivalent
15:09:40 <apevec> right
15:10:08 <dmsimard> kilo is still in http://buildlogs.centos.org/centos/7/cloud/x86_64/, I'll follow up with KB and we'll also stop syncing the consistent repos and keep only current-passed-ci
15:10:16 <larsks> dmsimard: more questions!  Right now, /host/<hostname> says "Playbook run for host <hostname>", but in fact this is aggregating together all the tasks from multiple playbooks and multiple playbook runs.  It seems like maybe this should be a list of playbook runs that include the host, and then /host/<hostname>/<runuuid> is the list of tasks *from that run*.  Does that make sense?
15:10:23 <dmsimard> I'll update the centos bug for getting rid of all the consistent repos
15:10:31 <apevec> just somehow weird to have private IP, but -primary is not what is advertised, it's internals
15:10:41 <dmsimard> apevec: yeah, this is just for internal usage.
15:11:22 <apevec> #info DLRN inside ci.centos tl;dr still blocked, need to wait for trown to get back or we check with derekh
15:11:32 <dmsimard> I don't think we need trown
15:11:39 <dmsimard> well, I mean, we do.. :)
15:11:43 <apevec> we DO need trown! :)
15:11:44 <dmsimard> but not to finish that task
15:11:46 <apevec> ack
15:11:50 <dmsimard> I'll follow up with derekh
15:11:50 <apevec> I've put or :)
15:11:57 <apevec> thanks, action it :)
15:12:03 <amoralej> ok, so next topic?
15:12:12 <apevec> amoralej, not before we have action written
15:12:26 <dmsimard> #action dmsimard to follow up with derekh regarding passive trunk.rdoproject usage and promotion through the ci.centos.org job
15:12:28 <amoralej> yeap, sorry
15:12:41 <apevec> now next topic
15:12:50 <amoralej> #topic separate common repo? BoF topic from pabelanger
15:13:03 <apevec> pabelanger, ^ have you opened that topic on rdo-list ?
15:13:44 <amoralej> if not, we can move on to the next one
15:14:21 <apevec> I didn't see it
15:14:39 <apevec> we'll follow up that thread when it shows up
15:14:47 <amoralej> ok
15:14:57 <amoralej> #topic review.rdoproject.org disaster recovery plans?
15:15:27 <dmsimard> I'm not the one owning that topic but I guess it stems from a relative concern about the cloud where the instance is hosted
15:15:37 <apevec> that was for fbo or tristanC  , but I think number80 checked and they should have backups
15:15:45 <jruzicka> +1 on that topic
15:15:46 <dmsimard> Which is the same concern that is leading us to migrate DLRN away
15:15:54 <apevec> but I wonder if that's documented esp. rescovery
15:16:03 <dmsimard> Backup and recovery should definitely be documented
15:16:34 <apevec> I'm concerned that we do now some customizations on the machine directly e.g. gerrit config for replication
15:16:58 <apevec> it should be really good backed up or we use config mgmt for that
15:17:04 <apevec> vs directly editing config
15:17:08 <dmsimard> +1
15:17:32 <dmsimard> I manually keep /etc/gerritbot fairly updated with projects (though I have git init'd the directory at least for keeping track of it)
15:17:39 <apevec> ok, I'll ping softwarefactory folks
15:17:50 <apevec> dmsimard, good idea
15:18:03 <apevec> but that doesn't help if machine dies :)
15:18:26 <apevec> #action apevec to followup with SF team about review.rdoproject.org backup/recovery plans
15:18:30 <apevec> next!
15:18:49 <amoralej> #topic RDO Bug Triage Day on 18th and 19th May, 2016
15:19:06 <amoralej> we discussed last week about what to do with bugs on EOL versions
15:19:06 <apevec> date was set last week, I think we stick to it
15:19:19 <chandankumar> ah, Mail will be sent just after the meeting.
15:19:31 <apevec> right, idea was to send warning week before i.e. today
15:19:44 <apevec> chandankumar, excellent, do you have message text for review?
15:19:53 <apevec> in etherpad or something
15:19:57 <chandankumar> apevec, i will pass you after the meeting
15:20:10 <apevec> just link it here for the record
15:20:52 <chandankumar> apevec, i am still drafting it
15:21:18 <apevec> ok, then post it on #rdo when ready
15:21:43 <pabelanger> apevec: amoralej: not yet, what do you need me to do
15:21:49 <apevec> anything else on the topic?
15:22:05 <apevec> pabelanger, just open the topic on rdo-list, explaining the use case
15:22:23 <apevec> then we discuss details there
15:22:57 <amoralej> #action chandankumar will send a mail about the bug triage day
15:23:22 <amoralej> #topic Update oslo libraries in fedora with python3
15:23:31 <amoralej> chandankumar, this is yours
15:23:36 <chandankumar> yes
15:24:03 <chandankumar> Actually we need to sync our rdo pkg oslo specs with fedora one
15:24:11 <apevec> http://fedora.portingdb.xyz/grp/openstack/
15:24:20 <chandankumar> because bugs are started filed against the component
15:24:29 <apevec> chandankumar, what is that site?
15:24:40 <chandankumar> so just a request from the package maintainer, please sync the spec
15:25:02 <chandankumar> apevec, it is the website maintained by fedora-infra team to track python 3 porting effort
15:25:35 <chandankumar> apevec, https://github.com/fedora-python/portingdb
15:25:35 <apevec> #info fedora.portingdb.xyz is the website maintained by fedora-infra team to track python 3 porting effort
15:25:54 <apevec> how was "OpenStack Group" defined?
15:26:04 <apevec> it includes PyQt4 ?!
15:26:12 <chandankumar> apevec, no idea need to check the code.
15:26:41 <apevec> ah might be dep
15:27:00 <apevec> but still, weird
15:27:10 <apevec> anyway, what would be action here?
15:27:26 <apevec> first sync py3 work from fedora to rpm-master ?
15:27:34 <chandankumar> apevec, yes
15:27:42 <chandankumar> or vice-versa
15:27:55 <chandankumar> all oslo libraries have python3 support in rdo
15:27:56 <apevec> jruzicka, ^ do you fancy cleaning up that mess, clients are your old love? :)
15:28:12 <jruzicka> oh, some actual packaging?
15:28:36 <apevec> yes, not exacly fun work, but still s* to be done
15:29:09 <jruzicka> sure, I can do that. it's just a matter of which s* will get done first ;)
15:29:15 <apevec> need to check py3 status and sync up fedora rawhide and rpm-master
15:29:32 <apevec> jruzicka, where are you with docs update?
15:29:44 <apevec> docs update is definitely high priority
15:29:50 <jruzicka> here is latest draft: https://github.com/yac/website/blob/new-pkgdoc/source/documentation/rdo-packaging-draft.html.md
15:29:56 <jruzicka> about half way there I guess
15:30:19 <chandankumar> https://trello.com/c/ReowuP4z/105-python3
15:30:36 <apevec> ok, wrap that up asap then check py3 ^ see that trello
15:30:50 <chandankumar> ok
15:30:51 <jruzicka> aye, aye, captain ;)
15:31:07 <apevec> jruzicka, action yourself
15:32:06 <jruzicka> #action jruzicka to py3 clients
15:32:19 <tristanC> apevec: I confirm review.rdoproject.org is backup daily to an external swift container, last one is 1.2G made 2016-05-11 00:32:54
15:32:25 <rdogerrit> Merged openstack/cinder-distgit: Add dependencies for Google Cloud Storage backup driver  http://review.rdoproject.org/r/1094
15:32:36 <dmsimard> tristanC: external, as in, outside of the RCIP cloud ?
15:33:16 <tristanC> dmsimard: as in the same cloud... though sf just reference a swift end point so it could easily be moved somewhere else
15:33:34 <dmsimard> tristanC: it'd make sense to backup sf on another cloud than it is hosted on :)
15:33:54 <apevec> tristanC, is the recovery procedure written down and tested ?
15:34:15 <amoralej> we should backup outside rcip cloud
15:34:33 <apevec> and should we consider doing all changes on review.rdo config files via confing mgmt?
15:34:42 <tristanC> apevec: the backup/restore feature do have functional tests run in CI, and the restoration process is documented here: http://softwarefactory-project.io/docs/sfmanager.html#backup-and-restore
15:35:26 <apevec> "backup of all the user data store in your SF installation" - what does that include?
15:35:45 <apevec> is e.g. gerritbot and gerrit replication config included?
15:36:12 <tristanC> git repository, replication configuration, gerrit database, etherpads, pastes, ...
15:36:20 <tristanC> gerritbot channels.yaml may not be included yet
15:36:56 <apevec> ok, so we need to check what might be missing
15:37:14 <apevec> and also look for outside swift for backups
15:37:22 <tristanC> might be a good excercise to similate a disaster indeed
15:37:28 <amoralej> a recovery test in a different cloud would be great
15:37:49 <imcsk8> sounds good
15:38:29 <apevec> alright, so I'm expanding my action to followup w/ SF about doing this disaster exercise
15:38:53 <apevec> #action apevec followup w/ SF team about doing disaster recovery exercise for review.rdo
15:39:05 <tristanC> apevec++ :)
15:39:48 <amoralej> so, i think we can move to the next topic, right?
15:39:51 <apevec> py3 was actually last topic, we should have opened open fllor
15:39:53 <apevec> floor
15:39:55 <amoralej> #topic Chair for next meeting
15:40:07 <apevec> ah yes that one :)
15:40:13 <apevec> any volunteers?
15:40:33 <jpena> I can do it
15:40:37 <chandankumar> apevec, RDO traige email draft https://etherpad.openstack.org/p/rdobugtraigeemail
15:40:49 <chandankumar> *RDO Bug
15:40:57 <amoralej> #info jpena will chair next week
15:41:04 <amoralej> #topic open floor
15:41:43 <dmsimard> I have something to share for Open Floor
15:42:04 <amoralej> go for it
15:42:19 <dmsimard> If you haven't seen it yet, take a look at ARA: http://lists.openstack.org/pipermail/openstack-infra/2016-May/004257.html
15:42:31 <dmsimard> It's something that'll help us scale the CI that we do by making it easier to troubleshoot
15:43:12 <dmsimard> There is only so many hours in the day, if we shave time everytime we have to troubleshoot CI (and god knows we do that all the time) we'll end up more efficient
15:43:33 <dmsimard> But it also means that troubleshooting CI runs will be simpler, more accessible and thus we will be able to onboard volounteers more easily
15:43:50 <dmsimard> </endtopic>
15:43:59 <apevec> chandankumar, ah that's announcement for the bugtriage itself
15:44:28 <apevec> I was thinking you've draft for the EOL warning to put as BZ comment?
15:44:32 <dmsimard> brb
15:44:34 <openstackgerrit> Merged openstack/packstack: Change name for Red Hat OpenStack when using rhsm  https://review.openstack.org/315010
15:44:35 <jruzicka> dmsimard++
15:44:45 <openstackgerrit> Merged openstack/packstack: Change name for Red Hat OpenStack when using rhsm  https://review.openstack.org/314473
15:45:05 <openstackgerrit> Merged openstack/packstack: Add sudo to easy_install pip  https://review.openstack.org/314495
15:45:30 <chandankumar> apevec, i will be drafting the second one soon.
15:46:04 <amoralej> ok, so i guess we can close, right?
15:46:10 <amoralej> anything else for open floor?
15:46:34 <amoralej> 3
15:46:35 <amoralej> 2
15:46:35 <amoralej> 1
15:46:45 <amoralej> #endmeeting