20:02:11 #startmeeting tc 20:02:12 Meeting started Tue Jun 23 20:02:11 2015 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:13 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:15 The meeting name has been set to 'tc' 20:02:22 Meeting agenda for today: 20:02:23 o/ 20:02:25 o/ 20:02:27 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:02:30 o/ 20:02:35 o/ 20:02:41 Lots of ground to cover, hopefully we won't spend too much time on straightforward things 20:02:48 #topic Add compute starter kit tag 20:02:52 #link https://review.openstack.org/180112 20:02:59 Last week we had limited attendance to the TC meeting so we said we would wait for this week before pushing this in 20:03:13 I think the remaining objections can be proposed as subsequent patches at this point 20:03:23 I still have strong reservations about this one. Can someone reassure me that we're not going to use this tag to allow cross-project teams to refuse to help projects that don't have it? 20:03:25 still short of one vote 20:03:43 dhellmann: I don't think cross-project teams need the tag to do that 20:04:02 dhellmann: I certainly hope that won't happen 20:04:07 ttx: I'm differentiating "help" from "do the work for them" 20:04:08 dhellmann: our job is to encourage cross-project tings 20:04:09 because that's not how I'm seeing this 20:04:11 similarly not certain that a few of the recommendations are things should be suggesting currently 20:04:54 I'd really love a more product centric view on things; I think this is a balanced, neutral stab at that, driven by requests from our newest users. 20:05:05 dhellmann: if a cross-project team refuses to help a given project, then that's a different problem. My point is the tag doen't help or prevent that 20:05:10 ttx: for example, annegentle expressed interest in having this for the doc team, and I would not want them to then say "we're only going to support projects in the starter kit" or "we're only going to include starter kit apps in the install guide" (not saying they would, just an example) 20:05:23 ttx: it might encourage it 20:05:45 dhellmann: so, you're asking for a guarantee that noone here will support the idea of projects not helping other projects based on starter kit membership ? 20:05:47 i do see it as useful input to docs, if for example they did want to write the simplest starter install guide they could 20:05:48 dhellmann: I could see the starter kit prioritizing effort, but not excluding it 20:05:52 or whatever guide 20:05:53 lifeless: yes 20:05:59 I'd love to see other kits to be proposed as well. I may do that if I find the time in the next couple of weeks 20:06:00 russellb: ++ 20:06:01 ttx: good summary 20:06:02 I think that'd help 20:06:14 I'd love to see -more- cross stuff, not less. So you have my guarantee. 20:06:39 dhellmann: if it's used for evil, you can come back and suggest we get rid of it :) 20:06:46 dhellmann: oh that's not the point 20:06:46 dhellmann: more "starter docs definition help" 20:06:46 dhellmann: and yeah, we don't only include certain tags, it's just that tags are doc anyway 20:07:00 ttx: you can't put the genie back into the bottle, though, right? 20:07:08 well, as someone that spent a ton of the last six months building external plugin mechanisms for devstack and grenade for the big tent, I kind of feel my actions speak pretty strongly for supporting a wide range of the ecosystem 20:07:09 annegentle: right, I wasn't saying docs would, just using it as a concrete example of what I wouldn't want to see 20:07:13 i think we could easily remove this tag 20:07:19 right now anyway 20:07:23 apologies my bouncer lost connectivity 20:07:36 dhellmann: sure, it's a decent example 20:07:56 dhellmann: I'm not sure what you mean, we can certaiunly remove the tag as well as we can create it 20:08:13 because if we're ever going to have another tag that requires *this* tag, or we're going to have teams saying "we only work on the starter kit" then I think we should not be documenting this in the governance repository where it implies that is ok 20:08:28 and if a team says I'll only support A B and Cn then the fact that a tag at a given moment covered A B and C doesn't really help or prevent 20:08:31 I'm +1 on this - I _DO_ worry that we're pointing new users at deploying a thing we want to deprecate 20:08:39 that said - I get the purpose, and I think it's well described 20:08:45 and I support its existence 20:08:50 mordred: which, nova-net? 20:08:51 yes 20:09:00 yeh, the nova-net / neutron bit doesn't honestly have a great answer today 20:09:00 mordred: I share the same concern 20:09:06 so I went for simplicity 20:09:07 I would like to reduce the number of new nova-net deployments 20:09:13 i'd like it just the same swapping nova-net for neutron 20:09:14 personally 20:09:18 and if the "start with this" says "deploy nova-net" that's bad for us overall 20:09:29 yeah, we don't really need to make the migration problem worse 20:09:32 dhellmann: does having a "deploy starter kit" in devstack worry you? Because I see that like something that could easily happen 20:09:33 that would be the starter kit *today*. It can change as the neutron story improves 20:09:37 we're also pointing them to multi-host which has the fuzziest migration path of all 20:09:38 mordred: we could quickly iterate on it though 20:09:58 i think it's better to assume you start with neutron, and fall back to nova-net only if needed 20:09:59 yah. we don't need to spin on this - we can adjust and move forward - I just wanted to vocalize that 20:10:00 edleafe: right, my hope is it flips next cycle because we feel confident we have a simple enough story there 20:10:03 dhellmann: so actually, I want to pick up on something here 20:10:12 but yeah, follow-up patch is fine to debate that point ... 20:10:14 dhellmann: I think it would be entirely reasonable for a group to form around making the onramp super easy. 20:10:18 dhellmann: I'd support that. 20:10:21 ++ 20:10:29 dhellmann: I wouldn't support e.g. nova saying 'starter kit only thanks' 20:10:30 flaper87: seems like if you're using devstack, you're past the need for a starter kit 20:10:48 edleafe: but that doesn't mean you couldn't have it 20:10:50 lifeless: right, someone working from this to make things easier is fine. Someone using this to exclude other projects is not fine. 20:11:09 we're discussing the meaning and implications of having the starter kit 20:11:13 right 20:11:13 flaper87: yeah, but still, one does not imply the other 20:11:15 lifeless: we have had a history of "in" projects vetoing ideas and requests from other projects, and I think we should not be encouraging more of that. 20:11:19 so, I kinda feel it's relevant to dhellmann's point 20:11:22 dhellmann: ah 20:11:37 I don't mind having it in devstack (if that ever happens) 20:11:40 lifeless: nova/ceilometer, for example. Or, frankly, nova/neutron. 20:11:45 dhellmann: I guess we'll have to stay vigilant 20:11:47 dhellmann: so, if there's a history, how about we actively oppose that where it shows up, unless you think this is structurally supportive of that... 20:11:50 dhellmann: (I don't) 20:11:51 I just want to know other folk's thoughts 20:12:15 I'm in support of this doc, but it is no longer the thing for which I had hoped we would get that describes technical relationships between the projects. 20:12:15 lifeless: I am a bit worried that it is, but I am glad that most everyone seems to be saying that's not the goal and would not be supported. 20:12:34 dhellmann: hm 20:12:43 dhellmann: one of the things that makes me say it isn't is that its less than a fully useful cloudin every dimension 20:13:08 I believe the moment we see this is going the wrong direction, we should just sit and take a step back 20:13:13 or take a step back and then sit 20:13:19 that makes more sense :P 20:13:30 lifeless: i am much less worried about the technical details than the message we send by identifying a group of projects like this *in governance* vs. a product guide or documentation somewhere else 20:13:31 lifeless: it's the location, not the content, that bothers me 20:13:36 markmcclain: the bit you oppose to is the proposed application of the tag. we could fix that or rediscuss it) when a patch comes to apply that tag 20:13:37 k 20:14:02 lifeless: that said, the nova-net/neutron thing caught my eye, too, though I do understand sdague's goal 20:14:09 and, honestly, the way we keep teams collaborating is by getting in and helping them collaborate. I feel like we made a bunch of progress in the last week on nova / ceilometer interaction for instance 20:14:19 and that was about people just deciding to talk and make things better 20:14:44 ttx: yeah the specific recommendations are a stumbling block 20:15:02 sdague: I won't go over the whole history there, but we tried for a long time to get the nova team to talk about that stuff and were rebuffed. So I think *finally* is the operative word. 20:15:09 sdague: yes, its all conways law :) 20:15:39 and that is a perfect example of what I want to avoid -- nova rebuffed ceilometer because that team was not an integrated project, will we see the same thing for non-starterkit projects now? 20:16:22 we can drop the whole thing because of that risk, or wait to see if that happens and call it out if we see it 20:16:24 dhellmann: slightly different though. Ceilometer was not an openstack project ? 20:16:33 I really think that we should keep our eyes super open to this cases and just rollback 20:16:40 ttx: at some point when we still wanted better nova integration, it was 20:16:57 if it would help, another paragraph could be added to the tag definition around that point 20:17:07 dhellmann: then it was integrated ? 20:17:16 having been on the receiving end of "go away, you aren't one of the cool projects" a couple of times, I might be overly sensitive to this particular issue 20:17:18 or was it during incubation ? 20:17:41 dhellmann: +1 20:18:00 Anyway, I think all the tags designate a subset of projects, and people can piggyback on them for evil 20:18:06 ttx: the problem they're solving now has been there since we started collecting more hypervisor metrics than nova had. I don't know when that started off the top of my head, but I would guess more than 1 year easily 20:18:24 some random person could decide that they don't support projects without team:diverse-affiliation 20:18:43 I don't see how that tag is different or more significant 20:18:47 ttx: this particular tag smells a lot like the integrated release or core, so I think it's different from "release:managed" or whatever 20:19:01 dhellmann: ++ 20:19:08 ttx: the members of this group are unlikely to grow 20:19:23 I don't know what can be done to make it smell less than calling it starterkit 20:19:27 and so no project not in it at the beginning is likely to ever get support from someone that says "you must be in the starter kit" 20:19:57 ttx +1 20:20:22 Just trying to see what's the next step here. You raise fear and doubt, it's hard to be constructive from that 20:20:24 it's clearly a small subset, not a cool club to join 20:20:44 ttx: we should probably move on. I feel like I'm saying the same things I've been saying since this came up, and I feel like the only one hesitating. 20:21:02 dhellmann: markmcclain seems also concerned 20:21:05 this set of projects will grow to exactly one more in the forseeable future. that is based on technical requirements, not popularity 20:21:15 dhellmann: no, I think your concerns are shared, it's just that we trust our ability to fix that if it arises 20:21:28 so, honestly, I think keeping it small is part of what prevents that. Because it's too small for most use cases, except my "first openstack". If we let it get big, then it becomes convoluted with core. 20:21:29 seems like this particular tag needs some additional parallel tags to make people more comfortable 20:21:33 basically it's not a bylaws change, we can iterate and change it 20:22:12 this sends a very powerful signal no matter how we down play it 20:22:19 ok, we need to move on 20:22:31 dhellmann: FWIW, I do share your concern and I was completely opposed at the previous version of this tag 20:22:43 dhellmann: now, that it is called starterkit, it seems more reasonable 20:22:48 it has a majority if Sean votes in favor 20:22:59 and I do, as ttx mentioned, believe in our ability to rollback 20:23:28 ttx: still very concerned with how we'll actually apply the tags 20:23:39 markmcclain: that's a different change though 20:23:47 ttx: there's no mechanism for saying this component in this exact config 20:23:54 we may iterate on the tag defv before we even apply it 20:23:58 dtroyer: you are supposed to roll-call vote as well 20:24:14 argh, done 20:24:26 sdague: you abstain ? 20:24:37 yeh, I said I was going to abstain because it was my patch 20:24:52 I think that's in the early comments 20:25:17 Alright, I think at this point it's easier to merge it and iterate on it 20:25:34 but Doug's point is duly noted, we should keep our eyes open 20:26:10 this is for users to have a short list of projects to start playing with a compute use case 20:26:25 not for excluding projects from the discussion 20:26:45 I could vote for this if it had a non-exclusion section, but I don't feel comfortable voting for it as it is now. 20:27:04 dhellmann: I'd suggest you propose it as a subsequent patch 20:27:06 * flaper87 thinks it'd also help to have other kits instead of just one. That way folks would see that it's not something dedicated to just a set of projects 20:27:19 ttx: ok 20:27:24 ttx: do we have a plan for more use case tags to be proposed? I can work on some if desired. 20:27:26 we can block the tag application anyway, tag definition is not the end of the road 20:27:28 the object-store kit should be easy to write 20:27:51 * ttx will proceed with approval if gerrit ever answers 20:27:54 dtroyer: +1 20:28:09 ?me thinks dtroyer stole my idea...;) 20:28:09 * flaper87 has that in his to-write things 20:28:10 ok, moving on while I wait for Gerrit to reply 20:28:18 #topic Ansible playbooks and roles to deploy OpenStack 20:28:18 dtroyer: low hanging fruit :) 20:28:28 #link https://review.openstack.org/191105 20:28:39 This one looks pretty straightforward to me, no need to spend too much time on it 20:28:48 last time Gerrit was nice enough to answer it was pretty close 20:28:54 * russellb waiting on gerrit too 20:28:54 hi ttx commited that review and am happy to answer any questions. 20:29:07 * sigmavirus24 is around too 20:29:22 any objection, or should I just approve it once it passes 7 yes ? 20:30:02 ttx: gerrit isn't loading, so maybe we should wait to give everyone time to vote 20:30:03 * flaper87 has no objections 20:30:04 is gerrit wearing its slowpants today? 20:30:12 gerrit has been sad all week 20:30:14 been a few days 20:30:25 * sigmavirus24 expected flaper87 to object on the basis of my involvement =P 20:30:25 Finally loading for me 20:30:27 ok it has 7 yes already 20:30:28 gertty ftw 20:30:33 yea its not been happy today at all. 20:30:41 sigmavirus24: did it in my mind :P 20:30:45 so I'll give you extra time to push your +1 on it and approve at end of meeting 20:30:48 the ansible stuff was all straight forward 20:30:49 silly gerrit thinking it can have feelings and such 20:30:57 #topic Add Cue Message Broker Service to Openstack 20:31:01 should we take this as a sign? 20:31:03 :P 20:31:06 #link https://review.openstack.org/191173 20:31:07 cloudnull: is the only repo a specs repo? 20:31:17 i'm here if there are any Cue questions 20:31:20 flaper87: might take it as a cue for zaqar though 20:31:24 For this one I was mostly wondering about the "where it makes sense, the project cooperates with existing projects rather than gratuitously competing or reinventing the wheel" requirement 20:31:33 annegentle: we have https://github.com/stackforge/os-ansible-deployment and https://github.com/stackforge/os-ansible-deployment-specs 20:31:35 so whether Cue was not accidentally duplicating a lot of the work already done within Trove to handle clusters of data things 20:31:56 i.e. are the Cue first-class resources sufficently different from Trove's to make a separate project worth it 20:32:01 cloudnull: ok I'm not seeing the os-ansible-deployement rep in the proposed patch 20:32:13 ttx: would Sahara be considered a duplication of Trove? 20:32:19 well, as a person who has used trove apis in anger - I can say that if I could ALSO get a rabbit from it it would be very strange 20:32:28 ttx: I think they are very different 20:32:39 mordred: "in anger" ? heh 20:32:41 sdague: well, a map/reduce cluster has significantly different properties from a queue or a DB 20:32:43 this feels very much like Trova and Sahara except with a different base resource 20:32:44 and also - I'd love to be abl to request a rabbit and not know anything about how it works 20:32:50 a queue and DB are about storing and retrieving data 20:32:58 and backup and users 20:33:02 annegentle: Line 1177? https://review.openstack.org/#/c/191105/2/reference/projects.yaml 20:33:15 sure - but to me the "don't duplicate" woudl be if this was another dbaas service 20:33:17 i think they're different enough 20:33:20 ttx: queue's are not always about storing data 20:33:27 I think the semantics of provisioning, management may be shared across all of these projects, but the API is definitely radically different 20:33:33 s/queues/messaging systems/ 20:33:33 annegentle: i added into the change set but its not in the body of the commit message . i can update it if you'd like to see it there. 20:33:37 honestly, things went really wrong when we said "everything that is metadata must go in glance" and "everything that touches a network must go in neutron" 20:33:38 flaper87: sure but cue doesn't do data plane 20:33:50 so I don't know why we'd start doing that again 20:34:01 I believe it'd be fair that it could even deploy other messaging systems that are not broker based 20:34:03 especially as it's a thing, with a team, doing a thing 20:34:07 I just want to avoid Trove and Cue copy-pasting 90% of their code 20:34:23 ttx: I believe they can collaborate in some areas 20:34:25 or reinventing what the other already wrote 20:34:27 sdague: agreed; i wonder if there is similarity around the deployment mechanisms in these projects that could be factored out, but the end product is different enough to warrant separate projects 20:34:29 but I don't think the use-case is the same 20:34:41 jeblair: I believe there is 20:34:42 ttx, flaper87: ^ to that point 20:34:47 :D 20:34:52 * flaper87 beat jeblair 20:34:55 w000t 20:35:06 flaper87: you win this round! 20:35:07 flaper87: +1 20:35:08 I'm fine with it if everyone else thinks it's different for a purpose other than just being different 20:35:17 so 20:35:22 I don't understand that argument 20:35:39 if we've *truely* moved from saying 'X is openstack' to asking 'are you openstack' 20:35:47 lifeless: ++ 20:35:49 then being different shouldn't matter 20:35:57 Someone might want to try to do it better 20:36:03 whatever 20:36:04 Well, being openstack is also about collaborating where possible 20:36:06 lifeless: I hate gratuitous duplication of effort 20:36:09 sure 20:36:20 but we just set up a governance structure designed to bring in effort 20:36:21 i just want to make sure this is not one of those cases 20:36:27 we're going to get overlap 20:36:29 yeh, but we're going to get some of it. And it's not like the Trove team showed up and said "don't do that" 20:36:30 I think the point of collaboration where possible is fair and I believe there are areas where these projects can collaborate 20:36:31 because the world isn't neat. 20:36:33 and that it's not "gratuitous" 20:36:40 it's a good thing that vipuls used to be part of trove as well 20:36:44 right 20:36:47 so, that makes it even easier 20:36:48 if the Trove team was strongly objecting here, I think that would be a different thing 20:36:53 right 20:37:00 I think we should be letting concerns like that bubble up 20:37:02 lifeless: i think in the future we may choose to allow _real_ duplication, and even then, i think it's worth discussing and being deliberate about. i don't think we are even that far down the line with this project. 20:37:06 not impose them ourselves 20:37:08 FWIW, vipuls is (used to) be a trove core 20:37:16 I guess you know better since it's a HP thing 20:37:17 jeblair: agreed 20:37:18 vipuls: amiright ? 20:37:23 flaper87: correct :D 20:37:27 used to be ;) 20:37:31 there 20:38:11 ttx: so, the HP angle isn't where I'm coming from here. I mean - yes, initiated by HP, because what they felt the HP cloud users wanted and needed didn't exist 20:38:12 I also think I remember people asking for a thing like this during the very long zaqar integration debate, so it's kind of cool someone showed up and filled that hole. 20:38:30 sdague: ++ 20:38:32 ttx: but my main thing is I want us to really actually truely get out of the way 20:38:53 ttx: and let folk already in the tent come to us with concerns about new entrants 20:38:54 that's actually why I thnk it's good - it's what a bunch of people thought zaqar was and those peopel were happy about that idea 20:38:57 sdague: yeah, I believe it was born close (or right after) Zaqar's second grad attempt 20:39:00 I do think it's another project that warrants the diverity:danger flag, and we should probably take it up. 20:39:05 lifeless: you'll note I'm not opposing it at all, not even voting -1. Just want to put that dead fish on the table 20:39:09 sure 20:39:18 let me slice it up some more, I like sashimi 20:39:31 I think there's value behind Cue, especially if it'll take the pain of maintaining rabbitmq away from me 20:39:33 * jeblair just ate sushi during the last meeting 20:39:33 :P 20:39:37 * jeblair doesn't feel so well 20:39:44 if you're all comfortable wityh it, I am too 20:39:48 jeblair: I *just* ate sushi 20:39:51 :P 20:39:58 we ahve 8 yes, I can approve it now 20:40:11 jaypipes voted -1 though :) 20:40:42 ttx: yeah, sorry, I don't really see much point to this, and have the same concerns jogo did. 20:40:42 jaypipes: didn't leave much of a reason :| 20:41:10 well, "not much point" is not a valid objection, I think 20:41:41 we are out of the business of judging if there is a point. Still in the business of judging if it will hurt a lot more than it helps, but that's about it 20:41:41 I haven't looked at Cue til now, so haven't voted. 20:42:06 vipuls: IMHO, the Cue project is trying to put a REST API around stuff that should be in Puppet manifests or Murano app manifests, and Pacemaker OCF resource agents, and I don't agree with it. 20:42:07 ok, Looks like Gerrit is back, so I'll proceed in approvals 20:42:28 jaypipes: yeah, i honestly feel the same way 20:42:38 i just don't care enough to -1 it, i guess 20:42:38 last call for votes on the previously-discussed changes 20:42:48 i see projects in this category as questionably useful 20:43:02 jaypipes: s/Trove/Cue/ or s/Trove/Murano and that is still valid 20:43:05 other people seem to think it's helpful, so wfm ... 20:43:22 jaypipes: If you read some of my comments back to jogo i don't think it's that simple. It's all about presenting an API that is user-friendly and not shoving everything into a one-fits-all 20:43:23 vipuls: I would vote the same way if someone proposed an OpenStack project that reimplemented Puppet in an OpenStack RESTful API. 20:43:32 approving starterkit at 7 votes, ansible at 8 votes and cue at 9 20:43:48 yeh, I feel like "can be done with Puppet" means we throw out trove, heat, sahara, murano, and a whole bunch of other stuff 20:43:49 vipuls: users don't want to deal with MQ clusters via a REST API. 20:43:59 jaypipes: some might 20:44:00 sdague: +1 20:44:02 s/MQ clusters/MQ cluster management/ 20:44:16 My agreement with this comes from the fact that DBs and Messaging systems are things you *need* to put your app in the cloud 20:44:21 jaypipes: I'd rather get an HA rabbit from my cloud than deploy one with puppet 20:44:31 jaypipes: could you not say the same thing by s/MQ Clusters/databases? 20:44:37 I don't think we are going to approve all projects willing to deploy something and take care of the lifecycle 20:44:41 jaypipes: isn't that zaqar? 20:44:43 i think we've seen the opposite is true 20:44:44 jaypipes: so, count me in the set of users who run things in clouds who would use this for his rabbit needs 20:44:50 ah, s/ helps ;) 20:44:57 lifeless: I could see Zaqar being deployed by Cue 20:45:03 flaper87++ 20:45:04 mordred: I'd rather not reimplement Puppet and Pacemaker in a REST API. 20:45:06 but it doesn't necessarily has to be Zaqar 20:45:08 flaper87: right,I was replying to an abbreviated comment 20:45:12 Im fine with REST APIs to set up Dbs and Queues 20:45:16 you could also say the same thing about nova 20:45:17 jaypipes: I understand that you would not use it. please undertand that I would 20:45:29 users don't want to interact with VM cluster management via a REST api... but they do 20:45:33 lifeless: ++ 20:45:40 I don't think we'll have a REST API to deploy.... PUT_THE_SERVICE_RUNNING_IN_YOUR_HOME_SERVER_HERE 20:45:41 mordred: sure, fair enough. and I would just point you at Murano and say "hmm, that is already done." 20:45:42 Alright, this has enough votes to pass, approving now 20:45:52 at some point we gotta stop 20:46:10 but queues and dbs? You ain't going to deploy a distributed app without those 20:46:11 flaper87: honestly, why. If people do a thing, find their audience, it's fine 20:46:11 jaypipes: possibly so - I think murano is a fine solution to the problem space as well 20:46:20 vipuls: yes, you absolutely can say the same about trove. 20:46:34 Let's move on... lots to cover still 20:46:37 #topic Add Solum to OpenStack Projects List 20:46:43 sdague: mmh, would you have a service that deployes apache ? 20:46:44 thanks folks! 20:46:46 #link https://review.openstack.org/190949 20:46:47 deploys 20:46:47 aw. but I ahven't had a good argument with jaypipes in years. :) 20:46:52 fuck english 20:46:52 lol 20:46:54 We discussed this one last week but couldn't gather enough votes for it to pass 20:47:08 it now has... 5 20:47:33 Questions on that that may or may not make you vote ? 20:47:36 vipuls, mordred: bottom line, I recognize there is a fine line here... 20:47:58 vipuls, mordred: and I'm just logging my general feeling about duplication of purpose, that's all. 20:48:01 jaypipes: ++ 20:48:17 ttx: sorry missed this one earlier... added my +1 20:48:28 arh, merge conflict fun 20:48:34 I think solum is clearly a set of people who are us 20:48:35 jaypipes: yep agreed, appreciate the feedback 20:48:36 I can post a revision 20:48:40 adrian_otto: please do 20:48:49 now, or after more votes? 20:48:55 I got my questions answered just a few minutes ago 20:48:58 it may reset the votes, so now 20:48:58 +1 mordred 20:49:07 ok, will do 20:49:23 jaypipes: I also don't feel like "well, we let Murano in so now it owns the entire space of all service deploys" because if I knew that was a thing, I'd have voted against that. I felt that was a way we were enabling users, not excluding other ways. 20:49:32 adrian_otto: ping us when done 20:49:51 In the mean time I'll cover something else 20:49:54 #topic Add type:library and type:service tags 20:49:57 #link https://review.openstack.org/191891 20:50:00 #link https://review.openstack.org/191892 20:50:13 Those are release-related tags, but I think type:* is more relevant for what we describe here 20:50:18 We could have type:doc one day for example 20:50:21 sdague: fair enough. 20:50:43 merge conflicts there too, added too many new projects 20:50:56 there are merge conflicts everywhere 20:50:58 yes, these new tags are meant to be used by a query tool we have in the release repository so we can find a list of all of the things of a type where we manage the release 20:51:17 oh noes 20:51:19 let's just vote, and we can rebase patches as needed after we're done and let ttx merge them -- we've done that many times before 20:51:22 I'll cast my vote after the rebase 20:51:23 If there are no questions about them I can merge those when they reach 7 yes during the week 20:51:23 my only question on the service thing was horizon being in there, because it's not a service per say, so the wording is a bit confusing 20:51:40 not that I know if there are any better words 20:51:43 some libs are not libs per se either :) 20:51:43 why is horizon not a service? 20:51:55 it's not an endpoint? 20:51:57 dhellmann: no rest api? 20:52:06 service != rest service 20:52:15 service == long running thing 20:52:38 to differentiate it from command line tool, library, docs, etc. 20:52:40 ok, that's fine. 20:52:52 I think with keystone having a "service catalog" ... I hear service and I think "something that registers with keystone" 20:53:00 dhellmann: would it also be correct for service == !library? for things that might have either of these tags? 20:53:01 which I know flys in the face of the meaning of the actual word 20:53:03 yeah 20:53:03 but this is cloud 20:53:07 where we redefine everything 20:53:09 maybe we should say daemon 20:53:11 but meh 20:53:19 dtroyer: the intent is for the type tags to be mutually exclusive, so that each repo only has one type 20:53:22 say daemon if we mean something other than "something we register with keystone" 20:53:25 dtroyer: except there are things there that are not service and not library 20:53:29 like a -specs repo 20:53:31 it's either that or 'project' 20:53:36 jeblair: or 'tenant' 20:53:37 or policy 20:53:37 or tenant 20:53:41 ttx: right, that's what I'm curious about 20:53:44 * Rockyg is pretty sure it's a UI 20:53:47 kk 20:53:50 s/service/daemon/? 20:53:58 * fungi ducks back into the bikeshed 20:54:02 yeh, it's fine, I'm sorry I openned the peanut gallery 20:54:03 ok, let's see what can still be merged in this rebase mess 20:54:10