20:01:19 <ttx> #startmeeting tc
20:01:20 <openstack> Meeting started Tue Dec 15 20:01:19 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:24 <openstack> The meeting name has been set to 'tc'
20:01:26 <ttx> Hi everyone!
20:01:33 * flaper87 bows
20:01:38 <ttx> Been away traveling all day, just catching up, so please bear with me if I'm not very up to date on todays reviews
20:01:44 <ttx> Our agenda for today:
20:01:59 <annegentle> ttx: well, welcome back!
20:02:10 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:02:16 <ttx> #topic Resolution about Image Uploads and Linux Kernels
20:02:23 <ttx> #link https://review.openstack.org/#/c/256438/
20:02:40 <ttx> Looks like the proposal, whic hwas mostly consensual last week, met some resistance today
20:03:12 <ttx> and/or could be split in several steps
20:03:12 <flaper87> it's gotten comments from folks that weren't in the meeting last week
20:03:22 <flaper87> I guess it's mostly around the wording not the resolution itself
20:03:38 <ttx> flaper87: well...
20:03:58 <ttx> jaypipes disagrees with the image upload capability, which is pretty central to mordred's proposal
20:04:19 <flaper87> oh, mmh, I haven't read jay's comment
20:04:26 <flaper87> damnit, one can never be up-to-date
20:04:29 <ttx> I understand what jay means
20:04:38 * annegentle reads too
20:04:43 <jeblair> yes, without being able to hang the proposal on image uploads we're back to specifying what kind of POSIX-like thing is there for tempest to use.  i think that's a mess.
20:04:59 <ttx> *but* I think it's fine as a requirement to call your cloud a nopenstack cloud to require image upload, frankly
20:05:04 <ttx> it's an interoperability question
20:05:06 <annegentle> Yeah I think the confusion I had around import/upload was better stated by jay as public/private and security/performance stuff
20:05:30 <jeblair> ttx: i think "nopenstack" is what you call it if you _don't_ allow uploads, but yeah. ;)
20:05:45 <ttx> If some private clouds want to not allow image uploads, so be it, they are just not "openstack clouds, they are a private cloud built with openstack
20:05:49 <edleafe> lol 'nopenstack'
20:05:49 <flaper87> jeblair: ++
20:05:53 <dtroyer> ttx++
20:06:10 <sdague> ttx, right exactly, they are not openstack
20:06:20 <mordred> clouds without image upload are useless
20:06:21 <mestery> I think this nopenstack thing could have legs ... :)
20:06:21 <sdague> people can build anything they want with the openstack code
20:06:25 <mestery> But yes, what ttx said makes sense
20:06:27 <ttx> which is quite ok, for an openstack private cloud
20:06:31 <flaper87> I'm happy to split this resolution so we can have dedicated discussions on some of these topics but, I'm of the idea an openstack cloud MUST allow for images to be uploaded
20:06:38 <mordred> I'm not
20:06:38 <sdague> ttx: you need to stop using that word openstack
20:06:39 <mordred> this is key
20:06:45 <mordred> and all of the current clouds allow this
20:06:48 <sdague> it is ok, for foo private cloud
20:06:53 <mordred> the "no image uploads" is a theory
20:06:56 <mordred> that is upheld by nobody
20:07:00 <sdague> it is not ok for openstack private cloud
20:07:02 <ttx> sdague: I don't think it means what you think it means ?
20:07:05 <annegentle> where is jay?
20:07:16 <flaper87> mordred: ++
20:07:21 * ttx can't resist Princess Bride references
20:07:22 <cdent> annegentle: he's probably on a plane back from the ukraine
20:07:23 <jeblair> mordred: are you sure your thing about bare-metal is right?  do you really mean to say every openstack cloud must provide both vms and bare metal resources running on user-uploaded images?
20:07:35 <angdraug> afaik Jay is in Europe this week, so probably asleep :(
20:07:39 <jroll> jeblair: VMs *or* bare metal
20:07:41 <fungi> it seems like this still leaves things open for defining that openstack compute clouds must do virtualization (allowing at least some specific platforms to be virtualized) and use uploaded images, while other board-defined trademarks could cover things like openstack container clouds
20:07:55 <flaper87> jeblair: IIRC, it's an or
20:07:56 <mordred> jeblair: no, I do not mean that
20:08:01 <fungi> er, yeah so virtualization or run directly on the hardware
20:08:01 <mordred> jeblair: what I mean is that your cloud must allow the abiliyt to boot a user supplied kernel, and it can do that on vms or bare metal
20:08:07 <jroll> jeblair: mordred: the bare metal thing is interesting, bare metal can't necessarily run arbitrary images
20:08:17 <jroll> linux, yes, arbitrary no
20:08:20 <mordred> it can
20:08:31 <jeblair> jroll, mordred: right; i think i understand the intent is that ether one is sufficient, i'm not sure that's an unambiguous reading of it though.  ;)
20:08:33 <mordred> it TOTALLY can
20:08:36 <dougwig> mordred: jaypipes sent you a reply on the ML: "Monty, just because I'm not there to argue with you in person doesn't mean you shouldn't channel your inner leakypipes and argue with yourself on the IRC channel."
20:08:44 <dtroyer> presumably a user who knows he is using baremtal knows _how_ to use it
20:08:48 <mordred> jeblair: k. we should fix tht
20:08:48 <ttx> For example, I don't think any distro would cripple their "openstack cloud distribution" by not allowing image uploads by users at all
20:08:50 <mordred> dougwig: hahaha
20:08:54 <annegentle> snort
20:09:00 <mordred> ttx: ++
20:09:01 <jroll> mordred: I missed "given matching processor architecture", ignore me
20:09:05 <ttx> You can disable that ability in a specific deployment, but you shouldn't expect that to be interoperable.
20:09:10 <mordred> jroll: yay!
20:09:15 <sdague> jroll: right, you have to vaguely know how to build an image
20:09:20 <ttx> which is all that defcore is about
20:09:24 <sdague> like it not being just a lolcats jpeg
20:09:24 <mordred> ttx: +100 - exactly
20:09:36 <mordred> I think we can all come up with corner cases where a person can try a thing and that thing can not work
20:09:38 <lifeless> o/ sorry I'm late
20:09:40 <jroll> yep, that's fair
20:09:49 <annegentle> so, do we believe the only interop is in virt?
20:09:54 <lifeless> child had an accident yesterday, had to do forms @ preschool
20:09:55 <mordred> but I think thathe general idea that a user who is reasonably competent must not be prevented from running a working image that they have built
20:09:56 <mordred> is key
20:10:05 <ttx> We are not removing the ability to restrict image upload. We are just saying that the interoperable set is the one that allows you to bring your own kernel
20:10:13 <annegentle> lifeless: hope it's "all's well that ends well"
20:10:18 <flaper87> ttx: yes!
20:10:26 <ttx> because otherwise it just can't be interoperable.
20:10:32 <lifeless> annegentle: yeah, couple of scratches on eye lens, will heal fine in all probability
20:10:38 <annegentle> owww
20:11:02 <sdague> ttx: right, because we need to think of this from the OpenStack application writer perspective
20:11:08 <ttx> and I'll +2 the proposal as is for this reason.
20:11:11 <mordred> annegentle: I do not personally believe there is any resaon to restrict to vms and not include bare metal
20:11:14 <mordred> as I belive OpenStack is in the business of giving me machines, be they physical or virtual
20:11:21 <flaper87> also, to that, we can add all the discussions we've had in the last 3 (or 4) months with defcore, glance, API-WG to improve image upload to allow for clouds to use it publicly
20:11:21 <annegentle> sdague: but the app writers already sidestep virt
20:11:30 <flaper87> well, that despite the fact that most clouds do already
20:11:53 <sdague> annegentle: sorry, in what context?
20:11:57 <anteaya> lifeless: done that myself 3 times, all healed fine
20:11:58 <annegentle> sdague: containers
20:12:05 <mordred> annegentle: many app writers sidestep virt
20:12:08 <mordred> annegentle: but not all
20:12:20 <sdague> annegentle: so you are saying all openstack applications are containers?
20:12:24 <mordred> there are a specific class of app writers who NEED openstack and CANNOT use containers
20:12:33 <annegentle> sdague: I mean, I've had to re-re-read any virt v containers discussions to understand
20:12:43 <mordred> the specific thing those writers share is the need to have some amount of control over the kernel of the OIS they are running
20:12:53 <annegentle> whether containers "are" virtualization or not. They're not.
20:13:14 <sdague> annegentle: ok, I feel like this went a little orthoginal
20:13:15 <jeblair> also people who are writing an openstack "app" that is a container deployment technology *need* virt.
20:13:16 <annegentle> mordred: and I absolutely want to have a "user first" hat on like you
20:13:28 <mordred> full virt and bare metal are not needed by many people writing 12 factor apps - and that's fine
20:13:31 <mordred> but we are not and never have been a good home for those people
20:13:32 <annegentle> sdague: ok, fair 'nough
20:13:45 <mordred> we ARE an awesome place for people to run kubernetes controle planes
20:13:46 <sdague> because I feel like the point is what are the guaruntees we give applications folks, so they don't have to special case every cloud
20:14:01 <sdague> and if they are writing to the nova / glance API
20:14:11 <mordred> and to run docker swarm control planes
20:14:15 <sdague> there is no interface to deploy a container there
20:14:38 <mordred> yah
20:14:40 <annegentle> sdague: right, so app devs can sidestep those APIs
20:14:44 <mordred> yes
20:14:53 <annegentle> mordred: and yes, that's all cool
20:15:06 <sdague> annegentle: right, and we are trying to give them guaruntees so they don't all have to ignore all our APIs all the time :)
20:15:07 <ttx> OK, so does anyone besides Jay have objections to the current proposal ?
20:15:10 <annegentle> mordred: hence my ask you don't bury the lede :)
20:15:14 <mordred> anyd many do - and that's fine for them
20:15:16 <lifeless> so
20:15:29 <lifeless> I think we need to separate product capabilities vs configured options
20:15:53 <lifeless> a *product* called an 'openstack cloud' - be it public, or an installer-style-thing, must IMO allow image uploads
20:16:00 <ttx> lifeless: the question defcore asked was about deployed capabilities
20:16:20 <mordred> lifeless: ++
20:16:22 <lifeless> a private cloud based on that product being able to limit who can upload images - fine IMO
20:16:40 <sdague> ttx: I'm fine with what's up there
20:16:44 <mordred> yup
20:16:46 <fungi> yeah, i think the point that a lot of users have "worked around" openstack's lack of consistent interoperability by adding their own normalization layer (at their own expense) isn't really an argument for giving up making that less necessary
20:16:53 <lifeless> jay's point seems to target not un-certifying private clouds, which makes sense to me
20:17:10 <sdague> fungi: ++
20:17:11 <cdent> there's a huge legal gap between (product capability and trademark definition) and (deployed stuff)
20:17:14 <flaper87> I don't have objections with what's up for review, tbh.
20:17:16 <ttx> lifeless: but it can't be called "an openstack cloud", it may be called "a cloud deployed from an openstack distribution", I guess
20:17:27 <sdague> or it can be called a cloud
20:17:31 <mestery> I don't have objections with what's there either
20:17:33 <lifeless> ttx: we don't certify private clouds today, we certify the product used to install them
20:17:33 <sdague> without the word openstack near it
20:17:40 <lifeless> ttx: AIUI it anyhow
20:17:42 <ttx> lifeless: then all is fine
20:18:00 <ttx> (if your understanding is correct)
20:18:17 <sdague> but if we want an ecosystem of off the shelf software (open or commercial) that interacts with OpenStack clouds
20:18:30 <sdague> we need to set that SDK expectation correctly, otherwise it's all tears
20:18:31 <lifeless> sdague: then those products need to be given appropriate acls on the cloud
20:18:35 <ttx> maybe mordred could sparkle some magic dust on the proposal to make it less worrisome for private cloud vendors
20:18:53 <mordred> so - I can try doing that
20:18:57 <lifeless> sdague: thats no different to needing a certain size quota, or particular image flavours
20:19:00 <lifeless> sdague: is it?
20:19:01 <sdague> ttx: why is it worrysome?
20:19:02 <mordred> but I'm not sure that anything in here talks about that at all
20:19:02 <ttx> while keeping the guts of it, which is interoperability of things we call "openstack clouds"
20:19:08 <mordred> right
20:19:15 <dougwig> if it's a private cloud, will anyone know it's being called an openstack cloud?  tree in a forest and all.  it's private.  :)
20:19:17 <mordred> this is talking about clouds
20:19:31 <mordred> not about cloud constructoin kits
20:19:38 <mordred> if someone wants to claim that a running cloud is an OpenStack cloud, it needs to meet criteria
20:19:42 <mordred> or else it's not behaving well
20:19:45 <fungi> make it more clear, i guess, that the proposal is specific to public clouds and openstack software distributions seeking interoperability certification
20:19:48 <sdague> dougwig: it will be the first time someone in IT gets Veritas for OpenStack
20:19:52 <sdague> tries to plug it in
20:20:04 <ttx> sdague: I think /some/ private cloud vendors are worried that they won't be able to use the openstack trademark because their product is used to deploy clouds that do not allow user image uploads
20:20:04 <sdague> and Foobar cloud they were sold doesn't have any of the interfaces for it
20:20:14 <mordred> ttx: which ones?
20:20:14 <dougwig> sdague: oh, you just gave me flashbacks and nightmares in one word.
20:20:17 <mordred> ttx: like, who is doing that?
20:20:28 <ttx> mordred: jay's employer, maybe
20:20:31 <mordred> ttx: because I'm getting tired of theoretical people with theoretical problems
20:20:45 <mordred> ttx: I believe fuel installs clouds that can upload images
20:20:51 <lifeless> sdague: so yes, that matters - but as long as the product the company bought /can/ do it, is it an issue?
20:21:00 <ttx> sure, and I think the concern is not warranted
20:21:06 <edleafe> ttx: if their product doesn't allow it at all, then it's not openstack. If it allows uploads to be turned off, well, that's the deployer's choice
20:21:11 <fungi> as long as their distribution allows you to build a cloud that allows image uploads, the fact that it also allows you to build ones which don't shouldn't be cause for concern
20:21:14 <ttx> edleafe: ++
20:21:15 <mordred> edleafe: ++
20:21:22 <flaper87> mordred: ++ on the theoritical people with theoretical problems issue
20:21:27 <lifeless> edleafe: except when its a public cloud... ?
20:21:37 <mordred> lifeless: when it's a public cloud it MUST allow image uploads
20:21:38 <ttx> maybe adding a short sentence that says what edleafe just said would alleviate their concern
20:21:55 <mordred> because then the user of the public cloud is not a private user who had a relationship with the deployment choices, nor should they be
20:22:03 <ttx> but then , again, I'm fine with approving this as-is, I think it's clear enough
20:22:16 <sdague> sure, though it does seem like in such an environment there should be a checkbox of "ensure compatibility with OpenStack"
20:22:20 <mordred> ttx: I'm fine adding one - or doing a follow up that says such a thing
20:22:31 <edleafe> lifeless: if a public cloud turns off uploads, then they are not openstack.
20:22:34 <ttx> My understanding being that all the other TC members are fine with it
20:22:52 <mordred> sdague: yah - because we're talking hopefully people who _want_ to verify that peope who write things "for openstack" can run those things on their cloud
20:23:05 <mordred> sdague: so those people would not be able to assert such a thing if the cloud in question did not allow image uploads
20:23:10 <annegentle> sdague: yeah and that'll enable that ecosystem too
20:23:19 <flaper87> tbh, the discussion is getting confusing at this point. Let's just say that clouds that want to me stamped as OpenStack must allow image uploads, regarless they are public or private. We don't need to care about the mechanics of how/why/when a private cloud would require such certification/stamp
20:23:32 <mordred> flaper87: +100
20:23:37 <sdague> yep
20:23:49 <mordred> you can ALWAYS use the software to do any number of other crazy things
20:23:57 <ttx> mordred: without Jay around, i don't think we can make a lot more progress continuing the discussion in-meeting. I propose we move to the review -- I'll approve it whenever it passes the majority vote
20:23:58 <flaper87> right
20:23:58 <mordred> I mean, the combinations are limitless
20:24:00 <lifeless> edleafe: right. *we* are agreed. But we're writing prose folk will try to lawyer-at-us.
20:24:11 <lifeless> edleafe: so I'd like there to be no things that can be taken out of context.
20:24:15 <ttx> and I propose we move on
20:24:19 <edleafe> flaper87: agreed. You can add the ability to turn it off, but it has to be an *option*.
20:24:20 <sdague> ttx: ++
20:24:21 <mordred> wfm
20:24:26 <ttx> unless someone wants to discuss another very specific point
20:24:27 <flaper87> I'm happy to comment on the review and reply to Jay's comments with the summary or even my own
20:24:30 <mordred> the review conversation has been very useful so far
20:24:34 <flaper87> edleafe: right
20:24:41 <lifeless> I'll be replying on the review after the meeting
20:24:43 <ttx> a bit late, but then that was posted late too
20:24:49 <mordred> I also haven't read jay's comments yet - so I'll poke those too
20:24:54 <ttx> OK, moving on
20:24:59 <ttx> #topic Spin off stable team as separate team
20:25:03 <annegentle> thanks mordred
20:25:06 <ttx> #link https://review.openstack.org/255159
20:25:13 <ttx> So this is the final stage of spinning-out the stable maintenance team into its own project team
20:25:22 <ttx> We had elections over the last weeks and the team has an initial PTL, mriedem
20:25:40 <ttx> I'll approve this now, since it has more than enough votes
20:25:43 <flaper87> mriedem congrats, wherever you are
20:26:07 <ttx> #topic Redefine Release Management team mission
20:26:14 <ttx> #link https://review.openstack.org/255379
20:26:26 <ttx> So... back in the day the "Release Cycle Management" team was a frankenteam of things I happened to lead
20:26:33 <ttx> i.e. release management, stable branch maintenance and vulnerability management
20:26:41 <ttx> Now that the last two are separated (one under Security, the other under its own team) it's time to reword the mission
20:26:54 <ttx> still short of a couple of votes
20:27:20 <ttx> alright, we are in
20:27:50 <ttx> FWIW I'll follow the team at least during the mitaka cycle to see it's off wit ha good start
20:28:13 <ttx> #topic Rewording Freezer mission
20:28:23 <ttx> #link https://review.openstack.org/254239
20:28:30 <ttx> Non-trivial team mission changes need to be formally approved by the TC
20:28:38 <ttx> This one sounds pretty simple
20:28:49 <ttx> mostly shortening it, not changing it
20:28:57 <annegentle> ttx: I could just revise their patch, think they'll mind?
20:29:17 <flaper87> annegentle: I don't think Fausto would mind if yo udo
20:29:28 <flaper87> I think he's a bit on/off these days
20:29:29 <dtroyer> annegentle: I'd appreciate an edit pass over my suggestion ;)
20:29:42 <ttx> annegentle: go for it
20:29:46 <annegentle> dtroyer: yep! Ok, on it
20:30:11 <ttx> the TC puts its famous iron fist on the table and overwrite the PTL proposed change
20:30:23 <ttx> +s
20:30:25 <annegentle> dtroyer: I'll also start it with To verb
20:30:43 <ttx> let's come back to that once Anne is done
20:30:51 <ttx> #topic Cross-project spec rubberstamp: Chronicles of a DLM
20:31:01 <ttx> thingee: you there ?
20:31:17 <ttx> #link https://review.openstack.org/#/c/209661/
20:31:17 <thingee> ttx: hi
20:31:25 <ttx> thingee: care to quickly introduce this one ?
20:31:46 <thingee> sure
20:31:48 <ttx> looks pretty consensual to me
20:32:09 <ttx> missing a few +2s before we can rubberstamp it
20:32:11 <thingee> at the summit we came to consensus we wanted to use tooz but have a refernece implementation for gate testing
20:32:41 <thingee> since then devstack supports bring up zookeeper as a first pass on a ref implementation
20:32:55 <ttx> (annegentle: let me know when done)
20:32:58 <thingee> there are also other drivers coming into tooz for distributed lock management
20:33:00 <thingee> etcd https://review.openstack.org/#/c/246879/
20:33:04 <annegentle> done diggity ttx
20:33:08 <thingee> consul https://review.openstack.org/#/c/245362/
20:33:11 <ttx> yay ^
20:33:16 <thingee> I think the future looks bright
20:33:34 <flaper87> w0000h00000! Gotta love the options
20:33:48 <thingee> we are following a similar model to MQ's where there has to be two maintainers I believe behind a driver.
20:33:54 <mordred> thingee: we're still planning on deprecating the less featureful toox drivers, yeah?
20:33:57 <mordred> thingee: ++
20:34:10 <sdague> flaper87: I have to say, I mostly hate options here
20:34:12 <flaper87> (like redis)
20:34:16 <mordred> thingee: like, the ones that 'work' but don't actually work
20:34:18 <mordred> like redis
20:34:35 <lifeless> mordred: call me maybe....
20:34:44 <sdague> because it just means segmenting our operator community into islands of knowledge that can't help each other
20:34:45 <mordred> sdague: I also hate the options, but I think the current set of curated options are not the worst thing that has ever happened to us
20:34:47 <flaper87> sdague: it depends. If we're talking about the whole DLM discussion, then yes. I love the fact that tooz now has support for other consensus services
20:34:51 <thingee> mordred: that's a good question. I need to follow up with julien on that
20:34:53 <ttx> sdague: I like having one non-Java option. I agree that options are not necessarily a good thing
20:35:00 <mordred> sdague: they seemed segmented already
20:35:19 <lifeless> sdague: if the operator community were willing to converge, we could do so really very easily
20:35:22 <thingee> sdague: I also agree, unfortunately majority wanted options. I think the ref implementation is going to be what kvm is today in openstack nova
20:35:24 <mordred> there was at least one vocal never-consul  and one vocal never-zk
20:35:28 <ttx> I would have settled with two (the best option and the non-Java option)
20:35:30 <mordred> ttx: ++
20:35:33 <annegentle> sdague: oo good point, but it's a natural progression
20:35:58 <thingee> sdague: also we had good operator presence and this is what they wanted.
20:36:05 <annegentle> more hammers, more nails, more finesse as we go
20:36:05 <thingee> options
20:36:05 <sdague> thingee: so be it
20:36:07 <ttx> still one vote short
20:36:16 <flaper87> FWIW, we tried to not have options at the summit and the result after talking to OPs and based on the knowledge we had back then, we thought tooz + options was the probably the best thing in this case
20:36:37 <sdague> we also thought that qpid was a good idea
20:36:40 * flaper87 remembers entering the room with his "I want just one solution" hat on
20:36:44 <ttx> sdague: who did ?
20:36:46 <thingee> flaper87: yeah even though I was moderating I was definitely leaning towards no options.
20:37:07 <sdague> lots of people, options were important. Erlang is yucky.
20:37:24 <mordred> sdague: for the record, I've never thought qpid was a good idea
20:37:25 <sdague> and, it turns out that superstition based on language, is silly
20:37:44 <sdague> the important thing is software has been out there and used under load for a long time
20:37:47 * flaper87 still doesn't think rabbitmq is the best technology to use there BUT that's a whole different discussion
20:37:57 <flaper87> anyway, fwiw, in this case, we also listened to OPs
20:37:59 <sdague> but, I'll let it go now
20:38:03 <mordred> flaper87: for the record, I've never thought rabbitmq was a good idea
20:38:12 <thingee> sdague, ttx lets bring back the burrow mq
20:38:15 * flaper87 hugs mordred
20:38:30 <ttx> hmm, missing one vote... jeblair, russellb, lifeless ?
20:38:52 <ttx> thingee: about that, I'm wondering if we should not burrow cue
20:39:04 <ttx> since it looks a bit dead
20:39:25 * thingee takes note
20:39:34 <lifeless> ttx: I need to do a final close read but its very likely to get my +1
20:39:56 <ttx> oh well, let's go back to anne in the mean time
20:40:16 <ttx> #topic Rewording Freezer mission (again)
20:40:22 <ttx> #link https://review.openstack.org/254239
20:41:21 <ttx> should we require fausto's +1 on it ?
20:41:30 <ttx> flaper87: or do you vouch for his support of it ?
20:41:32 <flaper87> ttx: I'd prefer to wait for his +1
20:41:34 <ttx> ok
20:41:42 <ttx> Let's pile up our +2s still
20:42:09 <flaper87> I can follow-up with him
20:42:43 <ttx> ok, please add your +2 to this one and i'll approve it as soon as Fausto +1s it
20:42:56 <ttx> #topic Cross-project spec rubberstamp: Chronicles of a DLM
20:43:00 <ttx> back on track
20:43:04 <ttx> it has 7+ votes now
20:43:07 <ttx> i'll rubberstamp it
20:43:28 <ttx> done
20:43:31 <ttx> #topic Cross-project spec rubberstamp: Add clouds.yaml support specification
20:43:37 <ttx> #link https://review.openstack.org/#/c/236712
20:43:49 <ttx> last-minute -1 posted
20:44:09 <annegentle> last minute!
20:44:13 <annegentle> harumph :)
20:44:16 * ttx looks sideways to Anne
20:44:24 <annegentle> that was yesterday morning!
20:44:27 <ttx> well, this has been posted 2 monts ago
20:44:31 <annegentle> heh
20:44:36 <annegentle> yeah I'm late to the party
20:44:40 <flaper87> looooooooool
20:44:58 <ttx> It was until then a disturbing contest of approvals
20:45:16 <sdague> annegentle: what's your main objection?
20:45:20 <sdague> I just see the one comment
20:45:43 <annegentle> sdague: since going through that project ID exercise I realized just how many new projects we have
20:45:46 <ttx> thingee: should we put it back to drawing board to address Anne's concern before going back to rubberstamp stage ?
20:45:50 <annegentle> that may or may not already have a client plan
20:46:19 <sdague> annegentle: ok, so it seems sensible to give them guidance here, right?
20:46:31 <annegentle> thingee: would it help if I posted all the names of the clients in that sort of state?
20:46:45 <thingee> ttx: whoops sorry back scroll was stuck
20:46:52 <ttx> that happens
20:47:02 <mordred> annegentle: I can totally add some guidance for new projects
20:47:33 <annegentle> mordred: thingee at the core of my question is this: are there different work items for say a handful of projects that are pretty new?
20:48:01 <mordred> annegentle: it depends on if they cargo culted python-novaclient or not
20:48:06 <mordred> (that's a common way to start a client)
20:48:09 <annegentle> yah
20:48:25 <mordred> annegentle: but if you could point me towards a few new projects, I can look and write up a thing on what newer projects should do
20:48:28 <ttx> ok, let's put it back on the drawing board for at least one week then, sounds like a valuable thing to have
20:48:39 <mordred> annegentle: for context, it took about 45 minutes for me to port python-magnumclient :)
20:48:41 <annegentle> mordred:
20:48:50 <annegentle> heh sorry, I'll get you a list
20:48:56 <mordred> annegentle: thanks! happy to have it
20:49:10 <mordred> one of my tasks for this cycle is making the patches for as many client projects as I can
20:49:17 * mordred exects to rage code over chirstmas
20:49:23 <mordred> s/exects/expects/
20:50:06 <ttx> mordred: will the thing you will write be part of the spec or separate ? Should we just postpone approval on this review ?
20:50:30 * flaper87 thinks mordred will rewrite openstack in rust
20:50:36 <mordred> ttx: let's give it one week so that I can make sure
20:50:41 <ttx> ok
20:50:43 <lifeless> mordred: you don't seem to have a lot of projects input - do you have consensus around this?
20:50:43 <ttx> #topic Cross-project spec rubberstamp: Backwards compat for libraries and clients
20:50:47 <mordred> ttx: it's possible the list from anne could illuminate something missing
20:50:48 * flaper87 knows mordred thinks flaper87 will do that someday
20:50:52 <ttx> So this was added by thingee way after I sent the agenda, so don't worry if you missed it
20:50:58 <annegentle> mordred: it's there, 9 projects or so
20:51:03 <ttx> I'm fine postponing it if we need more time to look at it. If it has 7 votes though we can fasttrack the rubberstamping
20:51:10 <mordred> annegentle: aewsome. thanks!
20:51:23 <thingee> ttx: sorry!
20:51:34 <ttx> #link https://review.openstack.org/#/c/226157
20:51:35 <thingee> yeah we can wait...I'll get better at posting things faster ;)
20:51:47 <ttx> we are 5 rubberstamp votes short
20:52:14 <ttx> and if you've not read it before, will be har dto swallow in the next 9 minutes
20:52:44 <ttx> so maybe let's plan to rubberstamp it next week and give everyone time to read the final version ?
20:53:07 <annegentle> lifeless: nice work there
20:53:14 <lifeless> I'll upload a version today including the thing about having a tag for this
20:53:19 <lifeless> no changes to the meat of it though
20:53:34 <lifeless> annegentle: thanks!
20:53:51 <thingee> ttx: thanks
20:53:56 <sdague> lifeless: so could you comment about how the oslo.middleware issue we just hit fouled here?
20:54:00 <ttx> #action ttx to put "Backwards compat for libraries and clients" and "Add clouds.yaml support specification" back on the agenda next week. TC members to read and vote by then
20:54:29 <sdague> just as we have a set of guidelines, and we had a fail, and it would be good to see where they intersected
20:54:31 <lifeless> sdague: the namespace one ?
20:54:35 <sdague> lifeless: yep
20:54:48 <lifeless> sdague: we did an API break while the API was still in use in deprecated form
20:54:53 <lifeless> sdague: and we had no testing to catch it
20:55:10 <sdague> so L33
20:55:14 <lifeless> sdague: the spec addresses both of those points: deprecate, stop using, stop *supporting*, then delete.
20:55:15 <sdague> it was semver signaled
20:55:32 <sdague> however, we aren't allowed to semver break any existing supported branches
20:55:45 <sdague> so maybe just make that point a little clearer
20:55:57 <sdague> as it's mostly in the parens substatement
20:56:09 <lifeless> sdague: ack, can do.
20:56:23 <sdague> but, yeh, seems solid
20:56:31 <lifeless> sdague: I'll break it into two points.
20:56:36 <sdague> lifeless: great
20:57:07 <ttx> #topic Open discussion
20:57:20 <sdague> from what I see here, I think it's good, I can't project forward every detail off of it, but this seems like the a solid stab in the right direction
20:57:29 <ttx> I can't help noticing the N naming poll is still not started
20:57:34 <annegentle> sdague: ++
20:57:38 * ttx tries not to look at mordred
20:57:48 <mordred> oh. BLAST
20:57:52 <mordred> this afternoon
20:57:53 <sdague> ttx he's not a medusa
20:57:55 * mordred sucks
20:58:09 * mordred waves his snake-hair at sdague and makes his eyes shine yellow
20:58:27 <ttx> Anything else, anyone ?
20:58:34 <sdague> fyi, I'll not be here next week, starting christmas break this weekend
20:58:34 <jeblair> sdague: what shiny yellow eyes you have
20:58:53 <ttx> About dead projects, I think we should remove kite, too
20:59:12 <flaper87> ttx: how are we monitoring those?
20:59:12 <ttx> or at least remove it from projects.yaml, it can stay as a git repo if someone wants to take it over
20:59:12 <sdague> ttx: +1 for removing kite
20:59:16 <flaper87> did you just happen to notice?
20:59:26 <flaper87> or are we relying on stackalytics
20:59:28 <flaper87> ?
20:59:28 <sdague> it was so dubious when it was kept in the first place
20:59:31 <ttx> flaper87: was looking into a specific combination of tags
20:59:39 <flaper87> ttx: gotcha
20:59:41 <annegentle> do we need anything for comms before the disappearing act of 2015?
20:59:42 <ttx> type:service + release:independent
20:59:53 <ttx> and uncovered cue and kite, then looked up stackalytics
21:00:15 <flaper87> annegentle: I was hoping to have the resolution merged, that'd have been a good thing to communicate
21:00:16 <ttx> annegentle: maybe wait next week ?
21:00:29 <ttx> and.. we are out of time.
21:00:40 <ttx> #endmeeting