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