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:46 <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 <openstack> Current chairs: imcsk8 jpena leifmadsen 15:01:18 <zodbot> 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:53 <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:45 <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:57 <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:19 * 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 <openstack> Current chairs: amoralej apevec chandankumar imcsk8 jpena leifmadsen trown 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:03 <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:29 <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:44 <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:35 <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:14 <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:05 <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:35 <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:49 <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:29 <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