14:01:00 <EmilienM> #startmeeting tripleo
14:01:00 <openstack> Meeting started Tue Jan 31 14:01:00 2017 UTC and is due to finish in 60 minutes.  The chair is EmilienM. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:03 <openstack> The meeting name has been set to 'tripleo'
14:01:06 <jrist> o/
14:01:10 <EmilienM> #topic agenda
14:01:12 <EmilienM> * review past action items
14:01:14 <EmilienM> * one off agenda items
14:01:14 <trown> o/
14:01:16 <EmilienM> * bugs
14:01:17 <bkero> o/
14:01:18 <EmilienM> * Projects releases or stable backports
14:01:20 <EmilienM> * CI
14:01:22 <EmilienM> * Specs
14:01:24 <EmilienM> * open discussion
14:01:26 <EmilienM> #info Anyone can use the #link, #action and #info commands, not just the moderatorǃ
14:01:28 <EmilienM> #link notes from previous meeting: http://eavesdrop.openstack.org/meetings/tripleo/2017/tripleo.2017-01-24-14.00.html
14:01:30 <EmilienM> Hi, who is here today?
14:01:32 <jtomasek> o/
14:01:32 <mwhahaha> o/
14:01:38 <shardy> o/
14:01:46 <panda> o/
14:02:09 <jpich> o/
14:02:14 <bkero> lots of people
14:02:26 <beagles> o/
14:02:28 <jpich> all the people
14:02:34 <marios> o/
14:02:40 <sshnaidm> o/
14:02:56 <jrist> EmilienM: link me the one off items again please?
14:03:11 <matbu> o/
14:03:21 <adarazs> o/
14:03:23 <ccamacho> o/
14:03:24 <EmilienM> jrist: please wait, it's on the agenda
14:03:31 <jrist> k
14:03:42 <EmilienM> #topic review past action items
14:03:44 <EmilienM> 1. (postponed) weshay, matbu, sofer to create a tripleo blueprint for multinode nodepool oooq based upgrade job: https://blueprints.launchpad.net/tripleo/+spec/tripleo-composable-upgrade-job
14:03:46 <EmilienM> 2. bandini and EmilienM to work on scenario005 when composable-ha patches are landed: WIP
14:03:48 <EmilienM> 3. team to review validation work https://review.openstack.org/#/c/416284/ / https://review.openstack.org/#/c/418507/ / https://review.openstack.org/#/c/419506/: done & released
14:03:49 <ansiwen> o/
14:03:50 <EmilienM> 4. team to review https://review.openstack.org/#/c/421242/: done
14:03:55 <EmilienM> nothing postponed this week.
14:04:00 <EmilienM> #topic one off agenda items
14:04:02 <EmilienM> #link https://etherpad.openstack.org/p/tripleo-meeting-items
14:04:13 <EmilienM> shardy: o/
14:04:20 <shardy> EmilienM: Hi!
14:04:31 <EmilienM> shardy: do we have a launchpad blueprint or bug for Contrail FFE?
14:04:33 <shardy> So, I wanted to draw attention to some work pushed by mhenkel last week
14:04:36 <michapma_alt> o/
14:04:43 <weshay> o/.
14:04:50 <cdearborn> o/
14:05:03 <shardy> it's two large patches, but they're mostly only contrail templates/profiles, it touches only the haproxy.pp and endpoint map
14:05:11 <shardy> what do we think about a FFE for this?
14:05:16 <EmilienM> it should be ok
14:05:24 <EmilienM> as long as we don't add a risk to break CI on this one
14:05:26 <shardy> EmilienM: there's a bug, but it's not got a lot of detail:
14:05:29 <EmilienM> but it's not the case AFICT
14:05:40 <EmilienM> shardy: the bug will be helpful for us to track it during RC
14:05:42 <shardy> https://bugs.launchpad.net/tripleo/+bug/1659560
14:05:42 <openstack> Launchpad bug 1659560 in tripleo "Contrail services assigned to wrong roles" [Medium,In progress] - Assigned to Michael Henkel (mhenkel-3)
14:05:46 <shardy> EmilienM: ^^
14:05:59 <EmilienM> moved to ocata-rc1
14:06:02 <shardy> probably, it should have been a blueprint given the size/nature of the change, but we can track it with that
14:06:08 <shardy> EmilienM: thanks!
14:06:11 <shardy> So the other thing was
14:06:12 <EmilienM> yeah, next time please create a blueprint
14:06:24 <shardy> what should we do for large vendor integrations like this which we can't test in CI?
14:06:39 <shardy> I wondered if in future we should have an "extras" or "contrib" directory
14:06:40 <EmilienM> so I see different options
14:06:52 <shardy> to show the pieces which are included, but not necessarily tested every commit
14:06:56 <trown> ideally the vendor will setup some CI that can run as third-party
14:07:02 <EmilienM> trown: yes, that
14:07:08 <beagles> +1 trown
14:07:11 <shardy> trown: Yeah, in this case that may happen, but we don't know when
14:07:13 <EmilienM> trown: like it's done in Cinder / Neutron / ... gates
14:07:29 <EmilienM> if it doesn't happen, I'm in favor of maintaining their code in-tree
14:07:35 <trown> ya, I think our current model is a bit hard to just stand up somewhere else
14:07:45 <trown> that is one of the big goals of quickstart based CI though
14:07:49 <EmilienM> I'm afraid that code out of tree might be outdated and wouldn't work with our most recent interface all the time :/
14:08:08 <shardy> EmilienM: yeah, well I think we need to be careful not to break the service plugin interfaces
14:08:20 <shardy> but we can definitely help keep things updated more easily if they're included
14:08:38 <shardy> I was just worred about confusion about which services are actually tested
14:08:39 <mwhahaha> we need a way to test those interfaces
14:08:43 <mwhahaha> so we know when we break them
14:08:51 <EmilienM> mwhahaha: like a lint test?
14:09:00 <shardy> mwhahaha: Yeah - having some CI that runs on a different repo would help with that
14:09:02 <mwhahaha> it doesn't have to be a real integration, but we need to come up with a proper test suite
14:09:11 <shardy> so we can't break the interfaces in one commit
14:09:15 <EmilienM> maybe a tht-lint thing?
14:09:25 <shardy> mwhahaha: yeah that's a very good idea
14:09:47 <shardy> maybe we can use an all-in-one heat similar to dprince's undercloud installer patch
14:09:48 <EmilienM> could someone create a blueprint for that?
14:10:09 <shardy> Ok, so it sounds like we're OK to go ahead and merge these as-is modulo reviews
14:10:34 <shardy> but perhaps in pike we'll talk more about ways to enforce the interfaces and maybe flag things that aren't tested via a directory move or docs
14:10:44 <shardy> anything else to add before we move on?
14:10:45 <EmilienM> shardy: +1
14:11:20 <EmilienM> jrist: o/
14:11:26 <jrist> hi!
14:11:35 <jrist> Release Notes for TripleO-UI - some contention as to the need for the python for reno
14:11:47 <jrist> EmilienM: jtomasek had mentioned he is wondering if we can skip reno somehow
14:11:48 <EmilienM> I saw that in the patch
14:11:54 <EmilienM> strongly NO
14:11:55 <jrist> personally I don't care
14:11:56 <EmilienM> :)
14:11:56 <jrist> ok
14:11:59 <jrist> done
14:12:01 <jrist> :)
14:12:07 <EmilienM> release note are useful for our users
14:12:24 <EmilienM> it makes popular and understable what you folks are doing
14:12:27 <beagles> release notes are a goodness
14:12:38 <jtomasek> EmilienM: I am not saying skip reno, I am asking if we can put the reno related setup somewhere else then root of the project
14:12:44 <EmilienM> having release notes will help our community to understand what we deliver each cycle
14:12:52 <EmilienM> jtomasek: no we can't
14:12:57 <jtomasek> to avoid having a bunch of python cruft in root of js project
14:12:59 <EmilienM> the release notes are in-tree
14:13:08 <EmilienM> jtomasek: you can maybe talk with dhellmann about this topic
14:13:12 <EmilienM> jtomasek: he created reno
14:13:21 <jtomasek> EmilienM: ok, I'll check with him
14:13:22 <EmilienM> jtomasek: we have the same thing in Puppet modules
14:13:26 <EmilienM> jtomasek: and we survived!
14:13:46 <EmilienM> jtomasek: another alternative is to not use reno
14:13:56 <EmilienM> and maintain a releasenote file
14:14:05 <dhellmann> what are you thinking about moving?
14:14:19 <EmilienM> dhellmann: releasenotes/
14:14:22 <dhellmann> keep in mind that the upstream CI jobs for publishing release notes are set up in one place
14:14:29 <jtomasek> dhellmann: https://review.openstack.org/425979
14:14:36 <shardy> dhellmann: Hi!  We want to maintain release notes for tripleo-ui, but it's not a python project
14:15:10 <shardy> dhellmann: jtomasek would prefer to avoid having the reno related files in the repo, so we're trying to figure out the best path forward
14:15:20 <jtomasek> dhellmann: It would be nice if we could keep the python setup which is used to generate release notes in a subdirectory of the project rather than root
14:15:52 <dhellmann> you'll need to maintain a custom release notes publishing job if you do that. so it's not impossible, but I wonder if it's worth the trouble?
14:16:14 <EmilienM> jtomasek: do you have technical issues with these python files in root?
14:16:18 <shardy> jtomasek: apart from cosmetics, what are the problems with having the files in the root of the project?
14:16:26 <jtomasek> hm, ok, it is probably not worth the trouble
14:16:48 <jtomasek> confusion it causes for new users is my concern
14:16:56 * dhellmann nods
14:16:56 <EmilienM> if there are non-cosmetics things, +1 for an alternative. Otherwise, I don't think it's worth it
14:17:16 <dhellmann> it's not ideal. we could look at changing the job definition to be more flexible, but I would want to consult with infra on that, too
14:17:30 <shardy> I'd suggest we just live with it for now, and talk again if it actually does create significant confusion
14:17:38 <EmilienM> shardy: +1
14:17:40 <jtomasek> ok, fair
14:17:49 <shardy> probably a README in the repo is all that's needed to explain things to new devs
14:18:00 <dhellmann> sounds good
14:18:09 <EmilienM> dhellmann: thanks for your help
14:18:14 <dhellmann> any time!
14:18:14 <shardy> thanks dhellmann
14:18:18 <EmilienM> jtomasek, jrist: anything else?
14:18:39 <jrist> well
14:18:47 <jrist> what's the conclusion? :)
14:18:55 <jrist> keep reno until we patch infra for a different method?
14:19:04 <shardy> jrist: that we use reno, and live with the files
14:19:15 <jrist> and if we come up with something else, we can patch later
14:19:15 <jrist> done
14:19:16 <shardy> and talk again if it causes significant problems
14:19:27 <shardy> and/or we think of a better way
14:19:27 <EmilienM> conclusion, we keep reno in-tree for now, document it in README if needed (or elsewhere) and adjust with infra if really needed
14:19:36 <jrist> thanks
14:19:37 <EmilienM> jrist: all good?
14:19:39 <EmilienM> cool
14:19:47 <EmilienM> #topic bugs
14:19:49 <EmilienM> #info ocata-3 bugs moved to ocata-rc1
14:19:51 <EmilienM> #link https://launchpad.net/tripleo/+milestone/ocata-rc1
14:19:53 <EmilienM> #info 32 Triaged, 34 In Progress
14:19:55 <EmilienM> #info Please use ocata-rc1 target for Critical / High bugs
14:19:57 <EmilienM> #info Please use pike-1 target: Medium / Low / Wishlist bugs
14:20:44 <EmilienM> #action Team to move Low/Medium/Wishlist from ocata-rc1 to pike-1
14:20:58 <EmilienM> I'll start this task today but any help is very welcome
14:21:23 <EmilienM> I don't use a Python script to do it because I want to see case by case, sometimes a bug is almost fixed (patch under review, etc)
14:21:45 <EmilienM> do we have any outstanding bug to discuss this week?
14:23:06 <EmilienM> just a note, the focus now should be on fixing Critical / High bugs on time for ocata-rc1
14:23:27 <dtantsur> yeah, just wanted to ask: is bumping bugs really effective in making people concentrate on the remaining ones?
14:23:27 <panda> urgh my UPS is exploding ... bbl
14:23:35 * dtantsur asks provocative questions
14:23:51 <EmilienM> dtantsur: how can you force folks to work on something?
14:24:07 <EmilienM> dtantsur: sharing the vision & roadmap is the only thing we can do as a team
14:24:21 <EmilienM> if folks want to work on pike-1 bugs, well... :-)
14:24:30 <shardy> dtantsur: FWIW I find it helpful to focus review attention
14:24:50 <dtantsur> shardy, me too, just wondering if it actually works. didn't work to well for us, honestly.
14:24:56 <shardy> in the days before release I'll review the open bugs every few days and try to close as many as possible
14:25:06 <dtantsur> ignore me, if you have other business to talk about during this meeting, I'm mostly thinking aloud
14:25:09 <EmilienM> I'm wondering if you like my emails about short term roadmaps, so folks can know priorities in tripleo?
14:25:39 <dtantsur> EmilienM, do you send such? in ironic we decide week roadmap every weekly meeting, works quite well.
14:25:53 <EmilienM> dtantsur: it sounds like a good idea
14:26:01 <jpich> I think pointing out the important stuff can help, yes :)
14:26:05 <EmilienM> dtantsur: yes I used to send some emails like this, in async though
14:26:15 <EmilienM> dtantsur: I'm glad you read them ! lol
14:26:48 <dtantsur> we also put the priorities on our official whiteboard for people like me ;) https://etherpad.openstack.org/p/IronicWhiteBoard
14:26:55 <EmilienM> I would try next meeting to add a topic for week roadmap
14:26:57 <dtantsur> (see line 66)
14:27:08 <EmilienM> #action EmilienM to add 'week roadmap' to next meeting agenda
14:27:32 <EmilienM> well, I think Launchpad already gives us this kind of information
14:27:52 <dtantsur> well... I don't think so, especially not in the middle of a cycle
14:28:07 <EmilienM> mhh interesting
14:28:37 <dtantsur> we used it to concentrate on certain features every week that are 1. of priority, 2. ready to receive active attention
14:28:37 <EmilienM> thoughts on ^?
14:28:50 <shardy> We tried etherpad for priorities a few times - it always ends with everyone putting their stuff on there, so everything is a priority ;)
14:29:07 <EmilienM> shardy: ha, was it for mitaka cycle?
14:29:09 <shardy> at least with launchpad we have a way to groom the tasks
14:29:12 <EmilienM> or liberty, I can't recall
14:29:23 <jpich> My impression is that it's more useful toward the end, when there can be a lot of "High" priority stuff but we know we won't be able to land everything, so focusing attention can help...
14:29:25 <EmilienM> if we have all bugs / blueprints in launchpad with the right milestone, i don't think we need to duplicate in an etherpad
14:29:28 <dtantsur> we ask people not to put anything there :) it's populated by the PTL/meeting chair
14:29:34 <shardy> e.g by bumping something to pike, or setting it low priority, you communicate to at least the core team that it's not a priority until after the release
14:29:37 * bkero is reminded of bugzilla's P1, P2 ... P6 for priority sorting.
14:29:55 <jpich> but TripleO is fairly decent at triaging bugs so Launchpad could easily be The Source
14:30:15 <dtantsur> ack, I just shared our approach :)
14:30:24 <shardy> dtantsur: cool, well it's possibly worth trying again, thanks for sharing :)
14:30:33 <jtomasek> I see launchpad as a good tool for this if used properly
14:30:43 <EmilienM> dtantsur: and we like having your feedback, thanks. I'll clone your idea of week roadmap if you don't mind
14:30:49 <EmilienM> dtantsur: it might be useful for some folks
14:31:00 <dtantsur> sure!
14:31:08 <EmilienM> dtantsur: and read tripleo emails ! lol
14:31:23 <dtantsur> well, I have the [tripleo] tag enable, dunno why I don't see them....
14:31:28 <EmilienM> do we have anything else about $topic?
14:31:46 <EmilienM> #topic Projects releases or stable backports
14:31:57 <EmilienM> #link https://releases.openstack.org/ocata/schedule.html
14:31:59 <EmilienM> #info python-tripleoclient 6.0.0 is released
14:32:01 <EmilienM> #link http://docs.openstack.org/releasenotes/python-tripleoclient/ocata.html#id1
14:32:03 <EmilienM> #info python-tripleoclient has stable/ocata branch
14:32:05 <EmilienM> Thanks everyone involved in that, specially tripleoclient contributors!
14:32:25 <panda> phew
14:32:29 <jpich> Release notes :)
14:32:53 <EmilienM> This week is feature and CI freeze, which means we will block all new features in TripleO (and big changes in CI), except the one where a blueprint has been accepted for ocata-rc1.
14:32:57 <EmilienM> I already moved all remaining blueprints to ocata-rc1 but some of them will probably move to pike-1. I'll talk with owners case by case if needed.
14:33:01 <EmilienM> Feel free to reach out for FFE if you're working on a feature that you want in Ocata (openstack-dev).
14:33:04 <EmilienM> #action TripleO core reviewers to block new features in TripleO unless FFE has been granted.
14:33:08 <EmilienM> #action EmilienM to work on TripleO RC1 schedule and propose it on openstack-dev
14:33:12 <EmilienM> #action EmilienM to move remaining blueprints to pike-1 when needed
14:33:19 <EmilienM> thoughts?
14:33:40 <shardy> EmilienM: to clarify, do you want an email to openstack-dev asking for a FFE if a blueprint is already targetted to ocata-1?
14:33:54 <shardy> or is that the list you've already accepted by talking to folks?
14:33:57 <EmilienM> shardy: yes and block everything else that is a feature
14:34:06 <shardy> EmilienM: Ok will do
14:34:13 <EmilienM> shardy: I didn't accept anything yet
14:34:19 <EmilienM> I'll start to look at the list today
14:34:19 <shardy> beagles: ^^ related to my comment on https://review.openstack.org/#/c/411874/
14:34:26 <EmilienM> ok in other words :
14:34:32 * dtantsur is sorry as it seems like he sneak-merged node autodiscovery
14:34:48 <beagles> shardy: yup, thanks btw!
14:34:55 <EmilienM> "if your blueprint is not implemented now, you're candidate for sending FFE"
14:35:03 <shardy> dtantsur: heh, yeah I did think that after I approve it...
14:35:31 <dtantsur> lol, don't worry, things happen, I won't blame you ;)
14:35:43 <jpich> Deadline for not needing FFE is Thursday then?
14:35:45 <EmilienM> #action EmilienM sends a reminder about FFE / RC1 policy on openstack-dev
14:35:58 <shardy> jpich: No it was last Friday AFAIK
14:36:11 <EmilienM> shardy: well
14:36:18 <EmilienM> in TripleO we are cool
14:36:19 <jpich> shardy: With the cycle-trailing thing I'm never too sure...
14:36:31 <shardy> jpich: ah, true
14:36:32 <EmilienM> so I would let until Friday to folks who want FFE
14:36:39 <shardy> EmilienM: Ok, sounds good, thanks
14:36:42 <EmilienM> and I'll send an email today
14:37:03 <jpich> Cool, thanks
14:37:10 <EmilienM> any question / feedback so far?
14:37:46 <EmilienM> #topic CI
14:37:58 <EmilienM> #link http://tripleo.org/cistatus.html
14:38:13 <EmilienM> so CI looks pretty stable this week
14:38:25 <EmilienM> I would like to share a new Trello board, that folks dealing with issues are using
14:38:31 <EmilienM> #link https://trello.com/b/WXJTwsuU/tripleo-and-rdo-ci-status
14:38:47 <EmilienM> this Trello board is useful to track the different issues we have between RDO & TripleO CIs
14:38:56 <EmilienM> we still rely on Launchpad to track the bugs
14:39:24 <panda> I'd like to say something about the freeze
14:39:31 <EmilienM> panda: sure, go ahead
14:39:54 <panda> it seems inevitable to propose and merge small very useful changes, despite the freeze
14:40:18 <EmilienM> panda: "no big change", that's it
14:40:19 <panda> but since we are transitioning, all those changes have to be ported to quickstart
14:40:34 <EmilienM> panda: in other words: "please don't add a risk to break jobs"
14:40:57 <panda> I'd like to ask people, when proposing changes to tripleo-ci, to try and propose the equivalent change in quickstart too
14:41:13 <trown> hmm... I also understood CI feature freeze to be actual freeze
14:41:41 <trown> kind of difficult to keep having full coverage via quickstart be a moving target
14:41:46 <EmilienM> trown: right, in theory we should be in "bugfix" mode until we release ocata
14:41:48 <panda> or at least open a bug, so keeping track of all the changes, now that the work for the transition has started, could be done more easily
14:42:25 <panda> or we'll find ourselves chasing all the small changes, and some of them may end up lost in transition
14:42:53 <EmilienM> panda: we might want to announce that on mailing-list and also probably document it for our developers
14:43:24 <panda> sure, I'll take care of this
14:43:31 <EmilienM> ok
14:44:06 <EmilienM> #action panda to email openstack-dev about quickstart & tripleo-ci changes
14:44:24 <EmilienM> anything else about CI?
14:44:36 <ansiwen> I have a question
14:44:44 <ansiwen> hope it hasn't been addressed before:
14:44:45 <EmilienM> shardy, marios: how is undercloud upgrade / overcloud upgrade CI jobs going?
14:45:10 <marios> EmilienM: more for matbu/shardy
14:45:13 <ansiwen> how could it happen that the python-pandas package requirements killed CI, is there something not properly gated?
14:45:30 <EmilienM> ansiwen: yes, the dependencies in RDO are not gated (yet)
14:45:42 <EmilienM> and AFIK they will be gates once RDO Cloud is alive
14:45:49 <EmilienM> gated*
14:46:02 <matbu> shardy: looks pretty good
14:46:06 <matbu> ooops
14:46:11 <matbu> EmilienM: ^
14:46:19 <matbu> i mean the OC upgrade
14:46:31 <matbu> i'm not if the UC upgrade is fixed now
14:46:37 <matbu> sure*
14:46:40 <EmilienM> matbu: ok, I'm still trying to make the scenario001 upgrade working but I have some issues with tripleo-ci, I'll catchup with shardy later
14:46:45 <EmilienM> matbu: it is
14:46:52 <shardy> EmilienM: Yeah the oc upgrades job has been pretty stable, but there are a few services it's not currently testing
14:47:02 <EmilienM> shardy: any blocker so far?
14:47:06 <ansiwen> EmilienM: what time-period is that to be expected? weeks, months? it seems to me like a high risk.
14:47:08 <shardy> in particular we need to land pacemaker and nova support, and get those tested
14:47:15 <EmilienM> ansiwen: I don't know
14:47:34 <shardy> EmilienM: mainly we've been delayed figuring out all the nova things, but sounds like that is quite close now matbu ?
14:47:53 <matbu> shardy: yep i hope
14:48:10 <matbu> pacemaker is (almost?) done i think
14:48:11 <EmilienM> (/me sends kudo to mwhahaha for all the work on puppet-nova)
14:48:28 <EmilienM> matbu: good progress
14:48:31 <EmilienM> anything on CI this week?
14:48:43 <shardy> EmilienM: Ok then no blockers, we need to keep testing and land the remaining patches this week
14:48:44 <EmilienM> ansiwen: you better ask this question on #rdo
14:48:49 <EmilienM> shardy: ack
14:48:52 <EmilienM> #topic Specs
14:48:54 <shardy> and do more manual testing of upgrades where operator driven computes happen
14:48:58 <EmilienM> #link https://review.openstack.org/#/q/project:openstack/tripleo-specs+status:open
14:49:12 <EmilienM> is there any spec to discuss this week?
14:49:27 <shardy> yeah kudos to mwhahaha and owalsh for all the nova help
14:49:37 <EmilienM> #link https://etherpad.openstack.org/p/tripleo-ptg-pike
14:49:45 <EmilienM> for those who want to propose a design session
14:50:09 <EmilienM> if nothing about specs, I'll just open the discussion
14:50:12 <EmilienM> #topic open discussion
14:50:25 <EmilienM> if you have any question, need review, or feedback, please go ahead
14:51:24 <EmilienM> ok, thanks everyone
14:51:31 <EmilienM> have a good week and keep rocking!
14:51:33 <EmilienM> #endmeeting