20:02:14 <ttx> #startmeeting tc
20:02:14 <openstack> Meeting started Tue Aug 12 20:02:14 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:18 <bswartz1> stupid wireless issues
20:02:18 <openstack> The meeting name has been set to 'tc'
20:02:27 <ttx> The agenda for today:
20:02:29 <esker> various Manila interested parties here as well..
20:02:34 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:02:53 <ttx> dolphm: around?
20:02:55 <ttx> #topic Identity program scope and rename, take 2
20:03:09 <ttx> We had that discussion two meetings ago, it's still a bit stalled
20:03:20 <ttx> It's in two parts
20:03:23 <ttx> 1. Expand scope of the Identity program to include auditing (https://review.openstack.org/109664)
20:03:32 <ttx> So this one hasn't reached the majority threshold yet, although it has enough votes to pass a simple vote
20:03:43 <ttx> It's about moving pyCADF to keystone program and tweaking the mission to reflect that
20:03:54 <ttx> There haven't been enough votes cast on this one, but I don't feel we should block it any longer.
20:04:04 <ttx> especially with both PTLs involved approving it
20:04:17 <dhellmann> yeah, the teams involved with that code agree to the move
20:04:17 <ttx> So I'm calling for final vote on that one -- Please vote on this, otherwise it will pass just because it has 5 +1s and more +1s than -1s
20:04:21 <devananda> I'm curious how this changes the requirement for projects to integrate with keystone
20:04:33 <ttx> (I probably won't pick up the votes before tomorrow though)
20:04:36 <devananda> do all projects now have to integrate with pycadf, if it is part of keystone?
20:04:47 <russellb> it's not part of keystone :)
20:04:54 <russellb> it's part of the identity program (proposed)
20:05:05 <dhellmann> devananda: AIUI, some keystone middleware will use it
20:05:08 <ttx> they are just taking over maintenance
20:05:15 <zaneb> russellb: "Identity:codename: Keystone"
20:05:28 <russellb> zaneb: heh, fair
20:05:28 <annegentle> devananda: well, swift already has ways to be used without keystone
20:05:48 <ttx> The second part is: Rename the "Identity" program (https://review.openstack.org/108739)
20:05:55 <ttx> Now this part is not nearly as popular.
20:05:59 <annegentle> devananda: but yeah, it's a good question, are there dependencies inherited?
20:06:05 <ttx> My take on it is that it's encumbered with the various ways we reuse program names for the moment
20:06:06 <devananda> annegentle: right
20:06:19 <ttx> So I would rather table any program rename until we have come to a point where a program short name really no longer applies to a program
20:06:26 <ttx> In this case it's close enough, I think
20:06:32 <ttx> and we have more pressing issues to address
20:06:33 <annegentle> program renames are really tough for user-facing docs
20:06:43 <ttx> So I think it makes sense to abandon this one for the moment
20:06:43 <jaypipes> ttx: ++
20:06:48 <annegentle> so I'm +1
20:06:51 <dhellmann> maybe we should just use uuids instead of names
20:06:59 <annegentle> dhellmann: frowny!
20:07:01 <devananda> ttx: ++
20:07:07 <ttx> so unless it magically gets 7 +1s oevrnight, i'll abandon this one
20:07:43 <mikal> Hi, sorry I'm here
20:07:49 <ttx> other comments on that before we move on?
20:07:50 <annegentle> I'm sorry you're here too :)
20:07:51 <zaneb> dhellmann: maybe we should just use the code names and stop with the parallel naming :)
20:07:54 <annegentle> just kidding mikal
20:08:02 <dhellmann> zaneb: heh
20:08:13 <ttx> zaneb: I'll work on that as soon as we have all the other problems in openstack solved
20:08:18 <ttx> should be sometimes next month
20:08:26 <annegentle> zaneb: doit!
20:08:35 <annegentle> ttx: I like your timeline
20:08:37 <mordred> o/
20:08:42 <ttx> so, about that...
20:08:45 <ttx> #topic Upcoming graduation reviews & future of the integrated release
20:08:55 <ttx> we have a busy schedule ahead, and I want to talk about how we can meet our deadlines
20:09:08 <ttx> We basically need to have Kilo contents wrapped up by September 16, so that we can plan the design summit AND get the official PTL election process started
20:09:21 <ttx> That leaves 5 meetings to cover all graduation reviews. And one of them falls during Burning Man week
20:09:34 <ttx> If we don't count the recently-incubated projects and the current padawans, we have ironic, marconi, barbican to consider for addition
20:09:54 <jeblair> how many people here will not be here during burning man week?
20:09:59 <ttx> During the same time we have a couple of new program / incubation requests to wrap up (Rally, Manila)
20:09:59 <devananda> ttx: regarding that, this is my last TC meeting until 9/9. probably ditto for mordred.
20:10:13 <mordred> yup
20:10:17 <ttx> devananda: so now it's burning man 3-week ?
20:10:19 * anteaya notes the election process will start earlier than usual due to the new questions feature this round
20:10:32 <mordred> ttx: well, devananda and I go early and stay late because we feed people
20:10:36 <dhellmann> anteaya: "questions"?
20:10:37 <devananda> ttx: yes. well. it's two weeks, but +travel and the meeting falling on tuesday
20:10:40 <ttx> we also need to have some serious discussion on what we want to do with the integrated release
20:10:43 <anteaya> but timelines for nominations and so on will be teh same
20:10:50 <ttx> and we may want to have that discussion *before* considering those graduations
20:11:00 <ttx> Do you think we are on track, or do we need to add a few more meetings to clear things up ?
20:11:01 <jaypipes> ++
20:11:11 <devananda> ttx: I would *really* like to have that discussion without it side tracking to the (also very important) discussion on how to prioritize reviews
20:11:11 <anteaya> dhellmann: we talked aabout submission and curation of questions for tc candidates, for improved voter participation
20:11:21 <dhellmann> anteaya: ah, yeah, I just forgot
20:11:21 <mordred> devananda: ++
20:11:24 <anteaya> dhellmann: it is on my timeline to implment
20:11:26 <anteaya> dhellmann: np
20:11:32 <jaypipes> ttx: personally, the "wtf is the integrated release and why do we care so much about new programs" discussion needs to happen ASAP, IMO.
20:11:36 <mordred> jaypipes: +
20:11:40 <mordred> ++
20:11:42 <mordred> I mean
20:11:46 <ttx> and I know mordred wants to be part of that one
20:11:51 <ttx> so how do we solve this
20:12:00 <mordred> there are two different aspects - one of them is "how do we scale our resources" - but the other is "how do we ship good things"
20:12:03 <ttx> I think it warrants its own meeting
20:12:08 <markmcclain> would it make sense to call a single topic meeting?
20:12:09 <russellb> yes, its own meeting makes sense
20:12:14 <jaypipes> ttx: as do I. this week, preferably.
20:12:16 <mordred> and I think they're both important, and I'm happy to show up at additional times myself
20:12:21 <annegentle> devananda: good point about separating
20:12:26 <ttx> to discuss where we want to go and how much drastic measures are warranted
20:12:33 <markmc> single topic meeting sounds good
20:12:40 <russellb> this week?
20:12:41 <dhellmann> +1 to another meeting
20:12:42 <devananda> ++
20:12:46 * dhellmann never thought he'd say that
20:12:50 <mordred> dhellmann: right?
20:12:52 <annegentle> never hear me say this, but yes let's have an extra meeting
20:13:02 <ttx> mordred: if it's not this week, you will miss it?
20:13:06 <jaypipes> russellb: just cuz devananda and mordred are out until 9/9
20:13:11 <jeblair> i've been away for a few days; is there something very urgent i need to catch up on?
20:13:17 <russellb> jaypipes: no no, i'm agreeing that let's knock it out asap
20:13:22 <ttx> I guess I can find time out of my roof to make that happen this week
20:13:28 <jeblair> i feel like the urgency of this topic is universally agreed to be high and i'm not sure why :)
20:13:30 <jaypipes> jeblair: reading the whole "the future of the integrated release" ML thread...
20:13:33 <ttx> otherwise monday sounded like a good idea
20:13:36 <annegentle> I feel the urgency too
20:13:36 <markmc> jeblair, I've been away too; just the thread AFAIK
20:13:41 <jeblair> jaypipes: thanks, i'll put at at the top of my list.
20:13:43 <mordred> ttx: deva and I could also figure something out if it's next monday, early next tuesday, or late the tuesday 3 weeks away
20:13:48 <annegentle> and it's only Tues/Wed.
20:13:48 <jaypipes> jeblair: it's a meaty one...
20:14:04 <russellb> i just want it discussed and out of the way, so it doesn't get in the way of all of the project consideraions we need to do
20:14:12 <jaypipes> russellb: agreed.
20:14:13 <devananda> I would advise against late tuesday 3 weeks away
20:14:22 <ttx> So I'd propose 19:00 or 20:00 UTC, Monday. If that doesn't work, same hours, this Thursday
20:14:23 <dhellmann> russellb: +
20:14:23 <russellb> i don't want several discussions stalled with "but we need to wait until we decide at the future of release discussion"
20:14:24 <mordred> yes. that would be my least favorite choice
20:14:25 <devananda> if i'm doing aything, it'll be related to juno3 and feature freeze and nova integration
20:14:42 <devananda> russellb: ++
20:14:50 <mordred> russellb: ++
20:14:51 <ttx> or we do Thursday and keep Monday as a backup extra session
20:14:58 <devananda> ttx: wfm
20:15:02 <dhellmann> I like having a backup
20:15:06 <mordred> it's POSSIBLE this one might be a longer discussion
20:15:08 <markmcclain> Thurs then Monday would be my preference
20:15:09 <russellb> any time thursday is fine with me
20:15:12 <jaypipes> me too.
20:15:17 <mordred> thurs then monday ++
20:15:19 * jaypipes will make time.
20:15:31 <jeblair> thurs or mon is fine
20:15:33 <ttx> I guess I can make Thursday work, but 19:00 UTC would have my preference then
20:15:42 <ttx> but I know thaat makes it difficult for mikal
20:15:50 * mordred willing to show up whatever time is good for mikal and ttx
20:15:55 <russellb> same
20:15:59 <annegentle> yeah me too
20:16:01 <ttx> mordred: there is unfortunately no such good time
20:16:04 <mordred> I know
20:16:06 <mikal> I will come whenever
20:16:13 <mikal> This time is about the earliest I would voluntarily do
20:16:15 <markmcclain> happy show up when needed
20:16:16 <ttx> it's either very early for him or very early for me :)
20:16:17 <mikal> (Its 6:15am here)
20:16:34 <ttx> if there was a second "good time" we'd rotate :)
20:16:35 <anteaya> Wednesday at 1800 utc in this channel looks free
20:16:36 * mordred hands mikal a recently blow-dried kitten
20:16:44 <russellb> achievement unlocked: have a meeting about meetings
20:16:45 <mikal> mordred: thanks?
20:16:53 <vishy> o/
20:16:54 <ttx> 18.00 is really too early, not even convenient for me
20:16:57 <dhellmann> russellb: heh
20:16:58 <mikal> So yeah, this time slot on some other day of the week works
20:17:02 <markmc> ttx, do you have a sense of concrete suggestions from the thread that there might be reasonable consensus around?
20:17:16 <ttx> Thursday, 19:00 in #openstack-meeting-3
20:17:16 <russellb> markmc: i certainly don't
20:17:27 <markmc> ttx, agree with devananda that the thread seemed to have been derailed from issues directly related to adding new projects
20:17:37 <ttx> markmc: not really. i want the first meeting to get people to shout problems and proposed solutions
20:17:58 <anteaya> thursday at 2000 utc all meeting channels open
20:18:04 <ttx> then use some time to digest them, and if we think there can be convergence, call another meeting to come up with something
20:18:10 <anteaya> wednesday at 2000 -alt and -3 open
20:18:27 <ttx> everyone OK for Thursday, 19:00 in #openstack-meeting-3 ?
20:18:31 <markmc> ttx, just wondering whether we can make real progress on list in preparation for the meeting
20:18:40 <annegentle> is 19:00 UTC now?
20:18:41 <mordred> we may just have to bring our own brains
20:18:46 * annegentle asks the dumb time questions
20:18:47 <mikal> Yep
20:18:51 <ttx> annegentle: now is 20:18 UTC
20:19:05 <ttx> 20:19
20:19:08 <dhellmann> annegentle: 3:00 Eastern
20:19:09 <ttx> :)
20:19:18 <annegentle> Got it, thanks
20:19:23 <jaypipes> 4 eastern.
20:19:30 <annegentle> heh hm
20:19:38 <ttx> #info Extra TC meeting on Thursday, 19:00 in #openstack-meeting-3
20:19:56 <jaypipes> oh, 1900UTC, yeah, 3 eastern
20:20:10 <devananda> markmc: i think it was derailed from the topic of culling fail[ed/ing] projects, which is related to not adding new projects.
20:20:10 <ttx> #info specific agenda: The need for change in integrated release for Kilo
20:20:18 <ttx> (or absence thereof)
20:20:32 <ttx> OK, next topic
20:20:43 <devananda> markmc: and that the litmus we use when deciding to add new projects should be mroe than just "meets QA and release process standards"
20:20:58 <russellb> devananda: the requirements list is already quite a bit more than that
20:21:16 <ttx> Feel free to fire warning shots on that ML thread
20:21:25 * dhellmann hopes anyone with specific goals makes them clear in that thread before thursday
20:21:28 <russellb> i'd rather concrete suggestions / discussion than warning shots
20:21:31 <ttx> although don't expect me to particiapte that much, I still need to rpetend I'm taking 3 days ofgf
20:21:37 <markmc> devananda, actually, that felt like a slight derailment from the original topic - that we're hitting scaling limits as we add new projects
20:21:55 <dhellmann> russellb: +1
20:22:17 <ttx> russellb: yay, getting a bit more info on everyone's position on this could help
20:22:24 <ttx> ok, we need to move on
20:22:26 <ttx> #topic Propose Manila for Incubation (initial discussion)
20:22:27 <mordred> markmc: I thought that the original topic presented the general issue in such a way that that seemed like the one and only topic at hand
20:22:33 <bswartz> I'm still here -- wireless appears to have stabilized...
20:22:36 <mordred> markmc: but I can try to express that better on the list
20:22:37 <ttx> bswartz: o/
20:22:50 <ttx> The program application is at:
20:22:56 <ttx> #link https://review.openstack.org/111149
20:23:00 <ttx> And the incubation application at:
20:23:04 <ttx> #link https://review.openstack.org/#/c/113583/
20:23:20 <ttx> Manila was considered and application was rejected/delayed in the past
20:23:33 <bswartz> in November 2013 to be exact
20:23:34 <mikal> ttx: so, the disconnect here is strange to me. We have an issue of general policy (are we too big) which we've deferred, but we're not discussing an issue of specific policy (should we become bigger by adding a thing)
20:23:43 <mikal> ttx: shouldn't this conversation happen after the first one?
20:23:45 <ttx> Incubation application has a pretty good account on what was said then
20:24:00 <ttx> mikal: yes, at least final decision needs to
20:24:01 <mikal> s/not/now/
20:24:10 <devananda> ... what mikal said
20:24:17 <bswartz> yeah we included an appendix in the incubation application answering questions raised last time
20:24:22 <ttx> but I figured we could still have a few early questions
20:24:37 <mikal> Nothing against Manilla
20:24:37 <ttx> If you feel like this is useless, we can skip though
20:24:54 <russellb> this is what i was afraid of ... deadlock until the other is resolved
20:25:00 * jaypipes recommends skipping until we answer the bigger questions.
20:25:00 <mikal> Useless is a bit strong
20:25:13 <mikal> Well, we could talk it through but defer our decision
20:25:17 <esker> ttx: the summary you'd issued from the November discussion on the topic "We would like to have Manila in OpenStack one day, needs more maturation, solve multi-tenant concerns and get devstack-gate integration before revisiting incubation request"
20:25:21 <mikal> That gives scope for if we have questions which need time to answer
20:25:22 <russellb> we need to move swiftly on the "big questions" so we don't leave all of these projects hanging though
20:25:24 <dhellmann> well, bswartz, how much code is manila still sharing with cinder? are you copying stuff back and forth there?
20:25:25 <russellb> that's not terribly fair to them
20:25:40 <annegentle> I do want to hear about cinder collab and so on
20:25:42 <ttx> How about bswartz quickly introduces the recent progress they made, but we don't judge yet, and move tyo next topic ?
20:25:43 <bswartz> dhellmann: no, we don't copy anything -- the common stuff is in oslo
20:25:45 <annegentle> is jgriffith around?
20:25:55 <ttx> So that he didn't come here for nothing ?
20:25:59 <bswartz> leftover overlapping code is gradually being removed and replaced with oslo stuff
20:26:03 <dhellmann> bswartz: so after that initial fork, you haven't updated anything based on ongoing work?
20:26:03 <russellb> yes, i'd love to hear about progress
20:26:47 <bswartz> dhellmann: no we're not messing with cinder code at all -- we have everything we needed from the original fork
20:27:00 <dhellmann> bswartz: that's not a bad thing, I'm just trying to understand the split, because a lot of the application emphasized how similar the architectures of the two projects were, and I wonder if there should be more code shared
20:27:16 <devananda> bswartz: how much duplication of code is there now between cinder and manila? and what portion of that should be oslo'ified in the fullness of time?
20:27:17 <bswartz> the only sharing we envision at this time is through oslo
20:27:24 <bswartz> we'll push to move more common stuff into oslo ofc
20:27:53 <markmc> devananda, dhellmann, could ask the same question about cinder/nova
20:28:00 <esker> with all due respect, we've engaged on a number of occasions in the past and made major changes to Manila in response... in good faith.  It seems poor form to change the game on us yet again.
20:28:15 <bswartz> the duplication is fairly low at this point -- mostly not we inherit the architecture, in terms of the services and their relationships
20:28:21 <dhellmann> ok, well, oslo isn't the only way for you to share code if it's just the 2 projects using it, so I'm worried that the oslo team will have to agree to adopt something that the 2 teams could be managing together without us
20:28:22 <bswartz> mostly now*
20:28:27 <dhellmann> markmc: yes, indeed
20:28:54 <dhellmann> but it's good to know that oslo is on your radar, in any case :-)
20:29:07 <bswartz> as for a general update on our progress, we have many more vendor involved now, and even more asking about how to get involved
20:29:30 <mikal> Do those vendor drivers all implement a similar level of functionality?
20:29:33 <dhellmann> do you envision having third-party testing like some of the other vendor-heavy projects?
20:29:35 <bswartz> a good bit of work went into satisfying specific requirements  (like the gate integration, docs, etc) late last year
20:29:36 <mikal> How granular is the functionality in fact?
20:29:40 <russellb> #link http://stackalytics.com/?release=all&project_type=all&module=manila
20:29:50 <bswartz> since then we've been working on new features and broader driver support
20:29:55 <jaypipes> bswartz: Looks to me that https://github.com/stackforge/python-manilaclient's README is still referring verbatim to the cinderclient's README. Just FYI...
20:30:26 <bswartz> regarding third-party testing, we plan to replicate the approach cinder is taking
20:30:32 <markmc> #link http://stackalytics.com/?project_type=all&module=manila&release=all&metric=commits
20:30:38 <markmc> russellb, commits :)
20:30:41 <bswartz> cinder is hitting some bumps in the road and we're learning a lot for free
20:30:49 <russellb> markmc: d'oh, i keep forgetting the default change
20:30:54 <devananda> bswartz: curious, how well does the manila API  abstract vendor differences
20:31:12 <mikal> bswartz: have you considered at all what functionality to require as a minimum from drivers? That might save you some pain later.
20:31:19 <jeblair> bswartz: what third-party drivers are you including?  what first-party drivers?
20:31:29 <bswartz> devananda: right now it does it very well because the API is quite lowest-common-denominator
20:31:29 <annegentle> markmc: oh yeah good point
20:31:37 <dhellmann> wow, 79% from the top company
20:31:40 <russellb> commits makes the project look a lot less diverse than i thought, though i think we've settled on that being primarily a graduation concern, not incubation
20:31:43 <devananda> bswartz: nice. do you have auto-generated api docs?
20:31:57 <bswartz> as we add more cool features keeping the API abstracted will be a challenge but no more than the challenge cinder faces doing this
20:31:59 <dhellmann> mikal: +1
20:32:15 <ttx> dhellmann: drops to 72% in Juno fwiw
20:32:26 <bswartz> jeblair: the first-party driver we support is called "generic" and it's software only
20:32:34 <bswartz> it layers on top of cinder and nova
20:32:34 <annegentle> devananda: at the incubation request, our requirements for docs are only for contrib docs
20:32:44 <jeblair> bswartz: what shared filesystem does it use?
20:32:49 <esker> NFS
20:32:52 <bswartz> for third party drivers we have netapp and glusterfs in tree
20:32:55 <annegentle> devananda: would still like to know the answer, but just noting
20:33:02 <bswartz> jeblair: ext4
20:33:03 <esker> NFS for the generic driver
20:33:15 <bswartz> and NFS for the sharing
20:33:18 <vponomaryov1> jeblair: nfs and cifs
20:33:24 <bswartz> actually cifs too
20:33:34 <jeblair> bswartz: does it provision its own nfs servers, like trove does for databases?
20:33:38 <devananda> annegentle: if they aren't able to autogenerate docs eg. with sphinxcontrib-pecanwsme, it's going to be more challenging later to retrofit that
20:33:53 <devananda> annegentle: but yes, i agree, not an incubation req
20:33:53 <bswartz> and we have several more 3rd party drivers in development or waiting for merge
20:33:54 <vponomaryov1> jeblair: yes, depends on driver
20:33:57 <annegentle> devananda: yes
20:34:11 <bswartz> jeblair: yes
20:34:16 <russellb> what's the mapping between VMs, cinder volumes, and NFS shares?
20:34:16 <jeblair> bswartz: why is glusterfs considered 'third party'?
20:34:36 <rcallawa> russellb: designate had 68% in juno timeframe as well - http://stackalytics.com/?project_type=all&module=designate-group&release=juno&metric=commits
20:34:37 <ttx> bswartz: could you link to the nice incubation requirements table you prepared?
20:34:38 <bswartz> well it's maintained by redhat
20:34:56 <vponomaryov1> russellb: nova creates VM with our image where nfs and cifs are preconfigured and uses cinder's volumes as devices for shares
20:35:04 <bswartz> #link https://wiki.openstack.org/wiki/Manila/Graduation#New_Program_Requirements
20:35:08 <russellb> ok, so a VM and volume created per share?
20:35:16 <ttx> bswartz: thx
20:35:27 <vponomaryov1> russellb: volume per share, VM  not
20:35:39 <vponomaryov1> russellb: VM per tenant network
20:35:42 <russellb> k
20:35:46 <jeblair> makes sense
20:35:55 <russellb> yep
20:36:15 <bswartz> vponomaryov1: thanks for jumping in with answers , I can only read/type so fast..
20:36:50 <ttx> OK, any more question for this first round ? We always do those reviews in two rounds fwiw, so this is not really special
20:37:06 <russellb> fwiw, this still seems like useful functionality, and i'm hoping we can work through our growing pains without hurting the progress and momentum here
20:37:08 <jeblair> bswartz: glusterfs seems like a useful bit of free software to support; so i think what i'm trying to get a handle on is how opinionated manila wants to be... what's your criteria for 'third party' drivers vs internal support
20:37:13 <ttx> I think it gets the elephants out of the room
20:37:18 <jeblair> russellb: agreed
20:37:39 <bswartz> we don't want to be opinionated about drivers -- that should be the admins choice
20:37:49 <annegentle> yep I think it's useful functionality
20:37:52 <dhellmann> russellb: +1
20:38:07 <bswartz> as PTL my goal is the make the project maximally useful -- not to promote particular backends
20:38:21 <markmc> agree this looks like a lot of promising progress, nice work
20:38:26 <jeblair> i'm also wary of another neutron -- where all the "real action" happens with proprietary hardware and there's very little support for a fully open source solution
20:38:28 <ttx> From an architecture/position standpoint it seems to fill the same spot as Trove or Designate, provision useful base services
20:38:30 <annegentle> bswartz: what's your sense of vendor interest vs. user interest?
20:38:36 <mordred> jeblair: ++
20:38:38 <dhellmann> jeblair: +1
20:38:39 <annegentle> jeblair: yeah that's sort of what I mean too...
20:39:00 <bswartz> annegentle: we're seeing a big spike in vendor interest, but user interest has been steadily high
20:39:11 <annegentle> bswartz: ok good to see correct order of cart and horse
20:39:13 <jeblair> so it's great to see nfs in there as the primary driver; i think exploring why glusterfs didn't make the cut will be interesting
20:39:14 <esker> user interest has greatly outweighed vendor interest to date.
20:39:17 <markmcclain> jeblair: +1
20:39:20 <devananda> bswartz: how are yhou planning to handle vendor differentiation?
20:39:32 <ttx> bswartz: also you don't want to be another Cinder -- being the target of a zillion driver request is not that fun
20:39:43 <markmc> annegentle, you know, that's a great question - I think user interest should be huge in this, but it isn't something other clouds offer ...
20:39:56 <bswartz> ttx: I actually think that's not unlikely, and we're prepared for it
20:40:06 <markmc> annegentle, i.e. we can't just say "AWS has this and people use it a tonne"
20:40:23 <annegentle> markmc: right
20:40:32 <markmc> annegentle, I've heard people say they'd love AWS to have something like this though, but that's just anecdata
20:40:33 <ttx> markmc: yeah. I found quite a number of people that were regretiing that AWS didn't have this though
20:40:34 <jeblair> markmc, annegentle, bswartz: it's definitely the sort of thing we have often discussed would be useful in infra (putting on our "really big user" hats)
20:40:39 <vponomaryov1> devananda: two types of drivers, where some, like gluster fs can not have network isolation
20:40:44 <esker> ttx: in some ways that's exactly what end users have asked of Manila though.... a single, abstracted API for provisioning of shared file systems.  That almost certainly will invite vendor specific implementations behind it.
20:40:49 <markmc> I wonder if we could get some sort of a question into the user survey about upcoming projects
20:40:55 <devananda> vponomaryov1: i mean, where vendors want to add $special-feature
20:41:01 <markmc> "which solve a real need you have?"
20:41:10 <dhellmann> markmc: good idea
20:41:24 <russellb> i feel like this has come up in conversations for me several times though
20:41:25 <bswartz> On the plus side we can follow the trail that the cinder project has blazed
20:41:29 <russellb> but it's just a gut feeling, i don't have data
20:41:34 <vishy> so i have a small concern about knock-on features, let me see if I can express
20:41:41 <devananda> esker: users want the common abstraction, sure -
20:41:49 <vishy> currently cinder is lagging nova for some pretty significant features
20:42:03 <markmc> russellb, not saying lack of data is a blocker for me, have a gut feeling too - but could be easy to get and very interesting
20:42:03 <devananda> esker: but vendors will want to differentiate, leveragign some $special $feature, to increase sales of their hardware
20:42:05 <vishy> in the past we had things like scheduler improvements, db races
20:42:12 <devananda> esker: and i'm curious how you plan to balance these two demands
20:42:12 <russellb> markmc: indeed
20:42:18 <rcallawa> markmc: our overview session at the atlanta summit on manila was standing room only - as one indicator of interest
20:42:26 <vishy> currently it is the object model and rpc versioning
20:42:28 <russellb> rcallawa: awesome
20:42:28 <markmc> rcallawa, excellent
20:42:47 <vishy> you still can’t upgrade cinder versions without restarting
20:43:01 <vishy> so it seems that things go, make changes in nova, some get pulled into cinder
20:43:18 <vishy> i’m concerned that since manila is a fork of cinder that adds another step in the trickle-down
20:43:20 <ttx> timeboxing to 5 more minutes
20:43:21 <esker> devananda: Cinder is certainly instructive in this light... and it is ultimately a balance.  I think it also makes sense to acknowledge that of course vendors will want to put their best foot forward.
20:43:28 <bswartz> vishy: manila is not as tightly coupled to nova as cinder is
20:43:36 <markmc> vishy, conclusion? cinder should never have split out? more focus on cross-project/oslo sharing?
20:43:39 <vishy> its not the coupling i’m concerned about
20:43:51 <vishy> its that important features get pushed into nova
20:43:58 <vishy> and then cinder gets them eventually
20:44:00 <bswartz> in fact manila attempts not to involve nova at all (although we do have plans to support attach-by-instance-id)
20:44:05 <dhellmann> vishy: the fact that the manila team seems to have a better attitude about working on sharing via oslo makes me think that will be less of a problem with them
20:44:12 <vishy> if you are waiting on cinder to lead the way then there is a longer delay
20:44:31 <vishy> i guess i’m suggesting that they should attempt to pull things more quickly from nova
20:44:32 <ttx> vishy: I don't think they depend on cinder though
20:44:35 <vishy> like the object model
20:44:39 <bswartz> we're not waiting for cinder -- it's just a reality that they are about 2 years more mature than us and they hit problems earlier than we do
20:44:47 <ttx> vishy: in my understanding they mostly use cinder as atemplate, rather han a fork
20:44:48 <vishy> like filter_secheduler
20:44:50 <vishy> etc.
20:44:50 <dhellmann> vishy: yeah, I'd like that object code to go into the incubator next cycle to make that easier
20:44:50 <markmc> ah, I see - well, good advice for manila folks there - if you're syncing new features (like object model) don't wait for cinder to adopt first
20:45:01 <jgriffith> markmc: hmm... merge cinder back in to Nova then?
20:45:10 <esker> jgriffith: seriously?
20:45:15 <bswartz> markmc: thanks
20:45:17 <vishy> i understand it was a template, but the reality is cinder often doesn’t know about improvements until nova makes tehm
20:45:22 <russellb> dhellmann: fwiw, it was submitted before and denied :)
20:45:22 <dhellmann> vishy: I've talked to dan about it, but we didn't get to it this time around
20:45:27 <vishy> for example retry_on_deadlock was only just added
20:45:31 <dhellmann> russellb: yep, that was me, and I've talked to dan about it
20:45:35 <russellb> cool
20:45:46 <dhellmann> russellb: just expect it to be fixed once it comes over :-)
20:45:55 <russellb> heh, k
20:45:56 <vishy> so concretely, my suggestion is parts of the code that were ultimately derived from nova
20:45:58 <ttx> vishy: well, obviously adding another project (whichever it is) will increase the need for cross-project coordination
20:46:02 <vishy> track nova directly for changes
20:46:14 <markmc> vishy, ironically, if manila had started from scratch we wouldn't really ask about this yet the problem would be same/worse
20:46:20 <vishy> like the db layer stuff, the object model stuff etc.
20:46:51 <vishy> markmc: that is true, but might as well take advantage of the grandparent code in this case :)
20:46:53 <ttx> vishy: oh, I see what you mean
20:47:05 <markmc> vishy, yep, it's a good point
20:47:09 <dhellmann> I see lots of oslo libs in the manila requirements already, which makes me happy. :-)
20:47:15 <devananda> i think the point is, nova is leading several changes, and its better to be following that directly than following a follower
20:47:18 <esker> vishy: not intention to follow Cinder, but rather to learn from it given common heritage
20:47:31 <vishy> cool
20:47:49 <ttx> OK, we need to move on, we'll have another session on Manila in a future meeting.
20:47:58 <esker> thanks
20:47:58 <annegentle> thanks bswartz and esker
20:47:58 <bswartz> thanks guys
20:48:01 <ttx> You can continue those discussions on the Manila incubation ML thread
20:48:17 <ttx> which didn't attract so much comments until now :)
20:48:24 <ttx> eglynn: around?
20:48:29 <eglynn> ttx: o/
20:48:30 <ttx> #topic Background information about Gnocchi project
20:48:35 <ttx> #link http://lists.openstack.org/pipermail/openstack-tc/2014-August/000757.html
20:48:40 <ttx> eglynn asked for some time to explain a few things about Gnocchi
20:48:46 <eglynn> ^^^ background on that ML thread
20:48:50 <ttx> We don't have that much time left, but since Eoghan will be in vacation soon, maybe a quick mention here can't hurt :)
20:49:04 <markmc> are there TC-level concerns?
20:49:07 <eglynn> yeah thanks for the opportunity ...
20:49:11 * markmc thought the mail was a nice summary
20:49:12 <ttx> I'm timeboxing this to 6 minutes so that we have time to cover the other changes
20:49:15 <russellb> markmc: ++
20:49:16 <eglynn> well the intent is just to get TC folks caught up on what gnocchi is about
20:49:24 <markmc> cool
20:49:26 <russellb> thanks for the ML post
20:49:31 <eglynn> as there was an info deficit
20:49:47 <eglynn> yep, so the TL;DR is ...
20:49:57 <eglynn> gnocchi is an arms-length project from ceilometer, in which we're exploring one option to pay down some architectural debt
20:50:06 <eglynn> happy to answer any questions is there's time
20:50:22 <mikal> So there are no plans to move to it at this time?
20:50:23 <eglynn> I did go into a bit more detail in the thread on what it is, and what it ain't
20:50:24 <ttx> i'm still a bit confused on the scope overlap between Gnocchi and InfluxDB
20:50:27 <mikal> Its still an experiment?
20:50:34 <devananda> eglynn: did anyone look into existing time-series databases before implementing another one?
20:50:43 <russellb> sounds like a nice way to try out a major improvement, without too much disruption to the project for now
20:50:44 <zaneb> eglynn: would it be fair to describe it as a branch that will eventually be merged back or not?
20:50:44 <russellb> seems reasonable
20:50:48 <ttx> there seems to be a layer that would be duplicated between them
20:50:48 <russellb> and something we should encourage
20:50:56 <eglynn> mikal: timeline is kilo to swicth if it meets the grade
20:51:10 <eglynn> zaneb: yep that's fair
20:51:24 <eglynn> devananda: well we're not just reinventing
20:51:32 <mikal> eglynn: how do you decide if it meets the grade? What's the process for that?
20:51:33 <devananda> eglynn: "not jsut reinventing" ?
20:51:40 <ttx> devananda: they can piggyback on a time-series DB, but yeah, it seems like they would reimplement some parts of it
20:51:40 <mikal> eglynn: a summit session?
20:51:57 <eglynn> devananda: ... there's a pluggable driver model that allows us to plug in InfluxDB etc. as the backend
20:52:18 <eglynn> mikal: at the juno session, yes there was a session
20:52:42 <eglynn> mikal: https://etherpad.openstack.org/p/ceilometer-tsdaas
20:53:06 <eglynn> mikal: a-ha, you mean at the kilo summit?
20:53:34 <eglynn> mikal: yes the process would include performance profiling and ensure a semantic match in the API
20:53:36 <ttx> The thread explains the sitiation pretty well, and it just gets started
20:53:55 <mikal> eglynn: ok, cool
20:53:59 <ttx> so I think discussion can continue there
20:54:00 <mikal> eglynn: that's what I was asking about
20:54:00 <mordred> I'm still very unclear as to why a new time-series anything needs to be written
20:54:06 <devananda> eglynn: I'm sure there's a reason why gnocchi didn't work with trove to provision influxdb instances?
20:54:09 <devananda> mordred: as am I
20:54:38 <dhellmann> gnocchi is also partially a response to all of the complaints about operators having to learn yet another new service, since can use swift for storage
20:54:52 <eglynn> mordred: sandy raised a similar question on the ML, and I go into more detail there on the additional semantics
20:55:09 <mordred> eglynn: ok. I'll go read that before I dive in more
20:55:10 <ttx> yeah, I think the discussion can continue tere, we won't solve it in 4 minutes
20:55:10 <eglynn> mordred: (i.e. above and beyond pure timeseries storage)
20:55:18 <mordred> but it seems very much like a description of carbon
20:55:22 <ttx> Thanks eglynn
20:55:32 <dhellmann> mordred: apparently the carbon code is really ugly
20:55:35 <mordred> which already exists and is in use at massive scale around the world and is in python
20:55:38 <mordred> *meh*
20:55:52 <jeblair> that's clearly not stopped us before
20:55:52 <russellb> works > pretty :)
20:55:54 <mordred> ugly code is not a reason to write a new thing
20:56:08 <jeblair> russellb, mordred: ++
20:56:17 <dhellmann> well, from the perspective of it not quite doing what we want and also being hard to change, it might be
20:56:19 <markmc> mordred, we could give the program the benefit of the doubt that they're not NIH for the sake of it
20:56:43 <russellb> yes, i think we should assume good faith on that ... but a summary about what was considered and why it didn't work out would be good
20:56:44 <mordred> markmc: no, I don't think we have very good track record with that overall aroudn here
20:56:57 <mordred> I don't assume bad faith
20:57:04 <mikal> I feel like at this point we should let gnocci do its thing, and then ask for a merits based comparison with other options before its baked into ceilometer
20:57:17 <eglynn> russellb: I can dig out more detail on jd__'s analysis of the fit with carbon
20:57:21 <mikal> Its not really fair comparing a half done thing with a finished thing
20:57:27 <russellb> eglynn: sounds like that'd be helpful
20:57:29 <jeblair> agreed, i think we need to ask these questions, if for no other reason than people may simply not be aware of all the options.  we have things to offer other than just being grumpy.  :)
20:57:31 <eglynn> russellb: cool
20:57:36 <mordred> mikal: I DO think it's fair
20:57:38 <eglynn> mikal: fair point
20:57:49 <zaneb> mordred: I'm not sure that's true, although we definitely don't have a good track record of communicating why something is not NIH
20:57:51 <dhellmann> jeblair: we got quite a lot of both at the summit in atlanta :-)
20:57:52 <russellb> it's not comparing gnocci with carbon
20:57:56 <sandywalsh> my only suggestion is the tsdb portion be one project and the abstraction layer be another (gnocchi proper)
20:57:58 <russellb> it's comparing carbon to requirements
20:58:04 <mikal> mordred: it sounds like other options were considered before they went down this path
20:58:08 <mordred> mikal: and if that thing is intending to a substantial part of an integrated project, then I think it's worthwhile for us to get involved if we're going to be on the hook for maintaining a thing
20:58:16 <mikal> mordred: I think we should leave second guessing them until they're done with their counter proposal
20:58:33 <ttx> OK, let's continue that discussion (1) on the thread and (2) at the special meeting
20:58:38 <jeblair> mikal: it also sounds like they weren't aware of influxdb at the time
20:58:41 <mordred> mikal: ok. I'm just saying, I do NOT think we need to wait until the thing is finished to have discussions about whether doing the thing is a good idea
20:58:53 <ttx> I'll use the last minute to cover the housekeeping changes
20:58:56 <devananda> mordred: ++
20:58:58 <jeblair> (i wasn't either -- that's not a judgement, just an illustration of why asking and discussing options early is good)
20:59:02 <ttx> #topic Other governance changes
20:59:07 <ttx> * Move DevStack to QA program (https://review.openstack.org/112090)
20:59:09 <mordred> jeblair: ++
20:59:14 <eglynn> jeblair: InfluxDb is pretty new in fairness, but the discussion with the Influx devs started in ATL at the same time as gnocchi
20:59:14 <ttx> It looks like we are hugely in favor, but it needed a rebase last time I looked
20:59:30 <ttx> which was posted... so please reapprove
20:59:38 <ttx> * Add oslo.serialization to Oslo program (https://review.openstack.org/112996)
20:59:43 <ttx> This one now has dhellmann +1 so should be good to go, unless someone objects now
20:59:48 <ttx> * Add oslo.middleware to the Oslo program (https://review.openstack.org/112395)
20:59:54 <ttx> Same for this one, will approve after meeting unless someone objects now
20:59:59 <ttx> * Add repository glance.store to glance (https://review.openstack.org/107585)
21:00:05 <ttx> This one is still missing Glance PTL's +1, markwash is in vacation right now
21:00:10 <ttx> #topic Open discussion
21:00:18 <ttx> And as usual, no time left for open discussion weeee
21:00:45 * ttx could do with a meeting that finishes early
21:00:56 <annegentle> too late :)
21:01:03 * dhellmann invites ttx to the oslo meetings
21:01:24 <ttx> OK, so we'll all see each other on Thursday, 19:00 UTC on #openstack-meeting-3
21:01:27 <markmcclain> well maybe we can try for thursday's to end early :)
21:01:33 <ttx> markmcclain: haha
21:01:38 <ttx> unlikely.
21:01:39 <ttx> #endmeeting