20:03:07 <ttx> #startmeeting tc
20:03:07 <openstack> Meeting started Tue Jan 21 20:03:07 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:03:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:03:10 <openstack> The meeting name has been set to 'tc'
20:03:13 <lifeless> sailboat of course
20:03:18 <markmc> lifeless, of course :)
20:03:19 <ttx> Our agenda for today:
20:03:22 <mikal> Hi
20:03:23 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:03:41 <ttx> #topic Clarify "Project must be part of the integrated gate" as a graduation requirement
20:03:47 <ttx> Last week during the incubation status review there was a lot of confusion around this requirement
20:03:56 <ttx> Mostly around a chicken-and-egg issue (project can't be a true part of integrated gate until it's actually integrated)
20:04:07 <ttx> So I would like us to clarify this requirement
20:04:20 <lifeless> whats confusing?
20:04:22 <ttx> sdague: could you explain what you had in mind when you originally mentioned it ?
20:04:39 <sdague> ttx: it's a graduation requirement
20:04:46 <ttx> lifeless: (project can't be a true part of integrated gate until it's actually integrated, so requiring it pre-graduation is a bit weird)
20:04:48 <sdague> so when we cut Juno
20:05:04 <sdague> the projects we say are in Juno would be sharing a gate job
20:05:11 <ttx> graduation to become part of Juno happens before we release Icehouse
20:05:30 <lifeless> ttx: the integrated gate isn't defined as 'the integrated API projects' is it? I thought it was 'the gate that zuul has that has all the symmetrically tested projects'
20:05:41 <sdague> so graduation for Juno is actually Juno release day
20:05:44 <lifeless> ttx: and thus includes clients, helpers, oslo libraries and more
20:05:45 <sdague> in my terminology
20:06:01 <sdague> not attaining integrated status
20:06:14 <sdague> maybe my wording was bad
20:06:20 <lifeless> ttx: so I think its a terminology issue
20:06:21 <ttx> sdague: they graduate and undergo a full cycle of development before being included in a final release
20:06:22 <russellb> i think that's what we're trying to clear up :)
20:06:34 <sdague> yeh, ok, pick a different word
20:06:34 <mordred> I had understood this to mean that the project in question had a dvsm-tempest job that it gated on, so that we could verify that, on graduation, all we'd need to do to have them in the integrated gate would be to change some defaults in teh global gate
20:06:34 <lifeless> russellb: fair enough
20:06:42 <ttx> https://wiki.openstack.org/wiki/Governance/NewProjects
20:06:56 <russellb> mordred: that works
20:07:00 <sdague> if you are integrated by the time yuo get to the stable release with your inclusion, there are things yuo need to do
20:07:00 <lifeless> mordred: I think we should require symmetric gating
20:07:04 <vishy> o/ sorry guys, last meeting went 5 min over
20:07:10 <mordred> we canont require symmetrical gating
20:07:12 <ttx> mordred: yes, that would work for me
20:07:19 <mordred> as a requirement to determine if we'll add you to the symmetric gate
20:07:25 <ttx> just wanted to make sure everyone is on hte same page
20:07:38 <lifeless> mordred: not as a requirement to be added to the symmetric gate, but as a requirement for graduation
20:07:50 <sdague> ttx: so what do we call the transition of a project to it's first stable release?
20:07:51 <ttx> one of the first thing they add during that common dev cycle after they graduate is that gate integration
20:07:57 <mordred> we do not gate integrated projects on non-integrated projects
20:08:00 <mordred> nor do I think we should
20:08:13 <russellb> +1
20:08:15 <lifeless> mordred: we gate on projects that are not part of the integrated release
20:08:18 <ttx> sdague: its first integrated development cycle ?
20:08:21 <mordred> lifeless: no, we do not
20:08:31 <russellb> i think a gate job for the project that clearly demonstrates that it'd be easy to flip the switch to have it in the integrated gate is enough
20:08:32 <lifeless> mordred: so python-novaclient isn't gated on ?
20:08:40 <sdague> russellb: +1
20:08:48 <ttx> mordred: would you care to suggest a wording to replace that line from the graduation-requirements doc ?
20:08:49 <devananda> ttx: "graduate and undergo a full cycle of development ..." -- this means projects which might graduate this cycle would NOT be included in Icehouse release. is taht correct?
20:08:50 <mordred> lifeless: server projects
20:08:55 <SergeyLukjanov> russellb, fwiw agreed
20:09:02 <jeblair> russellb: yes, that's what i was envisioning.
20:09:02 <ttx> devananda: yes
20:09:13 <mordred> russellb: ++
20:09:14 <russellb> sdague: if that was the original intent, we just need to clarify the wording, and i think we're good ...
20:09:16 <devananda> ttx: k, thanks for clarifying that
20:09:22 <ttx> projects graduating at the end of the icehouse cycle are to be patr of the full Juno cycle
20:09:22 <annegentle> I like the graduate plus undergo full cycle fwiw
20:09:23 <sdague> russellb: yes, that was the original intent
20:09:25 <russellb> cool
20:09:36 <ttx> that lets us catch up on all those things
20:09:38 <russellb> I can propose an update if you want, or you can, whichever
20:09:43 <sdague> ttx: ok, come up with a word for what Trove does when we get to Icehouse
20:09:45 <ttx> and give them equal footing in summit/meetigs
20:09:49 <sdague> all we need is a word for that event
20:09:54 <sdague> then this is clear
20:09:58 <ttx> sdague: "makes its first integrated release"
20:10:06 <sdague> ok, that's the word
20:10:09 <ttx> "release" would be the word
20:10:25 <markmc> yeah, the interesting part is the start of the cycle
20:10:26 <ttx> as in "there is one full cycle beween graduation and release"
20:10:54 <ttx> any volunteer to submit a wording clarification ?
20:10:59 <ttx> mordred, sdague ?
20:11:12 <sdague> ok, so I'm confused how people were reading the doc before. Because graduation == release to me. As there is a separate section on integration
20:11:21 <devananda> sdague: taht was my reading as well
20:11:38 <mordred> graduation == "be accepted into the intgrated gate"
20:11:48 <ttx> https://wiki.openstack.org/wiki/Governance/NewProjects has a diagram that should make it clear
20:11:51 <mordred> release == "be released as part of the integrated release"
20:11:57 <markmc> let's draft here: https://etherpad.openstack.org/p/graduation-gate-requirement
20:12:00 <hub_cap> inagural?
20:12:02 * markmc copies and pastes
20:12:08 <devananda> hence my confusion around testing Ironic this cycle. it sounds like we dont need to get all the testing up by Icehouse to graduate
20:12:13 <devananda> which was part of the requirement, i thought
20:12:19 <mordred> devananda: you do
20:12:28 <devananda> mordred: asymmetric?
20:12:32 <mordred> devananda: yes
20:12:36 <russellb> https://review.openstack.org/68229
20:12:39 <ttx> basically, once you graduate, we announce to the world you will be patr of the next openstack release
20:12:40 <devananda> mordred: ah. that wasn't clear in the doc
20:12:43 <mordred> then we'll turn it symmetric when you graduate
20:12:47 <ttx> it's not easy to back off frmo that
20:13:08 <ttx> so we need to have as much as we can nailed by graduation time
20:13:12 <markmc> "** Project must have a gate job running which can be added to the integrated gate after graduation" ?
20:13:14 <russellb> markmc: ah sorry, missed that
20:13:24 <sdague> yeh, s/graduation/release/
20:13:28 <sdague> and you are +1 from me
20:13:32 <devananda> markmc: sure, but that's not clearly asying an *asymmetric* job
20:13:34 <mordred> sdague: no
20:13:37 <devananda> so I read it as "part of the gate"
20:13:38 <markmc> russellb, cool
20:13:38 <mordred> sdague: graduation is correct
20:13:44 <russellb> i had ... +** Project must have a devstack-gate job running, including functional tests, that demonstrates that it would be easy to add the project to the integrated gate after graduation.
20:13:49 <mordred> sdague: release comes 6 months after graduation
20:14:09 <ttx> Also note that we have "Project must have a basic devstack-gate job set up" as an INCUBATION requirement
20:14:14 <mordred> ++
20:14:20 <russellb> basic job (with nothing about what it actually does)
20:14:26 <ttx> is that too much for incubation ?
20:14:27 <russellb> graduation: job with real tests
20:14:32 <russellb> basic job, don't think so
20:14:33 <ttx> russellb: ok ++
20:14:36 <mordred> I believe intent there was "devstack can install your project"
20:14:44 <mordred> and things don't fall to pieces
20:14:46 <russellb> for incubation, a job that just starts the API service and that's it may be enough
20:14:51 <mordred> ++
20:14:51 <russellb> just get it installed and run it
20:15:05 <sdague> ok. I'll trust you on this one mordred.
20:15:07 <ttx> like a job skeleton
20:15:11 <russellb> yeah
20:15:12 <sdague> yep
20:15:22 <russellb> there's a lot you have to get right to get that far, so it's valuable
20:15:28 <ttx> mordred: you propose the wording change ? I think we have the direction clearly set now
20:15:32 <mordred> ttx: ok
20:15:40 <russellb> i have a WIP -- https://review.openstack.org/68229
20:15:45 <ttx> ok, moving on then
20:15:53 <mordred> russellb: ++
20:15:57 <sdague> russellb: looks good
20:16:04 <ttx> #action mordred/russelb to suggest wording change for QA graduation requirement
20:16:14 <ttx> #topic Mid-cycle incubation status review: Marconi
20:16:28 <ttx> Like last week, the idea here is to check the current state of the project w/ the graduation requirements
20:16:31 <kgriffs> o/
20:16:35 <ttx> #link http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements#n56
20:16:49 <flaper87> o/
20:16:50 * alcabrera listens in
20:16:52 <russellb> have a handy page with notes on your status?
20:17:06 <kgriffs> so, we have a few things
20:17:17 <kgriffs> first, we have a tracking bp for graduation: https://blueprints.launchpad.net/marconi/+spec/graduation
20:17:36 <ttx> kgriffs: You mentioned to me you might pass on graduation for Juno. Did you change mind ?
20:17:55 <kgriffs> before I answer that, I need to clarify some things
20:18:02 <ttx> kgriffs: we are listening
20:18:28 <kgriffs> first, if we wanted to graduate to be integrated in Juno, we would need to be ready when? i-3 ?
20:18:45 <kgriffs> or sooner?
20:18:49 <ttx> we usually do the graduation review just before juno PTL election
20:19:06 <ttx> so that would be sometimes in March
20:19:11 <kgriffs> ah, ok
20:19:15 <ttx> post i-3
20:19:27 <kgriffs> so, assuming we participate fully in i-2 and i-3
20:19:43 <kgriffs> and have all our code ready by i-3
20:19:52 <kgriffs> we could maybe have a few weeks extra to work on docs?
20:19:53 <ttx> as far as release management goes if you get on board by i-2 you're golden
20:20:18 <ttx> kgriffs: sounds doable
20:20:56 <kgriffs> ok. If we can have until mid-march to get the docs requirement taken care of, then I would like to still try to graduate this cycle
20:21:14 <ttx> kgriffs: so, what are the gaps ?
20:21:15 <markmc> I honestly can't remember the feedback we gave marconi on incubation
20:21:21 <markmc> right, the gaps :)
20:21:30 <kgriffs> markmc: let me grab a link
20:21:33 <markmc> e.g. is falcon to pecan a requirement from the TC's perspective?
20:21:46 * ttx 's brain is a bit fried by jetlag. Or frozen.
20:22:00 <flaper87> https://wiki.openstack.org/wiki/Marconi/Incubation/Graduation
20:22:04 <kgriffs> so, it was not a requirement to swap it out
20:22:04 <markmc> thanks flaper87
20:22:09 <ttx> markmc: ISTR supporting pecan as an optoin was a requirement
20:22:11 <flaper87> markmc: :)
20:22:16 <kgriffs> the requirement was that we do due diligence on evaluating pecan
20:22:24 <markmc> ok
20:22:32 <annegentle> kgriffs: why the need for a few more weeks for docs? Just wondering
20:22:47 <kgriffs> with the understanding that if it looks good, we would migrate to it, but that could happen post graduation
20:22:56 <kgriffs> annegentle: we are short-handed
20:22:56 <ttx> kgriffs: was that due diligence done yet ?
20:23:03 <kgriffs> I am going to try to get everything done by i-3
20:23:17 <flaper87> ttx: work in progress https://blueprints.launchpad.net/marconi/+spec/pecan-framework
20:23:20 <kgriffs> but docs may come in a bit late depending on if we can recruit some more folks or not
20:23:25 <flaper87> ttx: there's 1 guy dedicated to that full time
20:23:43 <sdague> kgriffs: yeh, I think that due dilligence kind of needs to come first, because putting another web stack as an overall requirement for openstack integrated is kind of a big deal
20:24:05 <markmc> interesting that heat integration is a requirement
20:24:16 <kgriffs> markmc: so, that is more of a "nice to have" I suppose
20:24:21 <ttx> kgriffs: overall, that sounds like an impressive number of checkboxes to check given how much time and resources you have left, but it's still worth trying
20:24:27 <mordred> honestly - if I had to chose between you guys spending time on pecan dilligence and spending time on devstack/tempest integration testing ... I'd rather testing happen
20:24:43 <russellb> sqlalchemy driver still a requirement, yes?
20:24:45 <kgriffs> so, devstack/tempest is mostly done - we are waiting on reviews
20:24:46 <malini> mordred: I already have some outsanding patches for devstack/tempest
20:24:52 <mordred> malini: awesome
20:24:53 <markmc> kgriffs, might be worth clarifying there which are requirements vs nice-to-haves
20:24:55 <kgriffs> yes, sqlalchemy is a hard requirement
20:24:59 <russellb> cool
20:25:00 <flaper87> mordred: malini is working full time on that
20:25:08 <mordred> I see sqlalchemy in the tree
20:25:15 <kgriffs> that work is in progress (sqlalchemy) - already had a few patches land for that
20:25:30 <flaper87> sqlalchemy is moving a bit slow but we can speed that up. The structure is there, the implementation needs to be completed
20:25:37 <kgriffs> let me clean up that wiki page - it isn't clear what is a hard grad req.
20:25:48 <kgriffs> the graduation bp is more accurate
20:26:15 <kgriffs> flaper87: yep, we have already talked about getting another pair of hands on that to help speed up the work
20:27:28 <kgriffs> ok, refresh that wiki page
20:27:41 <flaper87> FWIW, the client library is almost done. There's just 1 feature missing and we already released an alpha version of it: https://pypi.python.org/pypi/python-marconiclient/0.0.1a1
20:27:47 <ttx> kgriffs: what about the process requirements ? core team size, diversity ?
20:28:02 <kgriffs> i don't think there were any changes we had to make
20:28:17 <kgriffs> we already had good diversity
20:28:23 <kgriffs> and the team has been steadily growing
20:28:29 <russellb> reference: http://stackalytics.com/?release=icehouse&metric=commits&module=marconi
20:28:53 <ttx> ok, looks good
20:28:56 <kgriffs> IBM has been ramping up
20:29:00 <ttx> comments anyone ? questions ?
20:29:09 <kgriffs> looking forward to them taking a bigger slice of the pie
20:29:22 <flaper87> to be more detailed: 3 core members (2 RAX, 1 RH) 2 more contributors from RH, 2 more from RAX, 1 guy from IBM and another guy from the community
20:29:31 <flaper87> also Cindy from GOPW
20:29:37 <flaper87> (re diversity)
20:30:07 <flaper87> and the teams seems to keep growing, thankfully
20:30:10 <kgriffs> I'm hoping to promote another core member within the next few months
20:30:15 <ttx> so in summary, lots of work to do on the dev side, but no blocker so far
20:30:18 <kgriffs> (probably from IBM)
20:30:25 <kgriffs> ttx: right
20:30:31 <ttx> #info Marconi looks good, lots of work to do on the dev side, but no blocker so far
20:30:54 <ttx> kgriffs: we'll do the i-2 common release, too
20:31:00 <kgriffs> yep
20:31:02 <flaper87> thanks guys! :)
20:31:05 * flaper87 STFU now
20:31:07 <ttx> last comments before we switch to nex ttopic ?
20:31:10 <annegentle> kgriffs: people are asking good questions about marconi docs of me, so there's that :) But yes, get resources on it.
20:31:15 <ttx> damn sticky keys
20:31:22 <kgriffs> ttx: what is the cutoff for i-2? meaning, when does it get tagged/branched today (UTC)?
20:31:33 <ttx> kgriffs: next meeting. Normally yes.
20:31:44 <ttx> but these are exceptional times
20:31:46 <kgriffs> annegentle: definitely - docs are a high priority, we are just looking for helping hands
20:31:59 <ttx> mikal: you around ?
20:32:04 <mikal> Yep
20:32:09 <ttx> #topic Requirements for third party test systems
20:32:14 <ttx> #link http://lists.openstack.org/pipermail/openstack-tc/2014-January/000487.html
20:32:20 <ttx> mikal: i'll let you introduce the topic
20:32:26 <mikal> Cool
20:32:34 <mikal> So I think this is mostly informational unless we're really upset
20:32:46 <mikal> I wanted the TC to be aware of the general push for third party CI which is happening at the moment
20:32:58 <mikal> Its causing some social problems, as these systems seem to be being built by people we didn't expect
20:33:07 <mikal> i.e. ops people who are not ATCs and never use gerrit
20:33:14 <lifeless> mikal: the spanish inquisition ?
20:33:23 <mikal> anteaya has had problems with systems going rogue and leaving bad votes lying around all over the place for example
20:33:31 <anteaya> it just feels like the spanish inquisition
20:33:37 <mikal> So, there's a few things here
20:33:39 <lifeless> anteaya: nobody expects...
20:33:45 <mikal> - we need clearer expectations of these systems
20:33:49 <anteaya> mostly because I am a point of contact for the rogue
20:33:52 <mikal> (which infra is working on already)
20:33:59 <jeblair> #link https://review.openstack.org/#/c/63478/7/doc/source/third_party.rst
20:34:07 <sdague> mikal: one other thing I'd like to see is an output template for expected results
20:34:09 <mikal> - PTLs need to be careful with the deadlines they set because of the load they place on anteaya / infra
20:34:13 <sdague> because that seems all over the board
20:34:33 <mikal> sdague: yes, although I don't think I agree with the assumption that tempest should always be the test run
20:34:41 <sdague> mikal: agreed
20:34:43 <mikal> sdague: that's true for driver authors, but not for meta testing
20:34:47 <jgriffith> mikal: sdague why not?
20:34:50 <sdague> but in the summery post
20:35:00 <jgriffith> mikal: sdague if that's what we use to gate, why woulnd't it be the same?
20:35:01 <sdague> we need some consistency on naming
20:35:03 <mikal> jgriffith: why not tempest?
20:35:20 <mikal> jgriffith: well, with db ci for example, tempest doesn't exercise what we're trying to test.
20:35:27 <mikal> jhenner: or at least exercises way more than we need
20:35:33 <mikal> sorry, jgriffith there
20:35:50 <jgriffith> mikal: so I think we need to think about different projects/etc
20:35:54 <sdague> mikal: you want output template suggestions in the same doc?
20:35:59 <jgriffith> mikal: cinder for example "better" require tempest IMO
20:36:04 <mikal> sdague: I think that makes sense
20:36:04 <lifeless> jgriffith: tempest starts with a cloud, so anything meta is perhaps awkward
20:36:12 <sdague> mikal: ok, I'll submit something
20:36:13 <anteaya> also stackforge-fuel https://review.openstack.org/#/dashboard/8971
20:36:17 <jgriffith> lifeless: I don't even know what that means?
20:36:19 <mikal> jgriffith: I think you should require tempest from _driver_ authors
20:36:24 <anteaya> tests only stackforge things
20:36:30 <jgriffith> mikal: exactly.. yes
20:36:33 <mikal> jgriffith: if someone wanted to test some non-driver thing, then that should be ok to be outside tempest
20:36:53 <mikal> jgriffith: well, outside of tempest if it makes sense to be outside tempest
20:36:54 <sdague> jgriffith: we also have other 3rd party testing, like mikal's turbo-hipster which is a functional test for db performance on real data
20:36:58 <jgriffith> mikal: I think we may be bighting off too big a piece of cake at once
20:37:06 <jgriffith> sdague: ok
20:37:11 <ttx> mikal: is this more for information, or do you need the TC to come up with some sort of decision here ?
20:37:19 <jgriffith> sdague: I'm with you now
20:37:20 <devananda> assuming that different drivers have (nearly) the sme functionality, reusing existing tempest tests for a project seems logical.
20:37:20 <mikal> What specifically caused me to want to talk about this was the neutron i-2 deadline
20:37:23 <devananda> is that a false assumption?
20:37:34 <jgriffith> sdague: mikal but I think there should be different docs/processes for the different types of testing
20:37:35 <anteaya> current 3rd party testing accounts: https://review.openstack.org/#/admin/groups/91,members
20:37:38 <ttx> mikal: because so far that sounds like something we could discuss on the cross-project meeting too
20:37:46 <mikal> ttx: well, if the tc is happy with that code review...
20:37:46 <devananda> mikal: though i understand your pointthat non-driver third-party tests may not be suitable for tempest
20:37:51 <annegentle> anteaya: thanks was just going to ask for a list
20:37:57 <mikal> ttx: then I just want PTLs to talk to infra before issuing deadlines in public
20:38:01 <anteaya> :D
20:38:08 <mikal> ttx: so yeah, informational
20:38:19 <mikal> Also, anteya I suspect could do with more support from core devs
20:38:24 <sdague> I think we should also all recognize this has been a learning experience
20:38:27 <anteaya> the deadline email in question: http://lists.openstack.org/pipermail/openstack-dev/2013-November/019219.html
20:38:27 <mikal> i.e. help with cleaning up misvotes etc
20:38:34 <sdague> and that we might need to adapt as we go
20:38:34 <ttx> mikal: given that PTLs != TC I think we should echo that discussion on the cross-project meeting too
20:38:42 <mordred> ++
20:38:42 <mikal> ttx: agreed
20:38:48 <NobodyCam> -infra just a passing "Great Job guys!"
20:38:50 <anteaya> also markmcclain is doing the first day of hr at new job so he isn't here atm
20:38:51 <mikal> ttx: I wanted to make sure I was in alignment with the tc first thugh
20:39:02 <jeblair> yes, we did not anticpate these problems but i think we can work through them and deal with them.
20:39:02 <mikal> though
20:39:16 <lifeless> more than just talking to infra; I think folk need to recognize it takes 6m+ for a testing system to get the bugs ironed out
20:39:17 <ttx> mikal: I think more coordination cannot hurt
20:39:21 <anteaya> more discussion is welcome
20:39:21 <lifeless> realistic deadlines...
20:39:41 <mikal> ttx: there was also talk about how we decide to grant voting rights to 3rd party testers
20:39:47 <mikal> ttx: that might be a tc thing if we want to get involved
20:39:54 <mikal> ttx: or we can leave it to the ptl
20:39:59 <mikal> I don't have strong opinions there
20:40:04 <ttx> mikal: can become a TC thing is that cannot be solved at a lower level
20:40:07 <mordred> I think leave to ptl until it's an issue
20:40:10 <jgriffith> mikal: I do :)
20:40:13 <ttx> mordred: +1
20:40:26 <mikal> jgriffith: what is your opinion?
20:40:27 <jeblair> i think infra can do objective evaluation
20:40:37 <sdague> yeh, I'd say we can take this out of TC
20:40:43 <jgriffith> mikal: external items I don't think should vote
20:40:47 <jeblair> if voting rights is a subjective question, i'd like ptl involvement
20:40:48 <mikal> jeblair: there was concern that puts infra "on the hook"
20:40:53 <jgriffith> mikal: they're out of the control of infra/community
20:41:06 <jgriffith> mikal: leaves us in a *bad* spot IMO
20:41:19 <jgriffith> mikal: at least to start
20:41:22 <mikal> jgriffith: I don't think there's concensus there
20:41:29 <anteaya> also in cross project testing like smokestack, which ptl's opinion breaks a tie?
20:41:29 <jgriffith> mikal: if the tests are on our infra I'm all for it
20:41:31 <mikal> jgriffith: oh, there is on "at the start"
20:41:39 <jgriffith> mikal: if they're external I don't think they should vote
20:41:44 <mikal> jgriffith:  the current proposal is you don't vote for like the fix 6 months or whatever
20:41:48 <markmc> IMHO, V -/+1 votes aren't all that different from R -/+1 votes
20:41:53 <markmc> you learn to trust some and ignore others
20:41:54 <jgriffith> mikal: I just envision gate clogging due to third party infra
20:42:01 <ttx> anteaya: no need to vote. If there is no consensus, that can be brought to tc
20:42:03 <mordred> jgriffith: I think when we say vote - we mean +1/-1 - never +2/-2
20:42:04 <mikal> markmc: the problem is devs who filter on verified status
20:42:07 <devananda> mikal: I think non-voting until there is PTL confidence
20:42:10 <anteaya> ttx k
20:42:13 <markmc> so be permissive in giving rights
20:42:13 <jgriffith> mordred: but what about -1
20:42:18 <mikal> devananda: yeah, that's where we were going
20:42:20 <mordred> jgriffith: it's non-blocking
20:42:26 <devananda> mordred: i don't think -1 should be allowed until there is confidence in the third-party system being truthful about that -1
20:42:28 <jgriffith> mordred: ok, that's what I was getting at
20:42:28 <mikal> jgriffith: well, we're talking check queue here, not gate queue
20:42:31 <jgriffith> mordred: mikal sorry
20:42:35 <jgriffith> carry on :)
20:42:36 <mordred> devananda: ++ I do agree with that
20:42:42 <mikal> IIRC infra already has a policy that gate checks must be run by infra
20:42:50 <sdague> so given the level of debate.... ML thread?
20:42:58 <sdague> I don't think this should be trapped in the tc
20:43:03 <ttx> sdague: yep. And then cross-project meeting topic
20:43:07 <mikal> Works for me
20:43:12 <ttx> ok, moving on
20:43:14 <lifeless> mikal: it does
20:43:18 <mikal> Noting that the people we're trying to talk to don't read our mailing lists
20:43:20 <lifeless> mikal: but things can change :P
20:43:26 <ttx> mikal: too bad
20:43:33 <ttx> #topic Recommendation to deprecate XML in new major API versions
20:43:40 <ttx> #link http://lists.openstack.org/pipermail/openstack-tc/2014-January/000494.html
20:43:48 <ttx> So I think it's definitely in our realm to make such a "recommendation"
20:43:59 <ttx> With the projects PTLs being the ultimate deciders on what they want to support or not, based on their project history and users
20:44:03 <sdague> right, so this thread is in a couple of different forums, -dev, general list, and -tc
20:44:05 <ttx> sdague: could you sum up the reaction on the ML so far ?
20:44:27 <sdague> so far on the general thread the only opposition is pointing to the user survey
20:44:33 <sdague> and the 30% XML number
20:44:45 <sdague> however, it's not really clear to me how that number is possible
20:44:45 <ttx> at the very least  ithink we could say "don't feel forced to support XML in future versions of your API"
20:44:49 <russellb> which i think we should ignore for the most part
20:44:54 <sdague> russellb: agreed
20:44:58 <ttx> if that helps them say no
20:45:02 <mikal> There was some talk internal to Rackspace about getting usage numbers
20:45:07 <mikal> But it doesn't seem to have happened yet
20:45:09 <mikal> Which makes me sad
20:45:12 <sdague> I've asked user committee for some clarification, and better future questions
20:45:15 <russellb> ttx: +1
20:45:19 <russellb> but really should be up to projects
20:45:23 <hub_cap> so what about current api's? could i, say, rip it out of trove if no one complains?
20:45:24 <markmc> russellb, ignore because you think it's unreliable data right?
20:45:29 <russellb> markmc: yes
20:45:37 <markmc> russellb, (just wanna make sure you're not misinterpreted :)
20:45:38 <sdague> markmc: yes, it's suspect data
20:45:39 <russellb> markmc: the question was quite poor for what we're trying to get at
20:45:41 <russellb> markmc: thank you
20:45:54 <sdague> I think I had a general list post sort of discecting that
20:45:59 <devananda> i have the same question as hub_cap -- we were discussing XML support in ironic today. it's currently broken, cause most of our work has been for the JSON API.
20:46:02 <hub_cap> mikal: i _know_ rax dbaas usage was like .2%
20:46:09 <hub_cap> for xml
20:46:18 <sdague> right, so that's actually what I want to do
20:46:20 <devananda> i'll happily just omit XML if there's broad support for not supporting it
20:46:21 <ttx> sdague: so I think there is room for a governance repo change proposal with mild language like "don't feel forced to support XML in fuure major versons of your api"
20:46:29 * mordred in favor of saing xml not required
20:46:32 <hub_cap> yea and ours is unused and id love to nuke it before my first integrated release :)
20:46:33 <russellb> markmc: i really liked your input on the thread btw
20:46:37 <stevebaker> (heat has no xml api and nobody has yet asked for one)
20:46:41 <markmc> russellb, thank you :)
20:46:43 <mordred> stevebaker: ++
20:46:48 <sdague> ttx: yes
20:46:48 <hub_cap> stevebaker: can i have a heat xml api?
20:46:48 <devananda> stevebaker: good to know, thx
20:46:50 <markmc> it's not that I'm trying to save XML support
20:46:54 <markmc> but let's not say "never"
20:46:55 <stevebaker> hub_cap: noes
20:46:56 <hub_cap> now u cant say that :)
20:47:03 <ttx> sdague: that sounds pretty much consensual
20:47:03 <markmc> high bar, we've learned some lessons, etc.
20:47:08 <sdague> or realistically just saying "openstack services need a stable JSON API"
20:47:17 <ttx> sdague: not sure it's really needed but if it makes some projects decisions easier...
20:47:34 <markmc> sdague, speaking of which - I just proposed https://review.openstack.org/#/c/68258/
20:47:45 <markmc> sdague, as a discussion starter
20:47:47 <annegentle> I am sad with mikal
20:47:47 <sdague> I think realistically if we nudge that way, we'll drop most of the XML support in the next set of major releases on API
20:47:53 <mordred> yah
20:47:57 <markmc> most likely
20:48:01 <jeblair> i think we've seen enough feedback right here from recent projects who would have done well to know that xml can be de-prioritized
20:48:05 <sdague> because I think that everyone is keeping it because they think someone told them they had to
20:48:09 <annegentle> but I do think we need to get a better finer set of questions in the survey so we might need to wait for an edict
20:48:09 <russellb> markmc: if heat, how about horizon?
20:48:10 <mordred> sdague: ++
20:48:16 <devananda> sdague: ++
20:48:16 <markmc> russellb, will add
20:48:18 <sdague> and I want to tell them they don't
20:48:27 <sdague> then let the cards fall where they may
20:48:31 <annegentle> sdague: and your points about the downstream effects are well stated
20:48:40 <mordred> yup. and if we get people screaing for us to add xml - then it'll be quite clear :)
20:48:43 <sdague> annegentle: thanks
20:48:51 <russellb> on a fundamental point ... is it ever valuable to support multiple encodings, really?
20:48:57 <russellb> seems silly
20:48:59 <sdague> russellb: I don't think so
20:49:07 <mordred> at this point, json is pretty darned ubiquitous
20:49:10 <russellb> but agree we should not say never
20:49:12 <sdague> which is why you better let me propose the commit to drop XML from v3 :)
20:49:20 <russellb> right, json isn't niche or obscure or anything
20:49:21 <ttx> #action sdague to propose a recommendation about XML not being required in future major versions of APIs
20:49:23 <mordred> sdague: I will +1 that commit
20:49:48 <sdague> ttx: sure, I think markmc has beginning discussion review as well
20:50:01 <russellb> yeah
20:50:01 <hub_cap> do we need to add a note about current versions of the API if projects decide to drop it asap?
20:50:11 <hub_cap> cough, cough, trove
20:50:36 <markmc> russellb, yeah, it can be useful when consuming from different languages or frameworks - think Java EE stuff
20:50:37 <sdague> hub_cap: well, trove hasn't released as integrated yet
20:50:44 <ttx> Trove being arguably "not released yet" I think you can do whatever you want
20:51:01 <sdague> I wouldn't complain if you used that as cover to drop
20:51:02 <markmc> russellb, oVirt API was JSON, XML and YAML at one point
20:51:14 <mordred> markmc: I got feedback from corporate overlords today that json is just as easy for corporate java types these days
20:51:18 <vishy> markmc: those things are valuable if you are actually providing a wadl/wsdl
20:51:21 <vishy> and the thing works
20:51:26 <russellb> markmc: yeah, don't have first hand experience but i've heard that ... in the perfect world in my head all of these things have evolved good json support by now
20:51:33 <markmc> mordred, vishy, fair points
20:51:37 <hub_cap> sweet sdague ttx
20:51:42 <ttx> anything else on that subject ? we still have a couple items to cover
20:51:42 <vishy> otherwise they have to write custom bindings anyway, and it isn't harder to write one talking to json
20:51:42 <sdague> vishy: right, but we haven't been doing that in a working way for a while
20:51:43 <mordred> I think it was much more important when we started openstack than it is now
20:51:52 <mordred> and even then I think it was tenuous
20:52:00 <markmc> maybe something will come along better than JSON :)
20:52:03 <markmc> "never say never"
20:52:06 <sdague> ttx: I'm good
20:52:09 <mordred> markmc: protobuffer!
20:52:09 <russellb> markmc: +1
20:52:15 <ttx> #topic Minor governance changes
20:52:22 <ttx> Program/project mapping (https://review.openstack.org/#/c/65096) just needs more +1s I think
20:52:28 <russellb> markmc: but in your patch "at least JSON" for now seems like a good statement for today
20:52:37 <ttx> or do -1 with a comment if there is a reason you did not approve that one yet
20:52:54 <ttx> Mention scope expansion in incubation requirements (https://review.openstack.org/#/c/62612/)
20:53:04 <ttx> Since this document represents consensual requirements, we originally rejected it because mordred & jgriffith and were -1 on the idea
20:53:12 <ttx> mordred, jgriffith: did your position change on that subject ?
20:53:14 <annegentle> I still need to send a ML post about a user program that contains horizon/cli rather than horizon being a program, to which list does that discussion need to go?
20:53:19 <ttx> I see jgriffith +1ed
20:53:22 * markmc will be lazy and paste his comments from gerrit
20:53:23 <markmc> Main objection seems to be that this is a subjective requirement rather than an objective one. And also a lot of talk about "finite resources".
20:53:23 <markmc> I don't see this being about "finite resources" but instead a "we're not going to add projects which would mean a crazy jump in OpenStack's scope". We're not going to add a gmail SaaS clone, for example.
20:53:23 <markmc> Yes, it's subjective ... but so is e.g. "large and diverse".
20:53:23 <markmc> The goal is twofold - (1) warn authors of new projects that this isn't a free-for-all, even if you tick all the other boxes then there will be a "does this increase of scope make sense?" discussion and (2) reassure those that worry about OpenStack's scope going crazy that we do actually think about this.
20:53:28 <russellb> annegentle: openstack-dev i think
20:53:51 <russellb> annegentle: but i don't think that reflects reality
20:54:02 <russellb> maybe if we have open discussion time ...
20:54:13 <annegentle> russellb: because there's no Dev Experience program? or. Yeah discussion time.
20:54:31 <ttx> markmc: I agree with the goals and I'm ready to +1 the thing. The reason it wasn't approved originally was because jgriffith and mordred didn't like it, and this doc needs consensus
20:54:41 <mordred> markmc: yeah - my concerns are purely that we make sure those goals, which are good, don't come across as prescriptive or legalistic checkboxes
20:54:50 <markmc> ttx, yeah, my reading of the discussion is that the intent was misunderstood
20:55:35 <ttx> markmc: the discussion on reusing "mesaured growth" as a tool to adjust bandwidth for teams like docs is abit orthogonal yes
20:55:35 <markmc> mordred, purely objective requirements are in danger of becoming a checkbox list though
20:55:37 <russellb> i read this as adding "the scope shouldn't be some bonkers crap that came out of left field and is way off from the current scope"
20:55:46 <markmc> mordred, "I ticked all the boxes! You have to take me!"
20:56:04 <markmc> mordred, "uh, no - you're a github clone, that makes no sense"
20:56:14 <mordred> markmc: maybe s/must/should/ and I'd be better
20:56:22 <mordred> or something
20:56:42 <mordred> or - screw it - I'm probably being too nitpicky here
20:56:53 <russellb> heh
20:56:57 <mordred> let me just go back and vote properly in the thing
20:57:06 <ttx> ok, looks like we have a deal
20:57:13 <ttx> #topic Open discussion
20:57:19 <ttx> Anything else, anyone ?
20:57:26 <annegentle> oo oo! Is there a user experience program need?
20:57:30 <russellb> so annegentle ... we've talked a lot before about programs being about teams of people
20:57:42 <russellb> i don't think the people working on all of the CLIs and horizon are a single group
20:57:55 <russellb> so i don't think it makes sense to try to make that a program (right now anyway)
20:58:04 <annegentle> so if the common cli starts to live in oslo, will that hamper progress due to the nature of the program they're under?
20:58:06 <russellb> unless someone steps up to organize such an effort to pull all these things together
20:58:19 <markmc> mordred, changed it to should
20:58:27 <annegentle> or does it actually help the common CLI get more resources
20:58:43 <ttx> russellb: ++
20:58:56 <sdague> annegentle: honestly, I don't think a program declaration is going to get more resources on a thing. Get people working on a thing first
20:59:01 <ttx> I thinnk UX needs some mileage
20:59:07 <russellb> which btw ... i would love to see all the CLIs be pulled together under a team
20:59:12 <sdague> russellb: +1
20:59:15 <russellb> but someone (and a group) has to actually step up to do that
20:59:18 <russellb> we can't force it
20:59:20 <annegentle> russellb: ya ok
20:59:45 <russellb> i've mentioned it to a few people as a possible area to step up and lead
21:00:03 <sdague> the current ML thread (which is massively deep) has some good stuff on it
21:00:03 <russellb> we'll see
21:00:15 <ttx> looks like we are done
21:00:15 <russellb> sdague: cool, that looked promising ... though i fell way behind on it
21:00:20 <sdague> jesse's direction I like
21:00:25 <ttx> #endmeeting