20:02:46 <ttx> #startmeeting tc
20:02:47 <openstack> Meeting started Tue Jun 18 20:02:46 2013 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:50 <openstack> The meeting name has been set to 'tc'
20:03:11 * mordred saw annegentle around earlier
20:03:24 <ttx> they are all on channel so hopefully they will join... except markwash
20:03:39 <mordred> ttx: you don't hope markwash will join? that's rude
20:03:45 <ttx> vishy: if he is sitting anywhere near you send something on him
20:03:50 <vishy> no he isn't
20:03:56 <ttx> Agenda for today is at:
20:04:00 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:04:21 <ttx> #topic Special motion: TC membership evolution to All-directly-elected model
20:04:39 <ttx> Following the Condorcet poll and the discussion on openstack-dev, I finally drafted a special motion about moving to an "All-directly elected 13" model
20:04:51 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2013-June/010255.html
20:05:12 <ttx> There were no comments or objections on the thread, so I guess we are ready to vote ?
20:05:23 <ttx> (ready, or bored to death about it)
20:05:27 <russellb> ready here.
20:05:51 <markmc> ready, steady
20:05:52 <ttx> As this is a special motion, we need 10 "yes" for this to pass. Abstaining (or not being present) is basically the same as voting "no"
20:06:01 <annegentle> I'm here
20:06:12 <ttx> here he is
20:06:17 <markwash> o/
20:06:20 <mordred> woot
20:06:30 <ttx> so just missing jd__ and mikal
20:06:33 <markwash> sorry folks, traffic and getting a bit lost in wine country
20:06:38 <ttx> let's try this
20:06:45 <mordred> I always get lost in wine country
20:06:46 <jgriffith> markwash: :)  good place to get lost
20:06:50 <gabrielhurley> markwash: your life is so hard.
20:06:57 <ttx> #startvote Accept "TC membership evolution to All-directly-elected model" special motion? yes, no, abstain
20:06:58 <openstack> Begin voting on: Accept "TC membership evolution to All-directly-elected model" special motion? Valid vote options are yes, no, abstain.
20:06:59 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:07:04 <ttx> Hopefully the last vote we'll have on this question :)
20:07:07 <russellb> #vote yes
20:07:08 <mordred> #vote yes
20:07:09 <ttx> #vote yes
20:07:10 <dolphm_> #vote yes
20:07:12 <jgriffith> #vote yes
20:07:13 <gabrielhurley> #vote abstain
20:07:23 <shardy> #vote yes
20:07:25 <markmc> #vote yes
20:07:32 <annegentle> #vote yes
20:07:34 <markwash> #vote yes
20:07:36 <CaptTofu> mordred: and whisky country
20:07:36 <notmyname> #vote abstain
20:07:40 <markmcclain> #vote abstain
20:07:46 <annegentle> whisky shivers
20:07:53 <vishy> #vote yes
20:08:14 <ttx> I think all present voted
20:08:16 <jd__> #vote yes
20:08:17 <ttx> #endvote
20:08:18 <jd__> sorry a bit late
20:08:18 <openstack> Voted on "Accept "TC membership evolution to All-directly-elected model" special motion?" Results are
20:08:19 <openstack> yes (11): markmc, ttx, vishy, shardy, jd__, markwash, annegentle, russellb, jgriffith, mordred, dolphm_
20:08:20 <openstack> abstain (3): gabrielhurley, notmyname, markmcclain
20:08:26 <ttx> jd__: wow, just in time
20:08:31 <mordred> jd__: impressive
20:08:33 <jd__> :-)
20:08:44 <ttx> so we have an approval.
20:08:59 <markmc> we do
20:09:06 <russellb> thanks everyone
20:09:06 <markmc> now we have to make it work :)
20:09:09 <ttx> Awesome. next topic.
20:09:11 <mordred> markmc: ++
20:09:13 <ttx> #topic Incubation request for Designate: initial discussion
20:09:15 <jgriffith> markwash: :)
20:09:21 <mordred> markmc: here's hoping it works well so that we never have to talk about it again!
20:09:28 <markmc> mordred, indeed
20:09:31 <jgriffith> mordred: +1
20:09:34 <ttx> mordred: +1
20:09:37 <russellb> +1
20:09:39 <ttx> So we are reviewing the incubation request for Designate, formerly known as Moniker.
20:09:51 <ttx> #link http://lists.openstack.org/pipermail/openstack-tc/2013-June/000266.html
20:10:07 <ttx> For this week we'll ask preliminary questions and give the Designate crew time to address them before we vote on the next meeting
20:10:22 <ttx> #link https://wiki.openstack.org/wiki/Designate_Incubation_Application
20:10:43 <ttx> Is Kiall around ?
20:10:47 <Kiall2> Yep
20:10:59 <ttx> cool, let's fire questions
20:11:12 * ttx has one
20:11:19 <ttx> Kiall2: You mention that you have a "framework in place to integrate with Nova and Quantum notifications"...
20:11:29 <ttx> and that you will add "functionality to utilize designate-sink to process events from Nova and Quantum"
20:11:38 <ttx> Could you elaborate on that plan ? What is the timeframe for that ?
20:12:20 <Kiall2> So, that statement ia somewhat out of date. Currently, we can receive and process nova and quantum events to trigger dns changes
20:12:29 <Kiall2> We auppprt
20:12:38 <ttx> Kiall2: auppprt?
20:12:50 <mordred> ttx: I'm going to guess he meant support
20:12:56 <Kiall2> We support plugins to customize the exact behaviour
20:13:12 <ttx> mordred: you're good at this. Must be some kind of HP lingo
20:13:17 <Kiall2> Apologies - on a phone.. stuck half way home
20:13:26 <mordred> Kiall2: does that mean that, in theory, "nova boot monty.foo.com" could actually get me a server whos IP is properly configured in DNS?
20:13:51 <Kiall2> Mordred, yea.. thats possible
20:13:56 <dolphm_> that would be cool
20:13:58 <mordred> that would make me the happiest person ever
20:14:04 <mordred> if HP and Rackspace do not both implement that
20:14:08 <mordred> I will physically kill people
20:14:08 <ttx> Kiall2: you receive those events through designate-sink ? Or tat's not available yet ?
20:14:13 <Kiall2> The default plugins create ip-n-n-n-n.bla.com
20:14:32 <dolphm_> mordred: i'll help you get in the building
20:14:34 <Kiall2> Yes, through sink which is available today
20:14:44 <ttx> Kiall2: ok, good
20:15:53 <ttx> So it looks like Designate has two roles: pure DNSaaS in the same way we have Trove to do RDBaaS... but it can also be consumed internally to do smart record updates ?
20:16:45 <simonmcc> ttx: that's correct
20:16:47 <Kiall2> Absolutely - we aim to support end user and internal dns needs
20:16:47 <mordred> well, the two would go hand in hand, right? a customer would "own" a domain - and then they could either update an entry via a direct API call, or nova/quantum could do an update for them, right?
20:16:51 <mordred> cool
20:17:02 <gabrielhurley> What is the plan for expanding/integrating your documentation? I spend a good bit of time talking to someone who was evaluating Designate last week (unrelated to incubation) and he expressed concerns that the only docs he could find tended to suggest needlessly complicated or inadvisable patterns that clearly fit very specific deployment cases (probably HP-internal requirements). I think this is an area where great docu
20:17:45 <ttx> mordred: sure, but that makes it an interesting candidate. Somewhere between our "supporting cast" category (think ceilometer) and the "IaaS++" style (think Trove)
20:18:06 <Kiall2> So, i'll be the first to admit our documentation needs work. Lots of work.
20:18:11 <gabrielhurley> heh
20:18:13 <CaptTofu> I will chime in and say that we on the team will certainly be filling in documentation where needed.
20:18:23 <annegentle> gabrielhurley: thanks for not making me point it out :)
20:18:39 <markmc> Kiall2, you're the only person to merge more than 5 commits in the last 6 months - does that concern you?
20:18:49 <annegentle> though I will say I was unable to get Rackspace to give them source for API docs
20:19:44 <russellb> concerns me ... i'd definitely like to see a more sustainable dev community around it before it was integrated, at least
20:19:48 <mordred> Kiall2: and along with markmc, I see Ryan_lane listed - but do we have any good support from non-HP?
20:20:06 <Kiall2> Markmc: Yes, and no. We've not puahed hard enough for mpre involvement
20:20:09 <mordred> and has there been any word from RAX on interest in moving their DNSaaS to Designate?
20:20:22 <annegentle> Kiall2: what mordred said
20:20:29 <markmcclain> I'm concerned about community size as well
20:20:37 <CaptTofu> mordred: at the conference they were very interested
20:20:41 <Kiall2> Yes, we had a conversation at the summit
20:20:43 <mordred> ok. that's good
20:21:05 <Kiall2> But - Im noy sure what was said in confidence.
20:21:07 <CaptTofu> mordred: I need to reach out to their PM about that
20:21:13 <mordred> I agree with what russellb says - I'd want to see real movement on dev community as a graduation requirement
20:21:28 <ttx> Yeah, I think Designate makes sense from scope and architecture perspective. The most concerning aspect would be dev community expansion
20:21:36 <mordred> CaptTofu: well, I'd like to see that engagement happen in the openstack context, rather than as HP employee to Rackspace PM
20:21:45 <russellb> are there any other projects out there that do this same thing?
20:21:45 <Kiall2> Mordred, i would be happy with that condition
20:22:06 <notmyname> I'm not sure abut the scope question, but I'm still trying to formulate thoughts
20:22:08 <Kiall2> Russellb: yes, but nothing as complete
20:22:16 <mordred> CaptTofu: although if you need to jumpstart that interaction with some phone calls, then go for it
20:22:18 <CaptTofu> mordred: exactly, and some of that has just been the extreme business :) Agree.
20:22:28 <Kiall2> Nova-dns from griddynamics for one
20:22:28 <CaptTofu> mordred: will do.
20:22:47 <mordred> Kiall2: any thoughts from griddynamics about working together?
20:23:07 * mordred is thinking some of these folks might be waiting for designate to become incubated before jumping on board. sigh
20:23:18 <russellb> chicken/egg
20:23:19 <Kiall2> We talked 2 summits ago.. it wasnt ovely productive
20:23:20 <mordred> yah
20:23:37 <Kiall2> Overly*
20:23:38 <mordred> Kiall2: was that due to technical differences?
20:23:51 <russellb> any expected major rework / redesign as a result of recent testing?
20:24:08 <mordred> notmyname: yeah. I'm with you. on the one hand "DNS" seems like decently clear scope. on the other hand - it's DNS, which means it can be anything...
20:24:10 <ttx> mordred: indeed. That's one case where we might need to incubate early and integrate later, to give more time for community coalescence
20:24:17 <Kiall2> There was 2 options, and they disappeared after a vote that didnt choose their option
20:24:32 <mordred> hrm
20:24:55 <Kiall2> Russelb: im eyeing up a v2 api.. but nothing concrete yet.
20:25:06 <jd__> I know people interested in Designate but many are still coping with other OpenStack components at this point :)
20:25:23 <gabrielhurley> "coping with OpenStack". ha.
20:25:57 <notmyname> mordred: I'm concerned that DNSaaS as described should maybe be a subset of nova functionality, and "DNS" is something that should be in an overall "data delivery" project (IMO the current biggest gat in openstack)
20:26:14 <markwash> Kiall2: the "create a server" part of the api. . that's not actually instantiating a dns server, is it? its just registering an existing powerdns or other dns server that is already running, correct?
20:26:33 <mordred> notmyname: gat?
20:26:37 <ttx> gap ?
20:26:39 <mordred> gap!
20:26:51 * mordred tried to fill "gate" in there, and got very confused
20:26:53 <Kiall2> Markwash, down the line users will be able to create private dns servers
20:26:57 <russellb> in fact, mikal has patches in progress to do that in nova
20:27:07 <Kiall2> Today, they provide the NS records for zones.
20:27:13 <annegentle> so how do people do this now?
20:27:16 <mordred> Kiall2: why would a person want a private dns server?
20:27:26 <mordred> Kiall2: rather than control of zone file entries?
20:27:33 <Kiall2> Internal zones "dev.local" etc
20:27:39 <mordred> annegentle: well, I use rackspace dnsaas :)
20:27:43 <mordred> Kiall2: gotcha
20:27:56 <markwash> notmyname: intriguing. . can you expand a little on DNS in a "data delivery" project?
20:27:58 <mordred> Kiall2: so sort of like for people using quantum to create private envs
20:28:12 <Kiall2> Exactly.
20:28:31 <annegentle> within nova somehow?
20:28:39 <creiht> or what is a "data delivery" project?
20:28:45 <ttx> markwash: maybe notmyname means DNSaaS as just another form of DBaaS
20:29:00 <ttx> since that's what it is, after all
20:29:05 <notmyname> ttx: there isn't anything in openstack that does edge delivery or anything beyond internal-DC routing. I think we are missing something in the "networking" pillar of the project (compute, storage, networking), and DNS IMO seems to fit more in that gap
20:29:06 * creiht looks forward to the offical openstack cron as a service
20:29:08 <mordred> annegentle: for OpenStack CI - it's two different api calls for us. We do "nova boot jenkins.openstack.org" then we do "raxdns add jenkins.openstack.org IP_ADDR" or something
20:29:12 <sdague> honestly, given how incredibly useful I've found linode dns with an API to be used beyond guests I have there, I think DNSaaS is completely legitimate as a stand alone
20:29:17 <Kiall2> Annrgentile: yes, i rhink it would boot instances for private dns servers
20:29:26 <mordred> sdague: ++
20:29:32 <ttx> notmyname: oh, I see
20:29:34 <notmyname> but I'm not sure I agree that DNSaaS as described (and I'm still working on figuring out what it means) should be a top-level project
20:29:45 * mordred finds clouds without dns services to be highly unusable
20:29:53 <notmyname> mordred: I agree
20:30:08 <notmyname> I'm not commenting on the usefulness of DNS
20:30:25 <mordred> totally. yeah - it's about placement
20:30:49 <ttx> notmyname: we don't really have "top-level projects". Do you mean "core" or "integrated" ? I'd agree that it's not meant to become "core" with my current understanding of that
20:31:03 <notmyname> actually, one thing I would like to read is what DNSaaS actually does? how is it more than an API to BIND? or service hooks in nova? or deploying BIND servers on nova instances?
20:31:11 <ttx> or that it could be made part of quantum/nova/trove instead ?
20:31:16 <mordred> I think to me it feels 'top level' due to organization. it needs to interact bi-directionally with nova and quantum and its own user-facing stuf potentially
20:31:31 <sdague> ttx: from a nova perspective, I don't think any of us want more scope pushed into nova
20:31:33 <mordred> but that could purely be bias based on past usage experience
20:31:44 <sdague> we've been trying hard to spin scope out, re: cinder / ironic
20:31:49 <russellb> does it do anything for actual setting up of dns servers?
20:31:57 <jgriffith> sdague: +1
20:32:00 <russellb> or is that left as an exercse to the deployer?
20:32:04 <notmyname> ttx: sorry. "top level" as integrated
20:32:05 <ttx> sdague: indeed, and now projects should be free to cover whatever scope is most appropriate
20:32:17 <Kiall2> Notmyname: So, we started simple. API to control DNS
20:32:27 <markwash> DNSaaS in Designate seems to be offering a generic-ish HTTP api for controlling a cluster of DNS servers. . in my limited experience i haven't found good tools for manipulating DNS entries through a generic api
20:32:43 <sdague> markwash: +1
20:32:54 <mordred> also, integrated with keystone auth
20:32:54 <Kiall2> Over time, more complex and involved features will be added.
20:33:04 <clarkb> Merging Designate with nova, quantum, or some other core projects kills the usefulness of a designate install outside of the context of OpenStack
20:33:05 <notmyname> cool. that sounds useful (I hadn't seen a simple description like that in the docs I read yet)
20:33:05 <mordred> which is important in terms of tenant ownership of namespaces
20:33:15 <russellb> Kiall2: are those "future features" documented on your application?
20:33:23 <markwash> if I'm right (my experience is super limited!), DNSaaS isn't like DBaaS because DBaaS presumes that there is already an appropriate data api for controlling things (like SQL)
20:33:28 <sdague> your only real option in that space is basically samba4, which has it's own goofiness
20:33:31 <russellb> ah, i see some future release plans ..
20:33:38 <markwash> s/controlling things/CRUD/
20:33:52 <mordred> sdague: zomg. can we have Samba4aaS?
20:33:56 <markwash> lol
20:34:00 <Kiall2> Russelb: No - were hoping the community will help there!
20:34:23 <mordred> Kiall2: you are the community
20:34:40 <russellb> Kiall2: ok, you just said "in the future we can add more advanced stuff", so curious what you had in mind.  if you don't have anything in mind, that's fine.
20:34:42 <sdague> mordred: and turn everything in openstack into activedirectory, sounds awesome :)
20:34:44 <russellb> it's ok to be feature complete, too.
20:34:51 <creiht> mordred: isn't that basically filesystem as a service, which some of the SAN guys are trying to get going?
20:35:06 <russellb> creiht: mordred yeah, i think that may be starting to move again ..
20:35:21 <Kiall2> Russelb: geoip, weighted round robin, active failover, private dns servers etc
20:35:36 <CaptTofu> russelb: certainly more dns server backends
20:35:50 <mordred> Kiall2: also, I was just poking the trove guys about this - but consider cross-cloud things too
20:36:02 <mordred> Kiall2: such as people who run a single thing (openstack.org) on multiple clouds
20:36:19 <CaptTofu> mordred: you mean compatibility with route 49 or somesuch?
20:36:23 * mordred may be filing feature requests now
20:36:29 <mordred> CaptTofu: nope. I do not care about amazon at all
20:36:39 <Kiall2> Mordred: please do!(
20:36:44 <mordred> CaptTofu: I mean that it's possible that resources may be spun up on mulitple independent clouds
20:36:51 <ttx> Is there anything missing from the incubation request which you'd like to see precised before the vote next week ?
20:36:52 <CaptTofu> mordred: gotcha
20:37:06 <mordred> and some of our newer projects (heat, trove, designate) sit in places where they can either help or kill interop
20:37:14 <mordred> one does not expect a single VM to run on two clouds
20:37:31 <mordred> one MIGHT want a single orchestration engine to spin up vms and dns entries that span clouds
20:37:44 <clarkb> mordred: ++
20:38:10 <mordred> s/one might want/the openstack infra team absolutely wants/
20:38:13 <annegentle> ttx: yes, future feature vision, also a doc plan
20:38:18 <Kiall2> Sure, DNS works best with geo distributed servers.. multi cloud fita there.
20:38:19 <mordred> in any case - that's future direction :)
20:38:24 <Kiall2> Fits*
20:38:43 <mordred> just make sure that makes it into a plan even if local product managers don't care please
20:38:43 <russellb> i would also put out a call for who would be interested in helping
20:38:58 <ttx> annegentle: there is /some/ info about future features on the incubation request. Expand that ?
20:39:17 <russellb> we were sort of guessing earlier that maybe the low level of contribution was people waiting for it to be incubated, but no reason to wait
20:39:25 <markwash> ttx: no extra precision needed for me, but I'm really interested in fitting DNSaaS into our project lineup in the "right" way, in a technical & UX sense
20:39:37 <markwash> basically, interested in further pursuing lines of thinking like notmyname was proposing
20:39:47 <annegentle> ttx: under Future release plans there's no geo, round robin, active failover mentioned
20:39:51 <russellb> markwash: that would be good to see on the ML this week
20:39:56 <creiht> is loadbalancers going to stay in quantum (or whatever it is named now)
20:39:56 <russellb> i'd like to hear more ...
20:39:59 <markwash> russellb: +1
20:40:06 <creiht> if that is the case, any reason why dns should also go there?
20:40:22 <annegentle> ttx: unless I'm not mapping terms to terms correctly
20:40:36 <jdbarry_> mordred: noted re: fitting into future plan (from a local PM)
20:40:43 <mordred> jdbarry_: thank you
20:40:53 <notmyname> I'd love to see DNS integration as a feature bullet point of something larger in scope (like a CDN). I still don't understand the need for a REST API to a DNS server (or at least the need for that functionality to be an openstack project in and of itself)
20:40:54 <jd__> creiht: problems of different levels
20:41:44 <mordred> notmyname: the rest api part I totally get
20:41:51 <mordred> notmyname: as a rampant user of it currently
20:42:13 <mordred> notmyname: but looking at context of larger scoped things is also very intruiging
20:42:47 <mordred> notmyname: primary - if it's not got a public rest interface, then I can't piggyback my current keystone auth token and associate actions I'm taking with my tenant account
20:42:55 <ttx> annegentle: no, it could definitely use a bit more vision, I agree
20:43:01 <mordred> and if I can't do that, then I'm a sad panda
20:43:48 <Kiall2> Apologies - disconnected for a min there. Any outstanding Q's?
20:44:22 <russellb> sounds like there's some stuff worth spawning off to the ML ...
20:45:03 <ttx> creiht: that question was raised in the thread and answered by Kiall @ http://lists.openstack.org/pipermail/openstack-dev/2013-June/010162.html
20:45:04 <russellb> more discussion of how DNS might fit into something larger scope (notmyname), mainly
20:45:08 <Kiall2> Russelb, I'll review the loga and readdress eveything on the ML
20:45:09 <mordred> Kiall2: I think further work on clarifying future scope
20:45:15 <russellb> Kiall2: yeah, was going to suggest that, good
20:45:29 <creiht> ttx: thx
20:46:46 <ttx> OK, I think we can let the discussion continue on the ML this week. And we'll see if we are ready to decide at next week meeting, or if we need more time
20:47:02 <CaptTofu> I would only add having an API for DNS might be seen in a way of why it's useful for any other service that is often used and fits into cloud topology.
20:47:03 <Kiall2> Russelb, so DNS fits everywhere
20:47:33 <markwash> CaptTofu: does not fempute
20:47:34 <CaptTofu> DNS server agnosticism
20:47:41 <markwash> ah
20:47:53 <Kiall2> Keystone catalog alternative, CDN, compute instance addressing, SSH fingerprint validation
20:48:39 <Kiall2> There are potential tie ins all over the place, which makes if dofficult to pick a few!
20:48:47 <ttx> Unless you have more questions, we can switch to Open discussion now (which may still be on this same topic)
20:49:11 <Kiall2> Thanks all :)
20:49:20 <CaptTofu> much thanks to all!
20:49:28 <ttx> #topic Open discussion
20:49:44 <mordred> now that the TC elections vote is done, is it appropriate for me to do a motion for next week about making tripleo a program like oslo?
20:49:53 <ttx> yes, we should start the discussion on "programs" soon, now that the membership evolution discussion is out of the way
20:50:06 <mordred> do we need to have a general programs discussion
20:50:08 <mordred> ?
20:50:15 <ttx> mordred: I'd rather define what a "program" is first, no ?
20:50:20 <mordred> eh
20:50:25 <mordred> I'd actually rather not, tbh
20:50:35 <markmc> a program is a project with multiple repos?
20:50:36 <mordred> because I think we'll rathole on it for 9 months and drive everyone crazy
20:50:49 <markmc> maybe discuss what tripleo as a program would mean
20:50:57 <markmc> would help clarify the idea of programs a bit more
20:51:06 <mordred> markmc: technically, a thing with outcomes in mind, rather than specific products
20:51:19 <ttx> The sticky points are, programs still need to be proposed/approved because they will bring ATC status
20:51:20 <mordred> markmc: so, oslo's is to reduce duplication of common effort across openstack
20:51:34 <mordred> markmc: tripleo's is to do what's needed to make openstack able to boot openstack
20:51:35 <ttx> but yes, can be a rather lose definition
20:51:43 <mordred> in both cases, this can result in separate code
20:51:53 <mordred> or it can result in patches to existing projects
20:52:01 <markmc> hmm
20:52:03 <ttx> mordred: but I'd rather determine what is currently already a "program" before discussing of accepting new ones :)
20:52:08 <shardy> why can't it just be a project, with a stated purpose?
20:52:17 <markmc> getting into "a program covers contributions to other projects" is a bit nebulous
20:52:35 <mordred> well, becuase a project tehn gets in to openstack project semantics - which is where we get in to "does it have a rest api" and all of that stuff
20:52:37 <annegentle> shardy: docs and qa and ci cover all the projects
20:52:40 <mordred> yeah
20:52:43 * markmc thinks oslo as a program is multiple repos with oslo-core overseeing them all
20:52:53 <markwash> is there any way to at least communicate the meaning without going down a rabbit hole or getting legalistic?
20:53:04 <ttx> shardy: currently you are an ATC if you contribute to a set of blessed projects. My vision for it would be to be an ATC if you contribute to a project in a blessed program
20:53:05 <mordred> markwash: right. I think that's what I'd like to do :)
20:53:10 <mordred> I'd say docs, qa, ci/infra and oslo are all programs at the moment
20:53:11 <ttx> like "infrastructure"
20:53:14 <shardy> markmc: well heat has multiple repos, the main stuff, and dependent additional stuff
20:53:31 <mordred> I think it's a different thing from a project with multiple repos, personally
20:53:40 <mordred> mainly because there is no "main" repo from which things split off
20:53:41 <ttx> mordred: we could consider the "integrated release" as a program too. Which would contain all integrated projects
20:53:44 <shardy> markmc: I don't see the multiple repos thing as a defining feature
20:53:50 <mordred> shardy: ++
20:53:52 <annegentle> mordred: how about why you think a program is not a project?
20:53:53 <russellb> and oslo is really close to project ... it's just not user facing like everything else :-/
20:54:10 <ttx> programs could be project containers
20:54:11 <mordred> annegentle: I think a program is not a project because a program is defined as a set of people with a common objective working together
20:54:15 <russellb> user facing in terms of having running services and an API i guess
20:54:19 <mordred> annegentle: and a project is defined by the codebase of the project
20:54:27 <annegentle> mordred: ok that helps
20:54:36 <mordred> so, qa has one repo
20:54:37 <mordred> tempest
20:54:43 * annegentle doesn't rathole just seeks understanding
20:54:45 <mordred> but I don't think _tempest_ is the point
20:54:48 <mordred> as much as integration testing
20:54:58 <mordred> annegentle: totally. it's a weird distinction
20:55:10 <mordred> it's more trying to describe a thing I think we all know is happening already
20:55:11 <dolphm_> russellb: oslo defines a lot of openstack's UX, obviously
20:55:34 <ttx> mordred: we need to see if everything can be considered a program, or if the integrated projects still need some specialcasing
20:55:36 <russellb> i guess i'm saying oslo seems different than docs, qa, infra
20:56:04 <ttx> Oslo is a program with the goal of reducing code duplication
20:56:08 <markmc> group of people with common objective, I buy that
20:56:15 <markmc> that group is oslo-core in oslo
20:56:20 <markwash> russellb: I kinda agree. . now oslo.*utils feels similar though
20:56:27 <markmc> they're people with +2 rights to a group of repos
20:56:40 <dolphm_> ttx: with that kind of definition, i'd say all projects are also programs
20:56:52 <mordred> yes. but not all programs are projects :)
20:56:53 <ttx> dolphm_: or part of the same "integrated release" program
20:57:39 <ttx> I think that's a detail anyway
20:58:02 * markwash out for a little bit, but back in time for glance status
20:58:20 <mordred> ttx: I'll try to write up something for next week based on this discussion
20:58:21 <ttx> the important part is to rewrite/refactor/reorganize https://wiki.openstack.org/wiki/Projects so that it makes sense and is flexible
20:58:26 <markmc> tripleo as part of an official release cycle is probably what's best to talk through
20:58:34 <mordred> markmc: ++
20:58:42 <ttx> so that we ahve a clear "ATC" definition
20:58:57 <ttx> mordred: post that thread early
20:58:57 <mordred> which I think all came about from wanting to do things that would have projects potentially depend on tripleo outputs
20:59:02 <ttx> mordred: or i'll start it
20:59:11 <mordred> like some of hte heat/orc interactions - or trove+dib
20:59:32 <mordred> which is why it feels a little bit more like oslo to me, but I'm not sure I can fully say why
20:59:44 * ttx still has https://docs.google.com/drawings/d/1t1t2Aj1rIvxNnIvbjsiTPe5Szpx-lXBpW1dbL4K08cE/edit?usp=sharing up
20:59:45 <markmc> in both cases, my instinct is they should be optional deps
20:59:47 <markmc> unlike oslo
21:00:02 <markmc> i.e. trove should be happy with any image builder
21:00:26 <russellb> (unless we had an image building API ...)
21:00:28 <ttx> ok, time to close it
21:00:34 <mordred> kk. move to mailing list
21:00:40 <ttx> #endmeeting