20:01:52 <ttx> #startmeeting tc
20:01:53 <openstack> Meeting started Tue Feb 11 20:01:52 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:57 <openstack> The meeting name has been set to 'tc'
20:02:02 <ttx> Our agenda for today:
20:02:07 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:02:21 <ttx> #topic Incubation request: Barbican
20:02:29 <ttx> Original request:
20:02:31 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2014-January/025860.html
20:02:36 <ttx> Etherpad with analysis:
20:02:41 <ttx> #link https://etherpad.openstack.org/p/GFoJ4LpK8A
20:02:50 * ttx refreshes
20:04:12 <ttx> Looks like everything is covered
20:04:32 <russellb> yep
20:04:33 <ttx> jraim: devstack-gate job still missing, but on its way ?
20:04:43 <russellb> really appreciate the hard work since we last talked
20:04:53 <jraim> jraim: the devstack integration is done and the reviews look good, but it hasn't been merged yet
20:04:57 <jraim> we need to poke some people I think
20:05:21 <jraim> russellb: thanks - I appreciate the feedback we've gotten from everyone during this process
20:05:37 <ttx> comments anyone ?
20:05:44 <vishy> yes
20:06:05 <vishy> I was wondering if there were any steps taken based on justinsbs feedback
20:06:05 <annegentle> yes
20:06:12 <vishy> about the apis
20:06:14 <lifeless> ttx: o/
20:06:27 <ttx> lifeless, annegentle: welcome
20:06:31 <jraim> vishy: the issue about having more of the API defined?
20:07:09 <annegentle> jraim: I had also hoped the api docs would be in a public repo for comment and review
20:07:27 <sdague> ttx: o/ as well
20:07:33 <vishy> jraim: the thread here http://lists.openstack.org/pipermail/openstack-dev/2013-September/015477.html
20:08:07 <russellb> technically API docs are listed as a requirement, too ... so have to decide whether we're willing to waive that if they're not there ... also have the devstack-gate issue
20:08:26 <jraim> annegentle: we plan to do that, I think ayoung put in the first review for it
20:08:40 <vishy> jraim: actually wrong thread
20:08:42 <vishy> this one: http://markmail.org/message/erzouim6pnqjaqtz
20:08:49 <jraim> russellb: we do have API docs on our wiki in github and those are being moved to docbook now
20:08:51 <markmc> are these not API docs? https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface
20:08:57 <russellb> jraim: ok
20:09:02 <russellb> nm then
20:09:05 <annegentle> jraim: ah, found it. https://review.openstack.org/#/c/71396/
20:09:21 <jraim> vishy: right. While I sympathize with the problem, I don't think roughing out APIs that don't have code or consumers before they are needed is the right way to go
20:09:29 <vishy> specifically key rotation / symmetric keys
20:09:49 <vishy> so the plan is to figure it out later and fix it in v2?
20:10:24 <jraim> I think the plan is to add those features when there is need and deal with the API changes. Hopefully, we can do them in a backwards compatible manner
20:10:37 <vishy> jraim: ok
20:10:41 <jraim> if we can't, then we'll have to factor that into the implementation
20:10:52 <ttx> vishy: they are entering incubation, not being released just now
20:11:15 <vishy> ttx: I know, I'm unclear on when a 1.0 api would be considered final
20:11:27 <vishy> but it isn't totally obvious that it would be at integration time
20:11:39 <vishy> so I wanted to follow up a bit on justin's concerns
20:11:44 <ttx> vishy: yes, I have a point about that later in the meeting
20:12:00 <ttx> (about the API stability constraints)
20:12:06 <jraim> it is a reasonable concern. I'm not sure how to fix it however. Building stable APIs is hard
20:12:11 <markmc> jraim, what happens "the Cloud Keep initiative" if Barbican enters Incubation?
20:12:17 <jraim> we can try the best we can and then version appropriately
20:12:29 <jraim> markmc: most of our work is already moved over to stackforge
20:12:34 <jeblair> and when we would expect other openstack projects to start using it -- on incubation, in the j cycle, or graduation...
20:12:50 <jraim> CloudKeep might keep some things outside of OpenStack (e.g. vendor plugins, etc)
20:12:58 <jraim> but other than that, I don't have a lot of plans for it
20:13:00 <markmc> jraim, I guess I'm asking what would be part of this new program apart from barbican and python-barbicanclient
20:13:18 <russellb> jraim: which plugins do you expect to be in barbican then?
20:13:28 <markmc> jraim, or how would you decide as PTL what to move into the program from cloudkeep and what to keep in cloudkeep?
20:13:29 <jraim> markmc: right now, I think that's it. We are looking at Dogtag integration which might be its own repo, we'll see how the RedHat guys feel
20:13:54 <russellb> which would you encourage in vs out
20:14:01 <russellb> or how would you decide that
20:14:07 <jraim> markmc: off the top of my head, anything that we would want to use openstack process for (e.g. gerrit, etc) would move over
20:14:16 <jraim> not sure how other projects handle vendor plugins
20:14:22 <jraim> but I'd probably steal their ideas on that one
20:14:39 <jraim> I'd rather default to in OpenStack / in-tree is possible
20:14:42 <russellb> include them all for the most part, as long as they make sense / play by the rules
20:14:43 <mikal> Why wouldn't you want to use our process for everything?
20:14:50 <jraim> and just be mindful of adding things that no one cares about
20:15:03 <markmc> jraim, no https://github.com/stackforge/postern ? and cloudkeep/postern is essentially empty ?
20:15:06 <mikal> Ahhh, ok
20:15:09 <jraim> mikal: if the code is written by a non-contributor maybe?
20:15:13 <markmc> jraim, how important is an agent to barbican?
20:15:38 <jraim> markmc: is was part of the original idea behind the project. Since then, we've looked at certmonger and some other options
20:15:50 <jraim> we might still create an agent if there are use cases for it
20:16:07 <markmc> ok, so no use cases requiring it right now?
20:16:08 <jraim> not sure if those are useful for openstack services or just consumers of an openstack cloud
20:16:25 <jraim> markmc: I have some use cases for apps that run on an openstack cloud
20:16:33 <jraim> and redhat has some based on certmonger for openstack services
20:16:50 <jraim> there are some needs there, but more thought required before we started working on anything
20:17:04 <jraim> redhat might move forward with certmonger integreation - we've talked about it
20:17:17 <markmc> so, cloud operators would need to get an agent from elsewhere for those use cases ?
20:17:40 <jraim> markmc: we could go either way. If we think it belongs in openstack, happy to do it here
20:17:55 <markmc> but where's the agent now?
20:18:02 <ttx> TC members: do you think we should wait for the minimal devstack-gate requirement to be fully implemented before considering this request ? Or can we provisionally accept ?
20:18:13 <jraim> but if it just an app that uses barbican that can work on any platform, maybe it doesn't go in openstack?
20:18:47 <jeblair> ttx: i think we should wait
20:18:58 <markmc> jraim, if features of barbican aren't functional to users of openstack clouds without the agent, then I think it's an important part of this new program
20:19:01 <annegentle> #link https://review.openstack.org/#/c/70512/
20:19:13 <annegentle> (That's the review for the devstack gate, right sdague?)
20:19:17 <jraim> markmc: I would agree.
20:19:20 <dhellmann> markmc: +1
20:19:24 <markmc> jraim, where's the code for the agent?
20:19:25 <ttx> markmc: the agent looks pretty optional to me ?
20:19:40 <markmc> ttx, that's what I was asking - sounds like it's required for some use cases
20:19:42 <sdague> annegentle: that's the devstack side
20:19:43 <jraim> ttx: right now, certainly since it doesn't exist :)
20:19:51 <markmc> jraim, ah!
20:19:58 <sdague> jraim: where's the d-g side of that?
20:19:58 <markmc> <markmc> ok, so no use cases requiring it right now?
20:20:01 <jeblair> i think the reason for that requirement was to either make sure it gets done, or determine major obstacles; i don't think that process is far enough along yet to say it's served either of those purposes.
20:20:05 <markmc> <jraim> markmc: I have some use cases for apps that run on an openstack cloud
20:20:10 <ttx> https://github.com/cloudkeep/postern#why-use-postern make it look like a client lib
20:20:11 <markmc> jraim, that's where the confusion came from :)
20:20:12 <jraim> markmc: we have some ideas about what an agent could enable, but nothing is done yet
20:20:26 <russellb> sdague: not implemented
20:20:32 <russellb> sdague: open question of whether we should block on it
20:20:40 <russellb> sdague: devstack support up for review, no job yet, AFAIK
20:20:51 <sdague> right, I think having the job is pretty important
20:21:00 <jraim> markmc: understood, sorry about that. I just meant we have some ideas of problems we could solve with it, nothing done yet
20:21:07 <sdague> because it demonstrates this can actually install and coexist with the rest of openstack
20:21:16 <russellb> i think we have the requirements for good reasons ... and should probably defer again
20:21:19 <ttx> OK, so it looks like we should delay voting until all requirements are filled
20:21:19 <russellb> and revisit once it's done
20:21:20 <mikal> russellb: I agree
20:21:25 <russellb> ttx: +1
20:21:26 <markmc> jraim, ok, so .. palisade :)
20:21:29 <annegentle> ttx: sounds good
20:21:36 <markmc> jraim, does that become an horizon integration effort?
20:21:49 <ttx> is there anything else the barbican folks need to cover before coming back to us ?
20:21:52 <jraim> russellb: sdague when I looked at the gating job, it seemed like being in devstack was enough if you weren't part of enabled services?
20:21:58 <jraim> markmc: that's my plan now
20:22:08 <russellb> jraim: you can have a job that just runs on barbican that spins up devstack with barbican enabled
20:22:12 <russellb> that's what we need here
20:22:18 <sdague> and that does something
20:22:27 <sdague> some minimal testing of any nature you like
20:22:28 <russellb> "hey API, are you alive?"
20:22:34 <sdague> right
20:22:34 <russellb> would probably be sufficient at this stage IMO
20:22:41 <ttx> #info Missing basic devstack-gate job
20:22:42 <jraim> russellb: so we've been doing that to test our impl, where would we add that job?
20:23:00 <russellb> let's chat details outside the meeting, happy to give pointers
20:23:01 <jeblair> jraim: there are a few examples of this; let us know in the #openstack-infra channel and we can point you at them
20:23:03 <jraim> we did a little of that in just devstack with our exercises, but I'm happy to add it
20:23:06 <jraim> russellb: great, thanks
20:23:15 <jraim> jeblair: will do
20:23:18 <russellb> basically you need 1) devstack, 2) devstack-gate, and 3) infra config
20:23:23 <russellb> changes in those 3 places
20:23:23 <ttx> ok, so we should defer the decision on this
20:23:40 <jeblair> russellb: (actually not devstack-gate for incubation)
20:23:42 <mikal> ttx: agreed
20:23:43 <ttx> jraim: I'll also help you draft the governance repo change that will serve as the base for the final decision
20:23:55 <jraim> ttx: great
20:23:56 <russellb> jeblair: i guess so, ENABLED_SERVICES is enough, you're right
20:23:57 <annegentle> I would like a single source of truth for API docs (not that I'm noticing disagreement, but just noting)
20:24:01 <ttx> jraim: ping me when the devstack-gate stuff is covered
20:24:09 <russellb> ok, devstack and infra config :)
20:24:18 <ttx> anything else on that topic ?
20:24:22 <jraim> annegentle: I think the goal is to migrate to docbook and remove everything else
20:24:38 <SergeyLukjanov> russellb, btw, is it ok to merge into devstack not yet incubated project?
20:24:52 <annegentle> jraim: sounds good
20:24:59 <markmc> jraim, minor thing, but it'd be good if statements like "The Postern agent is capable of presenting these secrets in various formats to ease integration." weren't in the present tense :)
20:25:09 <markmc> jraim, from https://wiki.openstack.org/wiki/Barbican/Incubation
20:25:17 <russellb> errr ... i guess you can do devstack support as plugins, not actually as a patch to devstack itself
20:25:24 <jraim> markmc: yeah, I'll go back and clean that stuff up. The only impl we ever had was a PoC that couldn't be run in prod
20:25:28 <russellb> that's how solum has it for example, and they have a devstack-gate job
20:25:34 <ttx> ok, moving on
20:25:34 <markmc> jraim, cool
20:25:37 <sdague> yeh, solum is actually a good example
20:25:38 <jeblair> SergeyLukjanov, russellb: yeah, i think that's the way devstack wants to go for pre-integrated projects
20:25:44 <russellb> makes sense
20:25:55 <ttx> #topic Defining "designated sections" for DefCore
20:26:04 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2014-February/026413.html
20:26:16 <ttx> In that thread I proposed that we approached this question in two steps
20:26:29 <ttx> First we would answer the objective question: "which parts of each project have a pluggable interface ?"
20:26:41 <ttx> Then, once we have that list, we could answer a second question: "where, in that list, is it acceptable to run an out of tree implementation ?"
20:26:42 <russellb> a public pluggable interface
20:26:50 <ttx> russellb: +1
20:26:56 <ttx> Anyone against this two-step approach ?
20:27:21 <sdague> nope, lgtm
20:27:21 <markmc> well
20:27:35 <markmc> I don't know that there was much agreement that this is going to ultimately be useful
20:27:37 <markmc> right?
20:27:40 <russellb> markmc: +1
20:27:43 <markmc> e.g. http://lists.openstack.org/pipermail/openstack-dev/2014-February/026559.html
20:27:47 <jgriffith> agree with markmc
20:27:56 <mikal> I think we need to discuss how we feel about vendor specific modifications to the unpluggable bits too
20:27:59 <jgriffith> also not entirely sure about that appraoch
20:28:00 <markmc> "The request from the DefCore committee around designated sections would replace Section 2(i) in the above example. The external API testing that is being developed would fulfill Section 3."
20:28:02 <dhellmann> what is "this"? designating at all, or using the plugin API?
20:28:05 <dhellmann> as the designation
20:28:19 <markmc> personally, the more I think about it - I'd rather us just be tackling the API testing part
20:28:31 <jgriffith> markmc: can you describe?
20:28:38 <jgriffith> markmc: just API compat and call it good?
20:28:50 <russellb> API compat and a general "you must use the code" statement?
20:28:52 <markmc> "include the entirety of the [..] code from either of the latest two releases and associated milestones, but no older"
20:28:59 <markmc> that seems fine to me for now
20:29:05 <dhellmann> include != "run"
20:29:05 <russellb> that's the current statement right?
20:29:12 <mikal> markmc: I'd prefer something along the lines of "include and run"
20:29:17 <markmc> no point blocking progress on API testing on the "run the code" part
20:29:33 <markmc> mikal, well, think of a distro - a distro can only include it
20:29:33 <russellb> true
20:29:34 <jgriffith> markmc: I'd be ok with that, and of course if the project accepts pluggable drivers use whatever you want as long as the API tests work
20:29:34 <annegentle> core or extensions too?
20:29:37 <annegentle> er, API core
20:29:47 <jgriffith> I'm finding many of the cinder drivers don't succeed here
20:29:56 <mikal> markmc: well, they run it by adding the relevant hooks (e.g. systemd start entries)
20:29:59 <russellb> i think all this detailed listing of components (and trying to keep that accurate for all of these rapidly evolving projects) sounds like a nightmare
20:30:10 <jgriffith> russellb: +1
20:30:10 <russellb> and feels like overkill
20:30:20 <jgriffith> russellb: and I'm not sure what/if it means
20:30:22 <markmc> mikal, our users run the code
20:30:34 <dhellmann> is the driving factor there some desire to have part of a project not be listed as core?
20:30:36 <lifeless> mikal: the deployed instances run it, distros only in testing.
20:30:40 <ttx> hmm, I think this is not our game, though. Defcore is where those rules are defined... and they ask us to designate code sections. If you think that's not the right approach, you can fight that approach at DefCore level
20:30:43 <russellb> markmc: i really liked your list comment about keeping what we say now, and go after anyone that the board doesn't feel is acting in good faith
20:30:44 <mikal> markmc: I don't want someone re-writing nova in Java, and then saying they've included the python code by dumping it in a dir and therefore can use the trademark
20:30:45 <lifeless> mikal: Ubuntu OpenStack for instance.
20:30:58 <ttx> i'm just trying to answer their technical question
20:30:58 <dhellmann> mikal: +1
20:31:03 <jgriffith> ttx: so why isn't the tempst gate tests our defcore test?
20:31:10 <markmc> mikal, sure - I just don't think that's what we need to be going after right now
20:31:17 <lifeless> so maybe we only certify /installs/ of OpenStack
20:31:22 <jgriffith> ttx: I mean, we define OpenStak by what we gate on
20:31:28 <russellb> ttx: well can we give feedback to our resident board members?  :)
20:31:34 <sdague> jgriffith: realistically, I expect the defcore folks are going to lift tests from tempest
20:31:35 <markmc> mikal, i.e. which is the best next baby step - firming up the "run the code" requirements or adding API testing requirements?
20:31:35 <lifeless> and folk that are intermediaries can say that their installer gets you a certifiable OpenStack ?
20:31:43 <dhellmann> lifeless: the distros will want to use the trademark too
20:31:43 <sdague> but lets take some concrete examples
20:31:54 <lifeless> dhellmann: yes, and I support that
20:31:58 <mikal> markmc: but is the board expecting this to be a baby step, or the final answer for several years?
20:32:00 <ttx> russellb: we can
20:32:01 <markmc> ttx, we can and should give our feedback
20:32:01 <jgriffith> sdague: I would hope so, but I'm saying is this all being made much more complicated than it should be?
20:32:20 <sdague> for instance, tempest full doesn't pass on any of the hypervisors besides kvm (some pass almost all, but not quite all)
20:32:30 <dhellmann> lifeless: me, too, but that means we need some way to certify the distros, no?
20:32:40 <sdague> and it passes only about 60% if you have cells enabled
20:32:40 <jgriffith> sdague: ahhh....  see where you're going
20:32:48 <lifeless> dhellmann: problem is that a distro is an installer basically
20:33:04 <markmc> mikal, our feedback could be "we'd prefer to focus our (the TC) energies right now on helping you with API testing - come back later on the other stuff"
20:33:06 <lifeless> dhellmann: and installers can install both meets-requirements and doesn't-meet-requirements clouds
20:33:09 <ttx> jgriffith: "we" don't define the trademark rules. The board does. We can voice our opinion, but that's about it
20:33:12 <lifeless> dhellmann: so
20:33:13 <sdague> so that makes me scratch my head a bunch about what is Nova, if we consider all those options
20:33:22 <jgriffith> sdague: so....  IMO you pair out what we gate on, thy Hypervisor things would have to be fixed if you want to run them and be "OpenStacK" cloud
20:33:36 <jgriffith> ttx: understood....
20:33:38 <ttx> Personally I'd rather have the TC stay away from trademark usage rules
20:33:39 <lifeless> dhellmann: I don't think we can say 'you get the trademark only if ALL THE INSTALLS you do meet the requirements'
20:33:48 <mikal> markmc: yes, but perhaps with a deadline? We ant to defer the other bit until the Juno release?
20:33:50 <ttx> which is why we separated integrated from core in the first place
20:33:53 <sdague> or decide for each project what is the actual API contract
20:33:53 <dhellmann> lifeless: I don't think that's what I was suggesting
20:33:54 <jgriffith> ttx: but defining "code components" is what I'm still trying to get my head wrapped around
20:33:54 <mikal> s/ant/want/
20:33:56 <lifeless> dhellmann: instead, I think it has to be 'you get the trademark if your default meets the requirements'
20:33:58 <russellb> ttx: hard to stay away when tech details get wrapped up into defining it
20:34:00 <lifeless> dhellmann: or something like that
20:34:03 <russellb> ttx: otherwise totally +1
20:34:13 <dhellmann> lifeless: +1
20:34:23 <sdague> I think we've gone pretty heavy on optional API, and need to reconsider that if we want interop
20:34:28 <ttx> russellb: right. We can basically issue a statement saying this is not very convenient, and propose an alternate approach
20:34:37 <dhellmann> sdague: +infinity
20:34:37 <markmc> ttx, yes, we want to stay away from trademark policy decisions - I agree
20:34:40 <russellb> ttx: fair
20:34:51 <ttx> russellb: but if they decide to ignore our statement, we'll have to give them the technical answers they are asking for
20:35:04 <russellb> boo
20:35:06 <ttx> because I think we are better placed to answer them than they are
20:35:06 <russellb> :-p
20:35:10 <lifeless> so didn't we try this with plugins vs modules etc
20:35:12 <russellb> yes, that's true.
20:35:19 <lifeless> and ended up with terrible verbiage
20:35:30 <markmc> we don't have to give the board answers :)
20:35:32 <ttx> markmc: so you think we should pause and first propose an alternate approach ?
20:35:37 <markmc> "this is a bad idea, we don't want to help" :)
20:35:46 <ttx> markmc: sure. they will designate the code themselves then
20:35:46 <russellb> markmc: that's kind of how i feel :(
20:35:57 <markmc> I'm pretty certain if the consensus amongst us that this is a bad idea or not the right time
20:36:05 <markmc> and that we should focus our efforts now on API testing
20:36:08 <jgriffith> markmc: or how about "I can't help if you can't explain what you're trying to solve"
20:36:13 <markmc> the board would take that on ... uh ... board
20:36:14 <jgriffith> markmc: because frankly I'm still unclear
20:36:19 <lifeless> jgriffith: +1
20:36:35 <dhellmann> markmc: *groan*
20:36:35 <sdague> markmc: honestly, I'm also concerned that the parties driving this are basically part of orgs that don't give anything back (or much back) to the community as well
20:36:36 <annegentle> crazy idea, why not make the definition the docs rather than the code?
20:36:48 <lifeless> It seems to me that things like 'dont get the trademark if you rewrite in java' are better directly measured, rather than through awkward indirect means
20:36:50 <ttx> markmc: at the very least we need to come up with an aswer detailing why we think it's a bad idea
20:36:50 * annegentle has to ask
20:36:58 <markmc> sdague, I'd prefer to assume good faith
20:37:06 <mikal> annegentle: this is mostly about interop of deployments though
20:37:08 <sdague> because, honestly would some of this energy in defcore going into actually helping on test implementation
20:37:25 <annegentle> mikal: but you know how many software companies ensure legal contracts are bound by docs?
20:37:30 <dhellmann> ttx: let's provide those details then
20:37:43 <mikal> annegentle: no
20:37:53 <ttx> do we have a volunteer to draft the TC response ("sounds like a bad idea") ?
20:37:55 <annegentle> mikal: so it seems like a write up away from code might be the better discussion ground than the code itself
20:38:04 <sdague> and I think the fact that the vend diagram of people that work on the test tool chain for OpenStack have 0 overlap with the people working to define DefCore is probably a big part of the disconnect
20:38:16 <lifeless> sdague: venn ?
20:38:19 <jgriffith> I suppose all of this falls  out if you say:  "Must use <project>/API code from release and pass API compat test
20:38:20 <sdague> lifeless: yes
20:38:21 <annegentle> mikal: often software companies state in the contract where they sell the product that the product can only do what the docs say
20:38:31 <mikal> ttx: I think a review in governance would be a good way to do that
20:38:33 <annegentle> (well, not sure if often is correct, that's rather vague)
20:38:44 <mikal> annegentle: oh, ok
20:38:45 <jgriffith> That enforces what's "required" non-pluggable
20:38:46 <ttx> mikal: sure. You still need to seed it with something
20:38:58 <ttx> mikal: looking for someone to lead that
20:39:00 <mikal> ttx: sure, I will draft something if no one else wants to
20:39:03 <annegentle> just wondering if the response is "code is too difficult to split in this way, let's try a document"
20:39:04 <dhellmann> annegentle: the problem with natural language docs for enforcement is they are open to interpretation -- a test suite is not
20:39:10 * russellb nominates markmc :-p
20:39:16 <annegentle> dhellmann: true that
20:39:24 <mikal> markmc is the other obvious candidate, but I can work with him on something
20:39:28 <lifeless> dhellmann: a test suite certainly is ... in that you can just fake the thing it talks too.
20:39:34 <markmc> mikal, sounds good
20:39:37 <lifeless> dhellmann: that is endemic in vendor interop efforts.
20:39:40 <jgriffith> lifeless: +100000
20:39:43 <russellb> mikal: markmc sounds great to me
20:39:45 <ttx> We basically need a DefCore delegate
20:39:50 <annegentle> lifeless: good to know
20:40:00 <sdague> lifeless: sure, but it's at least easier for well intentioned players to do the right thing
20:40:01 <markmc> ttx, that would be good - especially if it wasn't me or monty
20:40:03 <mikal> ttx: I said at the HK board meeting I was happy to help them, they've never asked me for anything
20:40:06 <sdague> gamers are going to always find a way around
20:40:10 <mikal> ttx: so I stand by that
20:40:18 <mikal> ttx: I can draft something with markmc's input for next week
20:40:23 <russellb> mikal: i support you in this endeavor.
20:40:26 <markmc> ttx, just sign up to the defcore-committee list, then
20:40:36 <lifeless> sdague: right, but if you look at e.g. http proxy bake offs, for decades now, every single commercial vendor targets the test suite specifically.
20:40:37 <markmc> ttx, meeting notifications go there ... mostly, I think
20:40:40 <markmc> sorry
20:40:46 <markmc> mikal, ^^ that's to you
20:40:46 <lifeless> sdague: we're going to see exacrly the same thing.
20:40:54 <ttx> mikal: would you be willing to follow DefCore work and act as a TC interface there ? We badly need someone
20:40:59 <markmc> mikal, I don't have any more insight into anything than what goes across that list
20:41:01 <mikal> markmc: this is the first I've heard there's a list. I will give it a try
20:41:05 <mikal> ttx: sure
20:41:09 <markmc> mikal, cool
20:41:12 <ttx> mikal: awesome
20:41:14 <markmc> mikal, http://lists.openstack.org/pipermail/defcore-committee/
20:41:16 <mikal> ttx: until we find someone better...
20:41:23 <ttx> mikal: thx for volunteering ;)
20:41:33 <annegentle> go go mikal
20:41:38 <sdague> lifeless: so what's your alternative?
20:41:41 <russellb> mikal: ^5  gogogo
20:41:54 <sdague> yeh, thanks mikal
20:42:06 <mikal> I may yet rage quit, but I'll give it a go
20:42:20 <ttx> because given my bandwidth, i'm inclined to provide them the answers they want just because I don't have time to follow or suggest better routes. (lame, I know)
20:42:21 <annegentle> mikal: I'll subscribe to the list too and can be your backup
20:42:26 <annegentle> ttx: if that's ok
20:42:33 <mikal> annegentle: thanks, I would love that
20:42:35 <lifeless> sdague: I'm just saying, we can't use the test suite as a proxy metric for other things; what it exercises *exactly* will be covered, other things - like corner cases - may well be all over the shop.
20:42:45 <ttx> as long as there is someone tracking that effort closely, I think we are good
20:42:49 <lifeless> sdague: and it won't prevent the 'rewrite the plumbing' scenario on its own
20:42:55 <dhellmann> mikal, annegentle: I've subscribed, too
20:43:00 <markmc> ttx, you think it's easier to get those answers?
20:43:14 <markmc> ttx, my assumption is we'll tie ourselves up in knots working out the answers?
20:43:23 <ttx> markmc: it's compatible with my bandwidth.
20:43:39 <markmc> ttx, ahm ok :)
20:43:48 <dhellmann> ttx: let's let mikal have a chance
20:43:50 <mikal> Ok, on the list
20:43:50 * russellb joined the list too
20:43:51 <ttx> markmc: having TC delegates follow defcore and propose alternative solutions is 100x better
20:43:54 * markmcclain joined too
20:43:56 <sdague> lifeless: it's better than not. At least those interfaces will be interoperable. Saying the problem is hard doesn't seem to me like a reason to throw in the towl
20:44:09 <lifeless> sdague: I wasn't suggesting throwing in the towel
20:44:21 <lifeless> sdague: I was answering '09:39 < dhellmann> annegentle: the problem with natural language docs for enforcement is they are open to interpretation -- a test suite is not
20:44:33 <zehicle_at_dell> ttx, I'm happy to have them join!
20:44:35 <ttx> I know mikal feels strongly about this so I trust him to follow that closely :)
20:44:35 <lifeless> sdague: which I read as a suggestion to use a test suite instead of english.
20:44:49 <lifeless> sdague: which is iMO a mistake - its not either-or, its both.
20:44:54 <russellb> if tenant == testing: do_the_thing_it_expects() else: do_the_thing_we_want()
20:45:00 <russellb> tests not foolproof solution either :)
20:45:02 <lifeless> russellb: exactly :(
20:45:04 <lifeless> russellb: thats my point
20:45:09 <russellb> but a good step forward
20:45:15 <mikal> lifeless: do you have an alternate solution though?
20:45:17 <ttx> zehicle: I think having clear TC delegates will help solving the communication issues we had in the past
20:45:20 <sdague> sure, I'm not saying they are. I'm saying they are a good first step
20:45:23 <zehicle_at_dell> please let us know who is going to join, yes
20:45:24 <lifeless> mikal: the test suite is a good thing to have.
20:45:32 <sdague> and it moves everything in the right direction
20:45:33 <jeblair> russellb: right so the thing is that we would not merge code that does that
20:45:33 <lifeless> mikal: prose saying what we mean is a good thing to have.
20:45:34 <annegentle> and for docs I was not really thinking of narrative but of reference docs like API docs, config reference, etc.
20:45:39 <lifeless> mikal: I think we should have both.
20:45:48 <russellb> jeblair: not upstream, but downstream there could be ... i'm being extreme
20:45:51 <annegentle> to try to get closer to "truth"
20:45:58 <jeblair> russellb: which is why i think that the "you must run openstack" is the stronger part of this
20:46:15 <lifeless> jeblair: +1 exactly
20:46:15 <mikal> zehicle_at_dell: I'm going to draft a quick email explaining our plan to that list after this meeting
20:46:19 <ttx> #agreed mikal will act as TC interface to follow the DefCore effort and channel TC views. with annegentle as substitute
20:46:26 <russellb> saying you must run it, sure, defining it in a lot of detail sounds like a rat hole i'm not sure we'll get out of
20:46:32 <zehicle_at_dell> thanks
20:46:34 * ttx feels better about this
20:47:02 <ttx> more on this, or can we jump on the next topic ?
20:47:28 <ttx> or is that jump to ?
20:47:29 <sdague> vote jump
20:47:31 <annegentle> ttx: jump!
20:47:36 * russellb jumps
20:47:37 <ttx> #topic Integrated projects and new requirements: Nova
20:47:44 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2014-February/026450.html
20:47:51 <russellb> oh
20:47:59 <ttx> russellb: you jumped
20:48:03 <jeblair> russellb: jump back
20:48:03 <ttx> As we raise requirements for new incubating projects, it was suggested that we should review existing integrated projects to make sure there was a plan to cover any gap
20:48:04 * dhellmann wonders if russellb has jumper's remorse
20:48:10 * russellb jumps back quickly
20:48:18 <ttx> I suggested we started the process with projects where the PTL is also a TC member: Nova, Cinder, Neutron
20:48:26 <ttx> russellb: did you prepare an answer for Nova yet ?
20:48:26 <russellb> so, nova meetup this week means i haven't had a chance to write up an analysis of Nova vs requirements
20:48:29 <russellb> i did not :(
20:48:30 <ttx> haha
20:48:50 <ttx> no biggie, I have another topic up my sleeve
20:49:02 <russellb> ok, yeah, let's start that next week
20:49:05 <russellb> unless another project is ready
20:49:06 <russellb> (sorry)
20:49:10 <ttx> jgriffith, markmcclain: you shall be next, so plan to prepare that in the coming weeks
20:49:34 <ttx> #topic Minor governance changes
20:49:40 * markmcclain can't wait to write the duplicated functionality paragraph
20:49:51 <ttx> markmc: I know, right
20:49:52 <ttx> * Add some REST API graduation requirements (https://review.openstack.org/#/c/68258/)
20:50:04 <ttx> that was markmcclain, not markmc
20:50:22 <ttx> So.. on that one... Had a question there about requiring API stability at graduartion time vs. art release time
20:50:22 <markmc> ttx, I'll mark as WIP - I think these should be "after graduation, before first release" as you say
20:50:33 <markmc> ttx, which would be a new section
20:50:39 <ttx> markmc: looks like we need one yes
20:50:59 <annegentle> ttx: and I wondered about "stability for which version of the API" and timing of that stability
20:50:59 <ttx> BUT note that we don't review stuff between graduation and release. That happens automatically
20:51:09 <russellb> hard to enforce that, but at least good for setting clear expectations
20:51:29 <ttx> i.e. once we said "you will be in the next release", it would take a pretty bad event to make us not follow up on that
20:51:38 <NobodyCam> would this be a good time to a graduation question?
20:51:41 <ttx> because we communicate a lot around that
20:51:50 <ttx> NobodyCam: wait for open discussion
20:51:51 <markmc> ttx, yeah
20:51:53 <NobodyCam> :)
20:51:59 <ttx> and we invest a lot around that
20:51:59 <markmc> ttx, I guess at graduation, we're just looking for a commitment
20:52:14 <ttx> markthere is still value in detailing the post-graduation tasks
20:52:19 <lifeless> I think we need to separate out 'stable' vs 'finished' - nova is on v3 for instance
20:52:22 <lifeless> things evolve
20:52:27 <dhellmann> markmc: is there any reason not to hold graduation until a 1.0 API is complete?
20:52:35 <ttx> damn my markcompletion powers are broken today
20:52:43 <markmc> dhellmann, just that we've not done it before
20:53:11 <dhellmann> we've not had most of these guidelines before, right?
20:53:16 <ttx> markmc: example post-grad tasks would be: get into horizon proper
20:53:25 <markmc> ttx, yeah
20:53:38 <ttx> markmc: so feel free to add them to the doc
20:53:45 <sdague> markmc: have we had a project release without a 1.0 API in the past?
20:53:46 <markmc> dhellmann, I think we're mostly just documenting existing expectations and firming up them a little
20:53:57 <ttx> dhellmann: rigth, but I think we commit to supporting the API at release time, not really before
20:53:59 <markmc> dhellmann, stable API would be quite new
20:54:05 <markmc> ttx, add them back you mean
20:54:11 <dhellmann> ok
20:54:17 <markmc> sdague, we're talking about graduation, not release
20:54:44 <sdague> oh, right
20:54:48 <ttx> dhellmann: in particular, if integration with other projects creates a need, that should be adressable in the initial API version, not a second one
20:54:59 <dhellmann> ttx: good point
20:55:08 <russellb> mikal asked a good question on the review
20:55:13 <ttx> dhellmann: what we want for graduation is a pretty-compete APi. Not a stable one
20:55:16 <mikal> Yes, I am smart
20:55:18 <russellb> what if we have a project that we want to be integrated, but doesn't need a REST API
20:55:20 <ttx> complete*
20:55:28 <mikal> russellb: or an API at all
20:55:31 <russellb> deal with that as an exception if/when it comes up?
20:55:34 <ttx> russellb: could you make up an example ?
20:55:44 <russellb> gantt in theory ... we may want to use rpc only for that
20:55:46 <ttx> russellb: yeah, exceptions ftw
20:55:54 <russellb> exceptions is a reasonable answer for me
20:56:02 <markmc> well, I think we've always said that incubation is for "server projects"
20:56:04 <ttx> those rules are moving grounds anyway
20:56:08 <markmc> which imply API
20:56:09 <mikal> Or we could just word this differently
20:56:15 <mikal> "If the project exposes an API..."
20:56:19 <markmc> and an inter-project RPC API would be a new thing
20:56:27 <markmc> think we'd want the TC to vet that
20:56:27 <russellb> yeah, *punt*
20:56:33 <russellb> deal with it if/when it comes
20:56:39 <russellb> gantt nowhere near anything we need to review here
20:56:51 <ttx> All the other governance changes, i'll approve when they reach enough approvals:
20:56:55 <ttx> * Add a requirement for deprecating duplicated code (https://review.openstack.org/#/c/70389/)
20:56:59 <ttx> * Add missed mission statement for Data Processing (https://review.openstack.org/#/c/71045/)
20:57:02 <ttx> * add identity mission statement (https://review.openstack.org/#/c/71271/)
20:57:06 <ttx> * Oslo program changes (https://review.openstack.org/#/c/72335/)
20:57:27 <ttx> Unless someone has a comment about those, we can move to open discussion ?
20:57:41 <SergeyLukjanov> ttx, "mission statement for Data Processing" needs one more iteration on my side
20:57:58 <ttx> SergeyLukjanov: sure, but I don't think it needs to be re-discussed at a TC meeting
20:58:14 <SergeyLukjanov> ttx, yup, just wording
20:58:15 <ttx> so we can go on and approve it once it reaches the approvals on the review
20:58:20 <ttx> #topic Open discussion
20:58:24 <ttx> We're still missing a number of mission statements
20:58:30 <ttx> (object store, image service, dashboard, networking, block storage, telemetry, orchestration, infrastructure)
20:58:32 <markmc> NobodyCam, ^^^
20:58:37 <ttx> Would be good if the TC members could lead by example here, before we start chasing the individual PTLs
20:58:37 <NobodyCam> quickly: graduation question: are items like the nova driver (which are mainly out of our control) and migration scripts required to land for projects like Ironic to graduate?
20:58:45 <ttx> So jeblair, markmcclain, jgriffith: would be great if you could propose a mission statement addition to the governance repo
20:58:56 <russellb> NobodyCam: yes
20:59:04 <russellb> NobodyCam: there is a governance change up for review that covers this
20:59:04 <mikal> NobodyCam: I frel like the nova driver would meet the "deprecated code removal" test
20:59:07 <markmcclain> ttx: ack
20:59:09 <mikal> s/frel/feel/
20:59:10 <russellb> NobodyCam: https://review.openstack.org/#/c/70389/
20:59:17 <russellb> very much applies to the ironic case
20:59:22 <jeblair> ttx: will do
20:59:23 <markmc> russellb, might be good to clarify your exact expectations e.g. around dates
20:59:28 <markmc> russellb, it's getting tight
20:59:30 <NobodyCam> ack :)
20:59:37 <ttx> markmcclain, jeblair: cool, thx
20:59:41 <jeblair> ttx: i believe the wiki has the statement that the tc approved, i will push that.
20:59:43 <russellb> well ... before we do graduation review?
20:59:49 <mikal> What happens in the ironic case if they fall out of the hypervisor support matrix and get deprecated?
20:59:49 <ttx> jeblair: ack
20:59:49 <annegentle> ttx: how much of a requirement is it for a project considering incubation to have a program decided upon? Is that a hard requirement for a review?
20:59:56 <mikal> Does that imply unintegrating ironic?
21:00:08 <NobodyCam> Thank you
21:00:09 <mikal> Cause that ties the nova team's hands on driver quality...
21:00:20 <markmc> russellb, more about freeze date for the driver, what you need to deprecate the old baremetal stuff in this release
21:00:24 <ttx> annegentle: an incubated project needs to be covered by a program yes, it's one of the requirements
21:00:38 <ttx> annegentle: if none existing, would create a new one
21:00:41 <jeblair> mikal: i don't believe ironic is integrated; it is in incubation.
21:00:41 <markmc> russellb, perhaps it's obvious, but no harm in spelling it out - I think there's confusion
21:00:42 <annegentle> ttx: but if they are not sure which to apply under, can that be part of the discussion?
21:00:48 <annegentle> ttx: ok that's helpful too
21:00:50 <mikal> jeblair: usre, this is a future thing
21:01:01 <russellb> markmc: i guess i've largely been relying on the ironic folks on this
21:01:04 <ttx> annegentle: we just make the team official, basically.
21:01:08 <annegentle> ttx: just wasn't sure if it's a push or pull (programs recruiting vs. projects looking for a home)
21:01:12 <ttx> ok, no time left
21:01:15 <lifeless> both ?
21:01:17 <mikal> Thanks peoples
21:01:23 <ttx> #endmeeting