15:00:45 <imcsk8> #startmeeting RDO meeting (2016-06-29)
15:00:45 <zodbot> Meeting started Wed Jun 29 15:00:45 2016 UTC.  The chair is imcsk8. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:45 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:45 <zodbot> The meeting name has been set to 'rdo_meeting_(2016-06-29)'
15:00:47 <openstack> Meeting started Wed Jun 29 15:00:45 2016 UTC and is due to finish in 60 minutes.  The chair is imcsk8. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:51 <openstack> The meeting name has been set to 'rdo_meeting__2016_06_29_'
15:00:55 <leifmadsen> o/
15:00:57 <imcsk8> #topic roll call
15:01:17 <imcsk8> #chair jpena leifmadsen
15:01:17 <zodbot> Current chairs: imcsk8 jpena leifmadsen
15:01:18 <openstack> Current chairs: imcsk8 jpena leifmadsen
15:01:35 <trown> o/
15:01:39 <amoralej> o/
15:01:49 <imcsk8> #chair trown amoralej
15:01:49 <zodbot> Current chairs: amoralej imcsk8 jpena leifmadsen trown
15:01:50 <openstack> Current chairs: amoralej imcsk8 jpena leifmadsen trown
15:02:25 <imcsk8> i guess we can wait for more folks to join
15:02:54 <imcsk8> apevec: meeting?
15:04:05 <chandankumar> \o/
15:04:44 <imcsk8> #chair chandankumar
15:04:44 <zodbot> Current chairs: amoralej chandankumar imcsk8 jpena leifmadsen trown
15:04:46 <openstack> Current chairs: amoralej chandankumar imcsk8 jpena leifmadsen trown
15:05:07 <chandankumar> we need to stop openstack bot.
15:05:28 <jpena> ok, we need an op for that
15:06:07 <imcsk8> ok, i guess we can start
15:06:32 <imcsk8> #topic pinning some packages in RDO Trunk-not-all-master ?
15:06:46 <jpena> this was proposed by apevec
15:07:13 <imcsk8> he does not appear to be here
15:07:29 <jpena> his idea was that, since we are having some troubles with clients and oslo libraries (due to CI not testing master but releases), we could have an intermediate RDO Trunk branch
15:07:58 <jpena> it would be chasing Trunk, but for clients and oslo we would be using a tagged release, chasing what's currently in upper-constraints
15:08:13 <trown> +1
15:08:14 <jpena> from the DLRN side, it requires some work, as it currently assumes branches
15:08:22 <imcsk8> +1
15:08:43 <amoralej> so, that could justify a more elaborated approach to pinning packages
15:08:56 <jpena> and of course, any CI currently using master should switch to that new repo
15:09:06 <amoralej> that the initial one we thought of creating a overrides repo
15:09:19 <amoralej> ideally, testing both would be perfect
15:09:20 * apevec back
15:09:22 <jpena> yes, I think it's a better idea
15:09:28 <number80> well, oslo and clients are also part of OS, so we still need to chase their trunk so the intermediate branch is a good thing
15:09:29 <apevec> thanks for the summary jpena !
15:09:30 <imcsk8> #chair apevec
15:09:30 <zodbot> Current chairs: amoralej apevec chandankumar imcsk8 jpena leifmadsen trown
15:09:44 <apevec> number80, yes, we need both
15:09:46 <jpena> apevec: I had it fresh after today' talk :)
15:10:04 * number80 slow typing this week
15:10:15 <apevec> but to unblock rest of the pipeline, we need almost-master
15:10:22 <apevec> name suggestions welcome!
15:10:50 <jpena> rdo-master-upper-constraints
15:11:00 <apevec> ah nice one
15:11:06 <jpena> maybe rdo-master-it-worked-on-devstack(tm) :P
15:11:06 <apevec> +1
15:11:07 <amoralej> rdo-master-we-hope-this-pass-ci
15:11:18 <imcsk8> jpena: i would like to assist in this task since i've been only reading  reviews related to this
15:11:19 <number80> rdo-restricted
15:11:26 <trown> rdo-master-it-worked-in-devstack
15:11:33 <imcsk8> rdo-miracle
15:11:40 <apevec> ok ok :)
15:12:17 <apevec> re. -upper-constraints is good b/c we actually will need to track tags from u-c
15:12:29 <apevec> so that it matches what is used in upstream gate
15:13:02 <apevec> proposal bot could be keeping it in sync
15:14:00 <leifmadsen> rdo-works-on-my-machine
15:14:13 <apevec> ok, action time, I can write proposal and post it on rdo-list
15:14:33 <amoralej> is u-c updated when new point release are released ?
15:14:36 <apevec> #action apevec post rdo-trunk-upper-constraints to rdo-list
15:14:43 <apevec> amoralej, there's proposal bot
15:14:50 <amoralej> ok
15:15:07 * apevec is looking for an example
15:15:37 <jpena> also, we should work on DLRN to support tags. apevec, is the patch you mentioned today still around?
15:15:42 <apevec> ah for oslo there's now bump on release: https://review.openstack.org/#/q/status:open+project:openstack/requirements+branch:master+topic:new-release
15:15:59 <amoralej> but to have both in parallel we'll need more workers == more infra to build and test
15:16:02 <apevec> jpena, it was just local hack when I did RC builds last year
15:16:04 <amoralej> will that be a problem?
15:16:16 <apevec> amoralej, yes and yes
15:16:29 <jpena> amoralej: we'll probably need more disk space (unless we aggressively purge)
15:16:55 <apevec> but we can workaround by alternating CI pipeline runs
15:17:16 <rdobot> [sensu] NEW: master.monitoring.rdoproject.org - check-delorean-newton-current @ http://uchiwa.monitoring.rdoproject.org/#/client/rdo-monitoring/master.monitoring.rdoproject.org?check=check-delorean-newton-current |#| Build failure on centos7-master/current: ceilometer, oslo.config: http://trunk.rdoproject.org/centos7-master/report.html
15:17:17 <apevec> and lowering frequency for rdo trunk stable  pipelines
15:17:18 <amoralej> yeap,
15:18:34 <apevec> amoralej, here are reviews bumping u-c based on latest pypi releases https://review.openstack.org/#/q/project:openstack/requirements+topic:openstack/requirements/constraints
15:19:16 <apevec> but we're concerned with oslo and clients
15:19:37 <amoralej> then u-c is almost the same as last point.release
15:20:12 <apevec> yes, unless it fails CI, but coverage is not that great
15:20:16 <amoralej> i was thinking in implementation details, :)
15:20:45 <apevec> so things passing reqs CI might still break things
15:22:30 <apevec> yeah, let's not get into impl details here
15:22:48 <apevec> anything else on this topic?
15:23:20 <imcsk8> can we move on?
15:23:42 <apevec> 3.2.1, let's
15:23:45 <jpena> yes, I think so
15:23:51 <imcsk8> #topic Does it make sense to have an RDO ISO installer?
15:23:57 <imcsk8> that's mine
15:24:22 <trown> imcsk8: what would it install?
15:24:36 <trown> RDO is not installer but package repos
15:24:55 <imcsk8> RDO is an OpenStack distribution right?
15:25:20 <trown> right, but not an installer itself, it includes many installers
15:25:27 <apevec> yes, but there are multiple installers using RDO
15:25:31 <imcsk8> i was playing with kickstart files from that standpoint and created a proof of concept
15:25:50 <apevec> do you have that pushed to github so it could be reviewed?
15:26:07 <apevec> hard to tell what is it about with something concrete :)
15:26:20 <imcsk8> i now, but i thoght that it could be a good way for new users to try a PoC install with packstack
15:26:39 <imcsk8> i wanted to ask to see if i polish this or move on
15:27:06 <jpena> imcsk8: so the idea is a kickstart installation that runs packstack --allinone at the end (or something like that)?
15:27:06 <apevec> so how it relates to remix last year?
15:27:19 <imcsk8> jpena: yes
15:27:21 <apevec> GSoC project
15:28:16 * chandankumar not tried rdo remix, just posted the link on etherpad.
15:28:17 <imcsk8> apevec: it's not really related since my attempt is to install openstack without rebooting
15:28:18 <apevec> not sure env in kickstart %post is ready enough for full installation, wasn't that the problem in gsoc remix?
15:29:06 <number80> https://github.com/asadpiz/org_centos_cloud
15:29:12 <number80> for reference, the GSoC code
15:29:15 <imcsk8> i was in contact with the guy that did that but didn't got too much into the details, you were he's advisor right apevec ?
15:29:28 <apevec> I was not
15:29:39 <chandankumar> i think rbowen is the mentor
15:29:50 <number80> yup
15:29:55 <apevec> I just remember it vaguel from the list
15:30:22 <number80> imcsk8: after running GSoC for few years, don't expect students to come back, most don't
15:30:35 <number80> (mine was hired by CoreOS to work on their cloud-init fork)
15:30:53 <apevec> imcsk8, I guess you could push what you have publicly then start discussion on the list,
15:30:59 <imcsk8> well, my experiment is about avoiding rebooting in order to install OpenStack, right now i'm using packstack
15:31:13 <apevec> but I know there's also usbkey based on tripleo-quickstart
15:31:25 <apevec> so maybe better to consolidate efforts
15:31:47 <apevec> weshay, trown - is ooo-usbkey in some repo?
15:31:47 <number80> live-USB may be a better promotion tool
15:31:53 <trown> not sure they are the same idea really, as quickstart usbkey is not bootable
15:32:23 <leifmadsen> apevec: it's in the tripleo-quickstart repo under ci-scripts I think
15:32:25 <apevec> trown, ah, I dunno details
15:32:27 <leifmadsen> or at least triggered from there
15:32:40 <imcsk8> well, i'll send the bate to the list with the current code and see what happens
15:32:43 <trown> apevec: needs docs on how to create it, but ya it is CI'd in quickstart tree https://github.com/openstack/tripleo-quickstart/tree/master/ci-scripts/usbkey
15:33:22 <weshay> apevec, internal msg.. re image location. I need to host it some where public as well
15:33:30 <apevec> ok, let's advertise that on the list and collect/consolidate ideas
15:33:31 <weshay> sudo gate job for it is here https://ci.centos.org/view/rdo/view/tripleo-gate/job/tripleo-quickstart-gate-mitaka-delorean-quick-ooo-usbkey/
15:33:54 <apevec> imcsk8, let's use your post to trigger that discussion?
15:34:04 <imcsk8> apevec: ok
15:34:22 <imcsk8> #action imcsk8 to send message to ML about ISO PoC installer
15:34:57 <imcsk8> that's it for me on this topic
15:35:18 <imcsk8> we have a lot of time and no more topics so...
15:35:21 <apevec> weshay, image could be posted under http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/
15:35:28 <apevec> open floor !
15:35:32 <imcsk8> #topic open floor
15:35:50 <weshay> apevec, k..
15:35:59 <apevec> FYI item could be that DLRN production was migrated to ci.centos
15:36:16 <apevec> kudos to all invovled, jpena++ amoralej++ dmsimard++ trown++
15:36:19 <zodbot> apevec: Karma for jpena changed to 2 (for the f24 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:36:21 <apevec> who did I miss?
15:36:21 <zodbot> apevec: Karma for amoralej changed to 2 (for the f24 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:36:24 <zodbot> apevec: Karma for dmsimard changed to 1 (for the f24 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:36:27 <zodbot> apevec: Karma for trown changed to 2 (for the f24 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:36:37 <trown> was a bit bumpy, but we got there :)
15:36:51 <number80> good progress w/ python3 migration, I hope to finish this week, but I'm doubting as I'm unable to use a hand for a few days
15:36:59 <number80> *hoped
15:37:12 <apevec> trown, last item is to make ooo take images from buildlogs by default
15:37:13 <jpena> number80: then you should be having some rest!
15:37:39 <number80> jpena: I'm fine, just typing slower
15:37:47 <trown> I didnt make a topic for it, but I want to switch out TripleO HA job in the promote pipeline for a single node pacemaker setup with ceph
15:38:19 <trown> until we have the ability to choose which services to install, the HA deploy is too bloated to pass on 3 of the 4 chassis' in cico
15:38:41 <trown> single node with pacemaker at least tests the code path of actual HA
15:39:00 <trown> if we throw in ceph we have gained more than we are losing in terms of coverage
15:39:05 <apevec> trown, so increasing timeout didn't help?
15:39:40 <trown> apevec: well, we have another issue on master, so hard to say, but that is not a very long term solution
15:39:59 <trown> because we are so close to the edge of everything falling over
15:40:38 <apevec> yeah https://etherpad.openstack.org/p/delorean_master_current_issues never ends
15:40:57 <trown> lol yep
15:41:00 <apevec> trown, so 5. is still open?
15:41:23 <apevec> i.e. DEBUG: testing increase timeout for tripleo CI. didn't help?
15:41:26 <trown> apevec: that patch is not in consistent I dont think, so hard to tell
15:43:12 <amoralej> i'll send a change in oslo-config to disable temporarily the tests, so that we can move the consistent link
15:43:19 <apevec> amoralej, ack
15:43:24 <trown> thanks amoralej
15:43:37 <apevec> I was just looking at topic:rdo-FTBFS
15:44:19 <trown> tripleo-common one created review for master, but it is issue on mitaka
15:44:25 <apevec> oslo.config is the only left on master, mitaka has o-t-common, I'll take that
15:44:26 <amoralej> iirc, oslo-config is the only one
15:44:30 <apevec> yeah
15:45:00 <apevec> I merged rpm-master change which broke mitaka, but do not want to create rpm-mitaka just yet
15:45:49 <apevec> trown, when is ooo-HA job change going to happen?
15:46:06 <trown> apevec: I plan to put up patches for it this afternoon
15:46:23 <apevec> cool, 25% luck rate is not that nice to have :)
15:47:04 <amoralej> if we don't get a fix for issue 7 in the etherpad we may have to pin osc again
15:47:21 <trown> ya, if we had single job retry in the multijob it would be livable, but the weirdo jobs and the minimal job are not 100%, so we sometimes get the lucky chassis on the ha job only to have some other job fail
15:47:36 <apevec> amoralej, heh, so back to first topic today :)
15:47:41 <amoralej> yes
15:47:49 <trown> that is something I want to brainstorm with dmsimard when he is back on
15:48:36 <apevec> ok, so we can have that as a topic for the next week
15:48:48 <trown> I think we could save alot of CI resources that way too
15:49:49 <apevec> trown, btw, have you tried new liberty oslo-concurrency build?
15:50:07 <apevec> upgrades worked both ways locally for me with -3 cbs build
15:50:23 <trown> apevec: ya seems to have fixed that issue, there is something else failing on liberty, but it is later and I havent looked closely
15:50:30 <trown> just saw undercloud install is working now
15:50:31 <apevec> cool
15:51:03 <apevec> ok, next week we should have less red in https://ci.centos.org/view/rdo/view/promotion-pipeline/
15:51:13 <trown> we can always hope :)
15:52:19 <trown> should we end the meeting?
15:52:22 <imcsk8> we're always at the top of the our, should we wrap it up?
15:52:29 <apevec> yep
15:52:47 <imcsk8> okay
15:52:47 <kbsingh> hi guys
15:52:50 <imcsk8> #endmeeting