15:59:24 <smcginnis> #startmeeting Cinder
15:59:25 <openstack> Meeting started Wed Dec  2 15:59:24 2015 UTC and is due to finish in 60 minutes.  The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:59:28 <openstack> The meeting name has been set to 'cinder'
15:59:55 <flip214> hi
15:59:57 <smcginnis> Meetbot is a little slow today. :)
16:00:03 <eharney> hi
16:00:07 <smcginnis> Courtesy ping: duncant eharney geguileo winston-d e0ne jungleboyj jgriffith thingee smcginnis hemna xyang
16:00:11 <diablo_rojo> hello :)
16:00:22 <egon> morning
16:00:25 <yhayashi> hello
16:00:41 <flip214> perhaps the ping would be better in #openstack-cinder, in case these people are not /JOINed here yet
16:01:04 <smcginnis> flip214: Eh, I'm not going to go searching. :)
16:01:14 <jungleboyj> Howdy!
16:01:19 <xyang2> hi
16:01:30 <geguileo> Hi
16:01:36 <smcginnis> #topic Announcements
16:01:49 <smcginnis> #info python-cinderclient 1.5.0 released
16:02:01 <smcginnis> Got the new client out yesterday. It has the commands for replication.
16:02:24 <smcginnis> #info M-1 milestone to be tagged today or tomorrow
16:02:25 <kmartin> hi
16:02:45 <smcginnis> I'll be getting that in place today. Just need to review the instructions again. :)
16:03:06 <smcginnis> Reminder on our current deadlines:
16:03:12 <smcginnis> #link Deadlines http://lists.openstack.org/pipermail/openstack-dev/2015-November/078215.html
16:03:22 <Swanson> hello
16:03:24 <erlon> anyone here??
16:03:35 <smcginnis> erlon: Seems pretty quiet.
16:03:43 <Swanson> erlon, nope
16:03:44 <smcginnis> I hope we're not having freenode issues again.
16:03:44 <tbarron> hi
16:04:03 <flip214> freenode has a hub gone bust, they said
16:04:11 <flip214> about 15mins ago
16:04:13 <diablo_rojo> smcginnis: I think we are. jgregor and baumann don't see anything in the channel.
16:04:13 <smcginnis> flip214: :{
16:04:20 <flip214> 16:46 [Freenode] -mist(~mrmist@freenode/staff/mist)- [Global-ish notice] Hmm, appears a hub went boom. Services are unavailable whilst we
16:04:23 <scottda> hi
16:04:23 <thingee> o/
16:04:24 <dulek_> smcginnis: We do, from what I see Europe is netsplitted - joining through online IRC client.
16:04:27 <flip214> figure out where it went.
16:04:57 <flip214> never mind, we'll be much faster that way ;)
16:05:00 <egon> only part of europe...
16:05:01 <smcginnis> Well, hopefully the meetbot is up and at least captures this for those that are cut off.
16:05:04 <wanghao> hi, everyone
16:05:18 <Swanson> This is what the meetings will be like after trump builds an irc wall.
16:05:21 <smcginnis> #link https://etherpad.openstack.org/p/mitaka-cinder-spec-review-tracking
16:05:23 * jgriffith joins the *right* side of the split
16:05:41 <smcginnis> Still trying to see if nova's method works for us with that etherpad.
16:05:54 <smcginnis> Added a link to some review stats that might help get some attention to what needs it.
16:06:04 <smcginnis> jgriffith: Come to the dark side.
16:06:08 <smcginnis> :)
16:06:13 <jgriffith> ha
16:06:45 <smcginnis> Another reminder/attention getter for third party CI: http://ci-watch.tintri.com/project?project=cinder&time=7+days
16:06:59 <smcginnis> We'll need to start cracking down on that soon.
16:07:01 <smcginnis> Very soon.
16:07:11 <smcginnis> I know a lot of folks have been having issues lately.
16:07:25 <smcginnis> We need to focus on stablizing that again.
16:07:28 <flip214> smcginnis: looks cool, thanks for the link
16:07:39 <smcginnis> flip214: I hope it helps.
16:07:56 <smcginnis> OK, enough for general annoucnements.
16:07:57 <DuncanT1> Sorry, had some trouble with irc cloud not behaving
16:08:04 <DuncanT1> I'll read the log later
16:08:05 <flip214> yeah, it's like my current overview link via graphite, but also shows other CIs - and that helps.
16:08:07 <smcginnis> DuncanT1: Was just going to check if you made it.
16:08:13 <smcginnis> DuncanT1: looks like freenode issues.
16:08:24 <smcginnis> #topic Removing drivers
16:08:29 <smcginnis> DuncanT1: You're just in time. :)
16:08:59 * bswartz grumbles about freenode and DDOS attacks
16:09:08 <flip214> bswartz: no, hub gone.
16:09:24 <smcginnis> DuncanT1: Still there?
16:09:35 <DuncanT1> Yes
16:09:42 <jungleboyj> Boom!
16:09:44 <DuncanT1> I'm still here, not sure if anybody else is
16:09:57 <smcginnis> DuncanT1: Yeah, hoping things get recorded.
16:09:57 <thingee> present
16:10:03 <smcginnis> DuncanT1: Want to discuss driver removal?
16:10:04 <DuncanT1> Is Jungleboy providing wifi for freenode now too?
16:10:08 <DuncanT1> smcginnis: Sure.
16:10:16 <smcginnis> Ouch. :)
16:10:23 <xyang2> :)
16:10:23 * jungleboyj shakes my fist at DuncanT1
16:10:24 <diablo_rojo> present
16:10:36 <DuncanT1> So we've got / had a few driver removals this cycle
16:10:40 <tbarron> aye aye
16:10:58 <DuncanT1> I'm wondering if we should think about what our policy is for these
16:11:16 <DuncanT1> What about users who're relying on these drivers, etc
16:11:24 <jgriffith> DuncanT1: umm....
16:11:30 <DuncanT1> I don't know any answers, but I'd like to know what other people think
16:11:32 <jgriffith> DuncanT1: we had that discussion at removal time IIRC
16:11:48 <DuncanT1> jgriffith: I don't see it for the Scality one for example
16:11:48 <wanghao> Feel something to be weird:(
16:12:01 <jgriffith> DuncanT1: The consensus was that they should pound on said vendor to get their things running again
16:12:11 <egon> what's on the removal list?
16:12:14 <smcginnis> I think planned removal is one thing. If a vendor doesn't want to be included any more, that's on them.
16:12:15 <jgriffith> DuncanT1: in other words it becomes a market decision
16:12:37 <jgriffith> DuncanT1: are you suggesting we revisit 3'rd party CI in general?
16:12:42 <smcginnis> Removal due to no CI is another. That might not be planned, even though the vendor should know better.
16:12:53 <jgriffith> smcginnis: yeah
16:13:02 <flip214> DuncanT1: don't remove from git, but put in an extra package called -untested or so
16:13:08 <DuncanT1> jgriffith: Ok, if that's what everybody wants, I don't necessarily mind, just wanted people to speak up / spell it out
16:13:18 <smcginnis> DuncanT1: I think it's a fair point.
16:13:20 <jgriffith> DuncanT1: no, not necessarily saying that.
16:13:24 <Erlon_> hi
16:13:29 <jgriffith> DuncanT1: we learn as we go right?
16:13:33 <thingee> we don't need some other package. What's "verified" is what's in driver log today
16:13:42 <jungleboyj> jgriffith: I think you were right.  If the vendor doesn't follow the rules then it is up to them to deal with sad customers.
16:13:44 <jgriffith> DuncanT1: so do we need to revisit some of our past decisions?  Come up with a plan etc
16:14:01 <smcginnis> If we remove a driver and that causes issues for a big user, that reflects poorly on OpenStack, even though it should really be on the vendor.
16:14:05 <thingee> https://www.openstack.org/marketplace/drivers/
16:14:06 <smcginnis> BUt on the other hand...
16:14:11 <thingee> that's it^
16:14:12 * jgriffith is skirting the question of whether the concept is actually working or not
16:14:13 <DuncanT1> jgriffith: I put this in the meeting to start that process I guess.... give people time to think and discuss it at the midcycle maybe?
16:14:24 <smcginnis> We don't want to have to take over maintenance for a vendor that doesn't feel like being involved.
16:14:32 <jgriffith> DuncanT1: seems reasonable
16:14:36 <smcginnis> DuncanT1: Definitely worth a discussion.
16:14:44 <thingee> I don't think there is anything to discuss
16:14:44 <jgriffith> smcginnis: I agree 1000%
16:14:52 <jgriffith> thingee: really?
16:14:52 <flip214> smcginnis: how about a big message in the gui saying "USING UNVERIFIED DRIVER"?
16:14:56 <jgriffith> thingee: interesting
16:14:57 <thingee> smcginnis: if you remove the driver, the driver itself is reflecting poorly on openstack
16:15:00 <thingee> remove it
16:15:05 <bswartz> One problem with driver removals is that customers don't necessarily go to their storage vendor to complain -- sometime they go to their distro to complain
16:15:13 <jgriffith> thingee: yeah, I agree with you on those points
16:15:15 <smcginnis> thingee: I'm saying the removal of it can reflect poorly on openstack.
16:15:26 <flip214> that's why I wouldn't remove.
16:15:26 <thingee> smcginnis: keeping the driver is relecting poorly
16:15:29 <DuncanT1> thingee: A perfectly working driver that a vendor no longer wishes to support is not reflecting badly on openstack....
16:15:40 <smcginnis> thingee: But keeping an unmaintained driver can reflect poorly too.
16:15:40 <jgriffith> thingee: but I have bigger questions regarding whether CI is a failed experiment or not... but that's an independent topic
16:15:54 <smcginnis> thingee: I'm not advocating changing our policy. I actually agree with it.
16:15:54 <flip214> a driver that's kept in-tree can at least get some copy/paste/search+replace maintenance.
16:16:04 <jgriffith> smcginnis: thingee there are two sides to it, both valid IMO
16:16:07 <bswartz> if you're a distro vendor, then it might be annoying to have drivers disappearing upstream
16:16:10 <smcginnis> thingee: But it doesn't hurt to have a discussion to see if there is any way to make things better.
16:16:18 <thingee> again I'm not hearing what people want here. Remove the driver, it's bad either way, just rip the bandaid
16:16:41 <thingee> smcginnis: a discussion on what exactly?
16:16:46 <scottda> I don't want a driver in my distro that is not maintained
16:16:51 <jgriffith> thingee: I don't think anybody is proposing an action, but stating that it might be worth thinking about and discussing at meetup
16:16:52 <thingee> vendor doesn't maintain driver or ci, remove it
16:17:00 <smcginnis> jgriffith: +1
16:17:02 <jgriffith> DuncanT1: smcginnis sound accurate?
16:17:07 <smcginnis> jgriffith: Yep
16:17:19 <flip214> thingee: basically yes, but it impacts users and distros and then openstack too
16:17:38 <thingee> If further discussion is needed around my last sentence, I'm curious why we need to complicate things more.
16:17:44 <DuncanT1> jgriffith: +1
16:17:49 <jungleboyj> jgriffith: ++
16:17:50 <thingee> flip214: a poor driver impacts users and distros
16:17:58 <smcginnis> To be clear, I think an unmaintained driver definitely should be removed. But end users of that driver can get caught in the cross fire. If we can do anything to ease that pain for them, I think it's worth talking about.
16:17:58 <flip214> thingee: a removed driver too
16:18:06 <DuncanT1> thingee: Because removing a working driver affects users too
16:18:13 <jgriffith> thingee: because this isn't a dictatorship, and some feel that the current system isn't really working
16:18:21 <thingee> DuncanT1: you don't know if it's working if you can't verify
16:18:21 <jungleboyj> smcginnis: Agreed!
16:18:24 <thingee> hence ci
16:18:44 <jgriffith> smcginnis: a basement!
16:18:54 <smcginnis> :)
16:18:57 <jgriffith> smcginnis: cinder-basement... where unmaintained drivers go to hibernate
16:18:58 <jgriffith> :)
16:19:09 <thingee> jgriffith: what's wrong with the current system?
16:19:11 <jungleboyj> If there is crossfire they need a bunker.
16:19:12 <jgriffith> honestly I'm more in line with thingee on that subject
16:19:26 <smcginnis> We may discuss and decide nothing needs to change. But talking doesn't hurt anything.
16:19:33 <smcginnis> So let's talk about it at the midcycle.
16:19:34 <jgriffith> thingee: do a query on success/fail rates of the CI's
16:19:37 <thingee> smcginnis: we've had the discussion. again and again
16:19:51 <DuncanT1> thingee: Drivers are being removed (for reasons other than no CI) - anybody using those drivers is screwed. Not a great situation#
16:19:54 <thingee> smcginnis: not sure what magic discussion people are hoping happens.
16:19:59 <flip214> thingee: on the side, I agree with your point, too!
16:20:01 <smcginnis> And if someone doesn't want to waste there time talking, then feel free to not participate.
16:20:10 <jgriffith> DuncanT1: oh... I wasn't aware of that (other than CI)
16:20:19 <jgriffith> smcginnis: +1
16:20:22 <thingee> DuncanT1: they're screwed for us keeping the driver in
16:20:31 <DuncanT1> jgriffith: A vmware one and a scality one this cycle so far
16:20:54 <jgriffith> DuncanT1: not familiar I'm afraid... details on why if it wasn't CI related?
16:20:57 <DuncanT1> thingee: Not until we do something that breaks it. Maybe a deprecation period is possible?
16:21:10 <egon> DuncanT1: +1
16:21:11 <smcginnis> jgriffith: They chose to remove them.
16:21:15 <jgriffith> Oh
16:21:16 <DuncanT1> jgriffith: The vendors asked to remove it in the scality case, dunno about VMWare
16:21:21 <jgriffith> Well that's their business AFAIC
16:21:24 <wanghao> DuncanT1: +1
16:21:42 <jgriffith> That's completely not my problem
16:21:47 <DuncanT1> jgriffith: Vendors are lazy and we don't want them making cinder look bad IMO. Maybe ask for a deprecation cycle?
16:21:50 <thingee> DuncanT1: If said deprecation, I would say place a warning on the driver on start of c-vol
16:21:58 <DuncanT1> thingee: +1
16:22:09 <flip214> thingee: nobody will see that, apart from developers.
16:22:10 <jgriffith> DuncanT1: ok... but are you going to maintain and test VMware and Scality drivers?
16:22:17 <thingee> also not included in driver log for the release.
16:22:22 <flip214> DuncanT1: would only push the problem for 6 months.
16:22:22 <thingee> https://www.openstack.org/marketplace/drivers/
16:22:25 <scottda> But if the vendor wants a driver out, why should we block that?
16:22:37 <scottda> Who will support it?
16:22:45 <DuncanT1> jgriffith: No, but I might say that their other drivers are up foor removal too if they don't maintain it for the deprication cycle, maybe?
16:22:48 <flip214> scottda: if she asks for removal, it *will* be removed. period.
16:23:16 <thingee> scottda: I say let them. even if they want to support it out of tree, they'll have trademark issues.
16:23:21 <DuncanT1> flip214: It gives people time to go shout at the vendor, or change, rather than leaving them cold
16:23:21 <flip214> thingee: what's needed to get on the marketplace list?
16:24:00 <thingee> flip214: good question. hogepodge has been working on the defcore cinder stuff. I imagine that.
16:24:00 <jgriffith> DuncanT1: smcginnis well, I certainly don't have any concerns if a vendor removes their driver.  So I'll butt out on this one, just voice my vote that "I think that's fine"
16:24:01 <egon> and deprecations can be put into release notes, or onto project pages so people *can* see them.
16:24:12 <smcginnis> jgriffith: I agree.
16:24:14 <jgriffith> I can give reasons if somebody wants it, but I don't want to waste air int he room
16:24:23 <thingee> egon: FWIW, we do this today with liberity and kilo
16:24:32 <DuncanT1> jgriffith: Noted. I'm not sure of the best answer, wanted to get people's thoughts.
16:24:33 <smcginnis> I think it just raised the question of whether that's a clean way to do things with no deprecation.
16:24:33 <flip214> thingee: thanks for the pointer, derefencing ;)
16:24:41 <egon> thingee: yes, it's helped with some other projects too
16:24:45 <jgriffith> DuncanT1: very fair, thanks!
16:24:51 <hogepodge> flip214: for cinder drivers? To be a compatible product in the marketplace you need to be passing cinder ci
16:25:15 <smcginnis> DuncanT1: Good to get folks thinking about it at least.
16:25:31 <smcginnis> DuncanT1: Anything else to say on the matter?
16:25:41 <flip214> hogepodge: -> #openstack-cinder
16:25:48 <DuncanT1> smcginnis: Nope, I think I'm done, thanks
16:25:54 <smcginnis> DuncanT1: Thanks!
16:25:54 <thingee> I won't be present at the cinder midcycle sprint to discuss this, but I think the deprecation idea is fine as long as we're no longer promoting the driver
16:26:20 <smcginnis> #topic FalconStor CI Approval
16:26:21 <DuncanT1> thingee: +1
16:26:23 <thingee> and that's the point. for people who are in the "know" to still use the driver
16:26:34 <smcginnis> sidbbt: No need for approval. Did you have a question about it?
16:26:49 <sidbbt> hello there. hopefully i don't get disconnected due to the free node issues. so i can just flip the switch on my CI and start posting comments?
16:26:59 <thingee> sidbbt: yes
16:27:11 <smcginnis> sidbbt: Yes. If you are comfortable that it is stable then please do.
16:27:13 <xyang2> sidbbt: Is this driver for FreeStor?
16:27:20 <sidbbt> should the CI be sending +1/-1 votes? at the moment, i've set it up to send 0 along with the comment
16:27:29 <sidbbt> xyang2: yes it is
16:27:37 <smcginnis> sidbbt: No voting for third party CI for now.
16:27:39 <xyang2> sidbbt: I actually have some concerns about it
16:27:47 <sidbbt> xyang2: how so?
16:28:00 <xyang2> I read something about FreeStor.  It has a SDS controller
16:28:20 <xyang2> sidbbt: in the past, cinder community has rejected similar drivers
16:28:33 <smcginnis> xyang2: Oh, is this another vipr one?
16:28:42 <xyang2> so if we are now open to accept this driver, then we are opening the door for other similar ones
16:28:46 <xyang2> smcginnis: yes
16:28:52 <smcginnis> Well, that will come out in the driver review.
16:28:56 <xyang2> I think so
16:29:01 <smcginnis> As far as CI, no approval needed.
16:29:11 <xyang2> someone knows more can tell me I am wrong
16:29:16 <smcginnis> sidbbt: But know that if it causes problems it will be disabled.
16:29:16 <sidbbt> hmm. i might have to talk to the dev team about the SDS thing. but yeah, basically we're a storage virtualization appliance.
16:29:32 <Erlon_> xyang2: whats the problem with SDS controller storages?
16:29:42 <thingee> sidbbt: so are we :)
16:29:48 <xyang2> sibddt: so it is hardware agnostic.  this means you support many many storage platforms.  that means you need CI for each one of them
16:29:50 <thingee> sidbbt: you can see why this weird
16:29:51 <jgriffith> xyang2: good point.. sidbbt in the past we've rejected abstraction layers within Cinder's abstraction layer
16:30:09 <sidbbt> well, we virtualize the underlying commodity storage and present it as a freestor disk
16:30:14 <DuncanT1> Erlon_: Historically we've asked what the point is.... storage virtualisation is kind of cinder's whole job
16:30:23 <jgriffith> Erlon_: SDS isn't a problem... it's abstractions that do the same thing as Cinder that have been a concern
16:30:28 <smcginnis> sidbbt: Direct attached, or you abstract other storage systems?
16:30:43 <jgriffith> Erlon_: so you have Cinder/Volume/Drivers/ABSTRACTION/Drivers/xxxxxxxxxxx
16:30:53 <Erlon_> jgriffith: hmm
16:30:56 <sidbbt> from cinder's point of view, it's a freestor disk. the scsi inquiry on the disk would return a falconstor identifier. you wouldn't know the underlying physical storage.
16:30:57 <thingee> sidbbt: well, we virtualize the underlying commodity storage and enterprise storage and present it as cinder volume
16:31:03 <thingee> sidbbt: see what I did there?
16:31:20 <xyang2> smcginnis: when we discussed about vipr driver in the past we were asked to provide CI for each storage backend we support
16:31:29 <jgriffith> xyang2: :)
16:31:46 <xyang2> jgriffith: we need to be fair:)
16:31:49 <smcginnis> sidbbt: Direct attached, or you abstract other storage systems? <-
16:31:53 <sidbbt> regarding the CI: i noticed a note somewhere about asking to be added to the third party mail filter list
16:32:42 <thingee> sidbbt: I actually don't remember now what the third party announce list gets used for.
16:32:43 <xyang2> smcginnis: I watched a video about FreeStor, it abstract storage underneath
16:32:44 <sidbbt> smcginnis: i'm not clear on the terminology, but essentially we set in the data path. the storage is connected to our appliance. our appliance carves out virtual devices and presents them to the client using iscsi
16:33:00 <smcginnis> "combines cutting-edge horizontal platform architecture with the ability to leverage new storage options" - well that clears it up. :)
16:33:11 <thingee> sidbbt: sounds like cinder. we do that for things like lvm
16:33:41 <thingee> jgriffith: what came out of your session of allowing things like vipr?
16:34:07 <sidbbt> hmm. so should we go ahead and submit our driver? or should i ask someone higher up on the development team to attend a meeting and discuss the architecture first?
16:34:29 <smcginnis> "allows enterprises to combine existing storage infrastructure with new technology"
16:34:34 <jgriffith> thingee: so the session was more about sticking with the concept of NOT doing that, and figuring out what cinder is/isn't lacking that would make anybody want to go that route
16:34:38 <smcginnis> This does appear to be another vipr
16:34:51 <smcginnis> sidbbt: In that case, I don't think this actually fits.
16:34:57 <jgriffith> thingee: as of yet, I've yet to hear a single "customer" ask for something like this... it's always Vendor driven to push their product
16:35:05 <smcginnis> Weird
16:35:16 <thingee> sidbbt, smcginnis: alright, there you go.
16:35:16 <jgriffith> thingee: I've still yet to receive any feedback regarding an advantage for an end-user
16:35:32 <sidbbt> so the vipr driver wasn't accepted?
16:35:35 <smcginnis> Abstract your abstraction.
16:35:41 <smcginnis> sidbbt: No
16:35:42 <xyang2> sidbbt: correct
16:35:44 <thingee> I don't want to drag this out sidbbt, but I don't think we'd accept the driver.
16:35:45 <jgriffith> thingee: I think it should be available from vendors outside of tree personally
16:35:53 <smcginnis> thingee: I agree.
16:36:06 <sidbbt> ah. so our alternative would be to distribute it though the marketplace?
16:36:08 <smcginnis> jgriffith: Yeah, in this case I do back out of tree. :)
16:36:18 <thingee> sidbbt: no the market place is for apporved drivers.
16:36:24 <jgriffith> sidbbt: no, not marketplace... but in your own github repo or whatever
16:36:36 <jgriffith> smcginnis: hehe... I finally got one!!!!
16:36:44 <smcginnis> jgriffith: ;)
16:36:44 <thingee> jgriffith: :)
16:36:53 <egon> so this would be a case where a vendor needs to integrate to distros
16:37:04 <sidbbt> i see. i guess i'll discuss this with dev/product management. we'll hold off on the driver submission for the moment. this might require further discussion in a future meeting.
16:37:30 <smcginnis> sidbbt: Sounds good.
16:37:41 <smcginnis> OK...
16:37:42 <sidbbt> thank you everyone.
16:37:53 <thingee> sidbbt: we've had this dicussion and in person meetings at the summit about this topic. I think the discussion has been exhausted unless as jgriffith mentioned there being a real use case for this
16:37:57 <smcginnis> Hopefully I can still control the meeting even though it somehow switched back to storyboard.
16:38:07 <smcginnis> #topic Bug Status
16:38:20 <smcginnis> Just fyi...
16:38:30 <smcginnis> #info Cinder bugs: 474
16:38:30 <openstack> bug 474 in Launchpad itself "Translate more than one language simultaneously" [Low,Won't fix] https://launchpad.net/bugs/474
16:38:37 <thingee> heh
16:38:40 <smcginnis> hah
16:38:48 <smcginnis> #info client bugs: 46
16:38:57 <smcginnis> #info os-brick bugs: 17
16:39:13 <smcginnis> And as always, nova volume bugs can use some attention:
16:39:17 <smcginnis> #link https://bugs.launchpad.net/nova/+bugs?field.status:list=NEW&field.tag=volumes
16:39:38 <smcginnis> #topic Open Discussion
16:39:59 <jgriffith> smcginnis: why do they all have to be "hard" bugs :)
16:40:07 <smcginnis> jgriffith: No kidding.
16:40:22 <smcginnis> Although, I do think a lot of them still have been fixed and just not closed.
16:40:24 <jgriffith> smcginnis: as much as I hated the "comment xyz misspelled" at least I could just laugh about them :)
16:40:26 <thingee> wanted to note that the dev list digest is now separate from the newsletter
16:40:29 <thingee> http://www.openstack.org/blog/2015/11/openstack-developer-mailing-list-digest-november-20151121/
16:40:33 <thingee> read it, stay informed
16:40:36 <smcginnis> thingee: +2
16:40:42 <smcginnis> Very useful!
16:40:55 <tbarron> +1
16:41:12 <flip214> I encountered a bug in Nova recently that had already 5 patches on gerrit ... only to then be abandoned
16:41:21 <flip214> I guess because of the repeated whitespace and similar comments
16:41:21 <jgriffith> Wow... third party CI solution is DONE!
16:42:03 <smcginnis> Oh, if anyone wants to be the Cinder cross project liason, I'm fine doing it but also fine handing it off.
16:42:42 <smcginnis> flip214: Death by 1000 paper cuts? :)
16:42:48 <flip214> https://bugs.launchpad.net/nova/+bug/1414802, in case anyone's interested.
16:42:48 <openstack> Launchpad bug 1414802 in OpenStack Compute (nova) "volume-attach "already attached" and "already detached" are not mutually exclusive" [Low,In progress] - Assigned to Vincent Hou (houshengbo)
16:42:51 <flip214> smcginnis: yeah, looks that way
16:43:12 <flip214> Change abandoned by Michael Still (mikal@stillhq.com) on branch: master
16:43:18 <jungleboyj> smcginnis: I was kind-of doing that but it fell off my radar.  Meeting is at a bad time due to family commitments.
16:43:31 <thingee> smcginnis: thanks for reminding me. I'll start hounding projects about electing a cross-project spec liaison
16:43:34 <thingee> http://lists.openstack.org/pipermail/openstack-dev/2015-December/080869.html
16:43:35 <smcginnis> jungleboyj: No worries. Yeah, not the best time.
16:43:57 <thingee> smcginnis: technically I could just do it for cinder ;)
16:44:04 <smcginnis> thingee: :)
16:44:14 <smcginnis> thingee: I do need to spend more time on those specs myself.
16:44:47 <smcginnis> Anything else? Or end early?
16:45:11 <flip214> thingee: so, the DRBD transport
16:45:11 <thingee> smcginnis: it's difficult when also managing your own project. I know we want ptls informed in cross-project, but I think you need someone to bring in a ptl when necessary
16:45:18 <flip214> that should be in Nova and Cinder would have to have a spec in the cross-projects repo?
16:45:18 <smcginnis> OK, thanks everyone.
16:45:18 <smcginnis> #endmeeting