16:00:19 <smcginnis> #startmeeting Cinder
16:00:19 <openstack> Meeting started Wed Nov 11 16:00:19 2015 UTC and is due to finish in 60 minutes.  The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:23 <openstack> The meeting name has been set to 'cinder'
16:00:28 <mriedem> o/
16:00:31 <jseiler> hi
16:00:33 * DuncanT waves
16:00:35 <scottda> hi
16:00:35 <diablo_rojo> Hello :)
16:00:39 <jgregor> Hello!
16:00:40 <tbarron> hi
16:00:42 <xyang1> hi
16:00:42 <ntpttr1> Hi
16:00:50 <abhi> hi
16:01:00 <e0ne> hi
16:01:17 <rhedlind-m> hi
16:01:24 <smcginnis> Hey everyone.
16:01:27 <baumann> Hello!
16:01:31 <flip214> hi
16:01:42 <e0ne> #link https://wiki.openstack.org/wiki/CinderMeetings#Next_meeting
16:01:43 <smcginnis> No announcements. Let's get right to it.
16:01:43 <jgriffith> 0/
16:01:49 <smcginnis> #topic cinder-api-microversions
16:01:53 <smcginnis> scottda: Hey
16:01:57 <scottda> hi
16:02:15 <scottda> Xing pointed out some things about API microversions spec
16:02:17 <scottda> https://review.openstack.org/#/c/223803/9
16:02:25 <scottda> That were encountered by Manila
16:02:36 <scottda> 1) API extensions cannot be versioned
16:02:51 <scottda> Manila moved API extensions into core so they can be versioned
16:03:14 <scottda> I'd like to but something in the spec for this, but do the work separately.
16:03:14 <smcginnis> If I remember right, there was some discussion at the kilo midcycle about pulling API extensions in to core.
16:03:26 <scottda> smcginnis: Yes
16:03:39 <e0ne> IMO, I'm OK with moving excentions to core, but we need to take care about backward compatibility
16:03:47 <scottda> I don't know if anyone wants to drive that? or if it is controversial?
16:03:54 <smcginnis> scottda: And that's fine to do it as a follow up IMO. We only need them moved once we want to microversion them, right?
16:03:55 <DuncanT> e0ne: +1
16:04:07 <scottda> smcginnis: Yes.
16:04:11 * bswartz creeps in late
16:04:13 <e0ne> we must follow deprecation policy for APIs
16:04:16 <DuncanT> smcginnis: Ideally, the otehr way round
16:04:24 <smcginnis> bswartz: We see you! :)
16:04:31 <smcginnis> DuncanT: How so?
16:04:37 <DuncanT> e0ne: Or just redirect the URLs so that they keep working
16:04:52 <smcginnis> DuncanT: I think that's what manila did.?
16:05:05 <e0ne> DuncanT: agree, it's a simple and usable solution
16:05:10 <DuncanT> smcginnis: Ideally you want extensions (which in our case include very core stuff) in your initial API version
16:05:24 <bswartz> yeah in manila we moved our extensions to make them core APIs -- we used redirects to avoid breaking anything existing
16:05:42 <scottda> So should this be done before/at_the_same_time/after api-microversions?
16:05:43 <DuncanT> smcginnis: Otherwise, your first API contract isn't enough to actually use the service
16:05:46 <smcginnis> bswartz: Did that need to be done before microversions were introduced?
16:05:54 <smcginnis> bswartz: I thought I saw Valeriy just do that.
16:05:56 <bswartz> no, definitely after
16:06:11 <jgriffith> scottda: before IMO
16:06:11 <bswartz> get microversions merged and working first, then tackle the extensions
16:06:15 <jgriffith> haha
16:06:22 * jgriffith is apparantly wrong
16:06:30 <bswartz> that way you can microversion the extension rename
16:06:43 <smcginnis> Isn't 2.0 our first API contract? So as it is now should be fine, then we need to redirect once we want to have a 2.1.
16:06:44 * DuncanT is with jgriffith
16:06:50 <xyang1> bswartz: i think we are moving all extentions to core first, after they are merged, rename and change microversion
16:06:55 <jgriffith> bswartz: smcginnis I guess my thought was more of the "same time"
16:07:05 <bswartz> we force people who use newer microversions to call the new URLs paths -- if they use the old paths with a new microversion they get 404
16:07:30 <smcginnis> bswartz: That makes sense to me.
16:07:30 <bswartz> it's our way of encouraging application writers to stay current with the API
16:07:36 <smcginnis> +1
16:07:56 <scottda> And if they use old paths with no microversion, everything works
16:08:11 <bswartz> of course anyone sticking with an older microversion (or no microversion at all) will not break
16:08:18 <smcginnis> scottda: I thought that is why it would need to be after introducing microversions.
16:08:19 <scottda> So, I think the move of API extensions can occur after microversions lands.
16:08:28 <DuncanT> What do we do with API changes to extensions in the mean time (e.g. backing up snapshots)?
16:08:36 <jungleboyj> o/  Sorry I am late.
16:08:43 <scottda> DuncanT: you wait for microversions to land
16:08:47 * smcginnis marks jungleboyj tardy
16:08:50 <scottda> and then move the extensions
16:08:58 <scottda> and then land backing up snapshots
16:09:08 <jgriffith> scottda: that seems kinda risky... but I guess it forces the issue
16:09:13 <jgriffith> scottda: no pressure
16:09:17 <scottda> hehe
16:09:39 <scottda> I'm seeing lots of reviews on API changes that say "this should come after microversions" anyway
16:09:43 <scottda> which makes sense
16:09:55 <scottda> So, let's land the spec and move to the code reviews....
16:10:05 <scottda> and thus this conversation.
16:10:08 <xyang1> actually I am not sure if it makes a difference, the extension does not have version now anyway
16:10:23 <scottda> So, I'll update the spec to do extension move later, but probably soon....
16:10:29 <xyang1> scottda: I am saying it doesn't have to wait
16:10:41 <smcginnis> xyang1: That was what I thought.
16:10:44 <scottda> OK, I *think* we are on the same page
16:10:55 <scottda> issue #2:
16:11:11 <scottda> Use of the microversion "latest" can cause problems, and did in Manila
16:11:18 <smcginnis> #info Need to land microversions, then move extensions
16:11:33 <scottda> But, I think we (and Nova) need "latest" to properly run Tempest tests...
16:11:39 <bswartz> scottda: that's not accurate
16:11:41 <scottda> This was discussed at the Tokyo Summit
16:12:03 <scottda> bswartz: OK, but you (Manila) do not have Tempest tests in-tree
16:12:07 <jgriffith> scottda: bswartz isn't "no version" == latest ?
16:12:15 <bswartz> in my mail thread I stated that using microversion "latest" results in inherently undefined behaviour, and a user should never do it
16:12:25 <bswartz> however for nova, they needed it because their tests were out of tree
16:12:27 <scottda> jgriffith: no
16:12:35 <bswartz> cinder may need it for a similar reason
16:12:43 <DuncanT> jgriffith: no version = 2.0
16:12:43 <scottda> jgriffith: "no version" is lowest supported version, i.e. 2.0
16:12:43 <smcginnis> jgriffith: no version == oldest (aka 2.0)
16:12:50 <bswartz> "latest" makes sense as a hack to make tests work
16:12:52 <scottda> latest is highest version
16:12:55 <jgriffith> :)
16:13:06 <smcginnis> bswartz: So the issue is "latest" is kind of a moving target?
16:13:06 <DuncanT> But how can you write tests against an unknown version?
16:13:20 <scottda> bswartz: Yes, so we need latest, and cannot do what Manila did because of Tempest, just like NOva
16:13:46 <DuncanT> scottda: I'm not sure why the tests need 'lastest'
16:13:58 <DuncanT> scottda: It is fundamentally an undefined target
16:14:18 <bswartz> "latest" means what it sounds like -- you don't know what you're going to get -- but when testing it can get you out of jail
16:14:57 <bswartz> the issue with keeping your tests in a separate git repo is that it's hard to add a new microversion and add tests for it at the same time
16:15:02 <scottda> I'm not positive on why the Tempest team wants or needs "latest", it is either a "must have" or a "very hard not to have"
16:15:46 <e0ne> scottda: +1. why does tempes require "latest"?
16:15:51 <smcginnis> Not to add more work and confusion - but wasn't there some talk of moving our tempest tests in-tree?
16:16:08 <bswartz> +1 for moving some tests in tree
16:16:13 <jgriffith> smcginnis: that would only be "some", but not all
16:16:19 <scottda> e0ne: I'll have to get the details...I don't recall right now.
16:16:31 <jgriffith> smcginnis: perhaps the ones that are affected by "new/latest" makes sense
16:16:31 <bswartz> tests that only test cinder should absolutely be in tree -- tests that test integration between cinder and other things should probably remain in tempest
16:16:35 <scottda> mriedem: Do you know why Nova/cinder Tempest for microversions needs lates?
16:16:36 <smcginnis> jgriffith: Ah, OK. So base level cinder functionality remains in tempest, then enhanced coverage in cinder?
16:16:38 <DuncanT> You can as cinder what its latest supported version is, and surely tests need to target a known version?
16:16:41 <smcginnis> jgriffith: +1
16:16:47 <jgriffith> smcginnis: just an idea
16:16:55 <smcginnis> jgriffith: One that makes sense.
16:16:59 <mriedem> lates?
16:17:13 <scottda> microversion= "latest"
16:17:14 <mriedem> oh, latest
16:17:28 <mriedem> did tempest land the microversion testing yet?
16:17:35 <mriedem> i think tempest was going to test lower bound and latest
16:17:43 <mriedem> just so there is bounds testing
16:17:44 <bswartz> my thread on "latest" microversion:
16:17:46 <bswartz> #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/073070.html
16:17:51 <mriedem> yeah i know about that
16:17:55 <mriedem> and we hit latest issues with novaclient
16:18:05 <mriedem> as in defaulting to latest for novaclient was a bad idea when the client didn't support latest
16:18:47 <scottda> mriedem: Yes
16:18:54 <scottda> to bounds checking
16:19:04 <mriedem> but it still seems like that's not going to work
16:19:14 <mriedem> in novaclient we cap the upper limit on what we know the client to support at that time
16:19:21 <mriedem> as the client adds new support, we raise that limit
16:19:27 <mriedem> i'd think tempest would have to do the same
16:19:28 <scottda> And that works for Tempest testing?
16:19:41 <mriedem> b/c if nova renames an API in v2.20 and tempest isn't ready, it will explode
16:19:46 <scottda> ok, I'll investigate further and update the spec when I'm certain of Tempest needs
16:19:48 <mriedem> i don't think tempest has nova microversion testing yet
16:19:56 <mriedem> k'inichi was working on it i tink
16:19:58 <mriedem> *think
16:20:01 <mriedem> mtreinish: ^
16:20:02 <scottda> mriedem: I don't think so either
16:20:04 <jgriffith> scottda: not sure how else you would do it?  I mean... why wouldn't your tests consume the API the same as your users?
16:20:08 <scottda> But it is being worked on
16:20:24 <mriedem> jgriffith: useres aren't supposed to ask for 2.latest
16:20:28 <scottda> I'll get some details and put them in the spec....
16:20:32 <mriedem> they are support to opt-in to what they can handle
16:20:33 <jgriffith> mriedem: no, that's my point
16:20:41 <scottda> don't want to rathole on this further, agenda for today is long
16:20:42 <mriedem> ok, yeah
16:20:54 <jgriffith> mriedem: IMO the tempest tests should just "work" as they do now, default to lowest version
16:20:56 <mriedem> nova specifically put in it's rest api docs that 2.latest is a thing but don't use it
16:21:08 <jgriffith> mriedem: if tempest wants to test a new version (micro-version or whatever) that's explicit
16:21:19 <mriedem> yeah, i think that's the idea
16:21:21 <jgriffith> mriedem: we don't do the "latest" strategy at all
16:21:35 <mriedem> test lower bound and 'interesting points' in between as sdague says
16:21:39 <scottda> OK. Thanks, I'll verify the latest issue and update the spec
16:21:47 <jgriffith> mriedem: yes.. that sounds right
16:21:48 <scottda> Thanks. Ok to move on.
16:22:03 <smcginnis> jgriffith: That makes sense to me.
16:22:10 <smcginnis> scottda: OK, thanks!
16:22:11 <e0ne> jgriffith: +1. tempest should work in same way as other API clients
16:22:25 <smcginnis> My parts should be quick, so the agenda isn't really as bad as it looks.
16:22:37 <smcginnis> #topic Spec status
16:23:05 <smcginnis> After being prodded several times by scottda, I've put up an etherpad to start tracking specs. :)
16:23:12 <scottda> :)
16:23:15 <smcginnis> This is something nova does regularly in their meetings.
16:23:34 <smcginnis> So not much to it right now, but the idea is if we stick to it, it will help in the long run.
16:23:41 <smcginnis> #link https://etherpad.openstack.org/p/mitaka-cinder-spec-review-tracking
16:23:57 <smcginnis> #info Start tracking specs in etherpad.
16:24:17 <smcginnis> There's also a link to all our open specs in the meeting agenda.
16:24:30 <jgriffith> smcginnis: cool
16:24:37 <smcginnis> It would be good to get those reviewed earlier in the cycle so we don't have a crunch at the end.
16:24:51 <e0ne> smcginnis: good idea, +2
16:24:53 <smcginnis> So please do if you have the cycles. :)
16:25:06 <smcginnis> #topic Bug Status
16:25:23 <smcginnis> Another nova suggestion. And probably a good one to get visibility.
16:25:43 <smcginnis> I'm working on some scripts to make this easier to get using some existing infra scripts.
16:25:58 <smcginnis> But for now I've put a few numbers as of last night into the agenda.
16:26:14 <smcginnis> Bottom line - we have a ton of bugs out there and they could probably use some attention.
16:26:26 <e0ne> smcginnis: what about to announce bug triage day on regular basis?
16:26:28 <smcginnis> We have several that have been out there for quite some time.
16:26:44 <smcginnis> e0ne: We can try. I do like the idea.
16:26:58 <smcginnis> I think the last few times we've tried that it kind of fizzled.
16:27:02 <smcginnis> But I would be up for it.
16:27:16 <e0ne> smcginnis: I can send e-mail like I did in the past
16:27:28 <smcginnis> e0ne: +1 Awesome, that would be great.
16:27:30 <e0ne> sending e-mail costs almost nothing
16:27:49 <smcginnis> I have a feeling a lot of them (especially from 2013) can probably just be closed at this point.
16:28:01 <kmartin> smcginnis, did you run the query to auto close bugs > then N years?
16:28:01 <smcginnis> But it would be good to validate that.
16:28:09 <smcginnis> kmartin: I did.
16:28:30 <smcginnis> Anything that didn't have any activity older than 1-1-2015 I think I closed.
16:28:43 <smcginnis> If there was activity (in-progress, etc) I left it alone.
16:29:07 <smcginnis> I'm sure there was probably something in that set of bugs that is still legitimate, so a bit of a risk.
16:29:13 <e0ne> in-progress have to be cleaned too
16:29:42 <smcginnis> But it seemed a little too unmanagable at 700+ open bugs, and if it was out there that long there's a good chance it either didn't matter or was fixed by other changes.
16:29:47 <e0ne> >2-3 month in-progress means it is not really in progress
16:29:49 <smcginnis> e0ne: Yeah, probably.
16:29:58 <jgriffith> hehe
16:29:59 <smcginnis> I was being conservative to start.
16:30:22 <sdague> (sorry, it's late, from the ping, but https://review.openstack.org/#/c/169126/ explains the testing strategy for microversions from tempest)
16:30:30 <smcginnis> sdague: Thanks!
16:30:38 <scottda> sdague: thanks
16:31:13 <smcginnis> While we're on the topic, I'll also take this opportunity to state that changing comment text or refactoring code most likely is not a "bug".
16:31:32 <smcginnis> So please don't file bugs just to close them with trivial patches.
16:31:38 <e0ne> smcginnis: +1
16:31:54 <smcginnis> I think bugs are only valuable if they actually document an issue in the code that could affect someone.
16:32:06 <tbarron> ++
16:32:14 <e0ne> and don't -1 to ask to file a such bug
16:32:17 <xyang1> smcginnis: refactoring a driver could be thousands of lines of code
16:32:21 <smcginnis> +111
16:32:33 <xyang1> smcginnis: you sure you don't want to track that
16:32:45 <smcginnis> xyang1: Then that sounds more like a bp to me.
16:32:51 <xyang1> smcginnis: yes
16:32:52 <DuncanT> xyang1: A good refactor is a bunch of patches that move a bit each
16:32:59 <smcginnis> xyang1: If the driver works before and the driver works after then there wasn't really a bug there.
16:33:08 <smcginnis> But a bp would be good for tracking if it's significant.
16:33:15 <DuncanT> xyang1: Multi-thousand line patches are not reviewable, so not acceptable IMO
16:33:23 <smcginnis> DuncanT: No several thousand line code changes? :)
16:33:30 <e0ne> DuncanT: +1
16:33:32 <xyang1> :)
16:33:42 <smcginnis> Only with donuts. :)
16:33:57 <e0ne> only removig several thousand LoC is good:)
16:34:05 <smcginnis> e0ne: Yes!
16:34:09 <tbarron> :)
16:34:18 <DuncanT> e0ne: rm -rf cinder; git commit -am "All bug removed"
16:34:30 <flip214> DuncanT: only very few features left, too.
16:34:33 <smcginnis> DuncanT: Some may upvote that. ;)
16:34:34 <xyang1> refactoring means thousands are removed and thousand are added
16:34:37 <e0ne> DuncanT: -1, please add Closes-Bug
16:34:38 * bswartz points out that simply renaming a file with 500 lines counts as a 1000 line patch
16:34:54 <flip214> bswartz: depends on your git config.
16:34:55 <jungleboyj> Coffee and donuts.  Right xyang1 ?
16:34:57 <xyang1> bs+1
16:35:07 <smcginnis> Anyway...
16:35:08 <xyang1> jungleboyj: yes, if it works:)
16:35:12 <smcginnis> #topic Go forward with use-cinder-without-nova blueprint
16:35:15 <smcginnis> e0ne: Hi
16:35:21 <e0ne> hi
16:35:46 <xyang1> bswartz: sorry, I mean your comment
16:35:47 <smcginnis> #link https://review.openstack.org/#/c/224124/
16:35:56 <e0ne> I want to contibue our session at Summit and deside that we are on the same page
16:36:37 <e0ne> and, of course get more and more feedback on it
16:37:11 <e0ne> the main question is
16:37:31 <e0ne> what should we as community do to make it a part of cinder?
16:38:18 <e0ne> it==python-brickclient
16:38:44 <smcginnis> Sorry, I have it in my list to get back to.
16:38:49 <DuncanT> IMO yes, it needs to make it into gate eventually, or it /will/ break
16:38:58 <smcginnis> It looked like it was on the right track last time I looked.
16:39:04 <smcginnis> DuncanT: Agree
16:39:05 <DuncanT> Even none-voting is better than nothing
16:39:27 <e0ne> DuncanT: that's why we need to move it from my github to openstack
16:39:45 <DuncanT> e0ne: +1
16:40:14 <e0ne> DuncanT: because even if it will have tests, w/o it's nothing
16:40:32 <smcginnis> Anyone against having this added as an offical project?
16:40:40 <e0ne> not me:)
16:40:45 <smcginnis> e0ne: ;)
16:40:52 <e0ne> https://review.openstack.org/#/c/243080/ - Add python-brickclient to OpenStack
16:41:18 <smcginnis> #link https://review.openstack.org/#/c/243080/
16:41:26 <smcginnis> Any concerns, vote there. ^^
16:41:54 <e0ne> jgriffith has a consern about it
16:41:58 <xyang1> a sub-project under cinder?
16:42:05 <e0ne> xyang1: yes
16:42:13 <smcginnis> Like python-cinderclient.
16:42:15 <jungleboyj> e0ne: ++
16:42:23 <jgriffith> e0ne: yeah, maybe I'm missing something
16:42:51 <jgriffith> e0ne: not following exactly why we'd do that... instead of having say cinderclient consume brick as a lib (like libs usually work)
16:42:52 <e0ne> we can do it inside cinderclient, but I don's want to confuse anyone more with one more 'attach' api.
16:43:03 <e0ne> even if it will have other binary name
16:43:11 <jgriffith> e0ne: ahh... yeah, that makes sense
16:43:14 <jgriffith> e0ne: but
16:43:17 <DuncanT> e0ne: +1
16:43:17 <smcginnis> I think the discussion was to have a separate client to avoid confusion.
16:43:24 <jgriffith> e0ne: why couldn't we just have a config option and do that?
16:43:39 <jgriffith> e0ne: so use the same method we have today to talk with Cinder and get things like policy etc?
16:43:45 <e0ne> jgriffith: I'm not fun of config for clients
16:43:59 <jgriffith> e0ne: that way that command never even shows up if it's not enabled via policy
16:44:25 <jgriffith> e0ne: well it doesn't have to be config
16:44:34 <smcginnis> jgriffith: Could you explain a little how that works?
16:44:55 <e0ne> jgriffith: how can we handle optional requirements for cinderclient?
16:44:58 <jgriffith> e0ne: but honestly that seems WAYYY better to me than building all the framework for a brick client when brick was supposedly just a lib
16:45:18 <jgriffith> e0ne: smcginnis if you have it disabled in policy file it won't be exposed IIRC
16:45:29 <jgriffith> e0ne: smcginnis I can look into that
16:45:34 <DuncanT> jgriffith: But it uses the same calls as nova....
16:45:54 <jgriffith> DuncanT: those are compute-extensions, we don't expose them currently
16:45:59 <smcginnis> I do like the idea of not duplicating code to have a separate client.
16:46:06 <jgriffith> DuncanT: if you do a "cinder help" you don't see them currently
16:46:09 <e0ne> DuncanT, jgriffith: keystone trusts could help us for this
16:47:28 <jungleboyj> smcginnis: You do like duplicating code?
16:47:51 <smcginnis> jungleboyj: NOT duplicating code! :P
16:47:58 <mtanino> +1
16:48:01 <e0ne> "cinder attach" via CLI and python API will be different
16:48:17 <e0ne> it's a not user friendly at all
16:48:22 <jungleboyj> smcginnis: :-)  Just making sure.
16:48:27 <e0ne> openstack-baseclient? :)
16:48:46 <jungleboyj> smcginnis: Oh, you did have a 'not' in there.  My bad.
16:48:50 * jungleboyj can't read today
16:49:12 <e0ne> IMO, code duplication is the other issue wich should be fixed separatly
16:49:20 <smcginnis> jungleboyj: http://www.zennioptical.com/
16:49:32 <smcginnis> jungleboyj: :)
16:49:52 <e0ne> info: we've got only 5 minutes more for this topic
16:49:55 <e0ne> or less
16:50:20 <smcginnis> My 2 cents - I think we need this functionality. We just shouldn't impose confusion or difficulty for our "main" cinder consumers.
16:50:30 <jgriffith> smcginnis: agreed
16:50:40 <jungleboyj> smcginnis: +1
16:50:45 <jgriffith> smcginnis: and IMO having multiple clients would do just that :)
16:50:53 <smcginnis> If that means a separate client, great. If we have a clean way of doing it without a separate client - awesome.
16:50:57 <e0ne> smcginnis: +1
16:51:02 <xyang1> smcginnis: +1
16:51:04 <jgriffith> smcginnis: so I have to use cinderclient to create etc
16:51:14 <jgriffith> smcginnis: then jump over to this 'brick' thing to attach
16:51:23 <jgriffith> blah
16:51:36 <smcginnis> jgriffith: I think the idea was both pieces of functionality would be in the new client.
16:51:40 <smcginnis> So there would be some overlap.
16:51:45 <smcginnis> But I could be wrong.
16:52:00 <jgriffith> smcginnis: so that's cool... but like I said in the review; that's probably the right answer but it should be in the cinderclient
16:52:04 <jgriffith> smcginnis: not the other way around
16:52:20 <jgriffith> at least I think so
16:52:21 <jgriffith> anyway
16:52:28 <jgriffith> I'll look again
16:52:32 <smcginnis> jgriffith: Very fair point.
16:52:33 <jgriffith> no need to take up time here
16:52:41 <smcginnis> e0ne: Good enough for now?
16:52:45 <e0ne> yes
16:52:51 <smcginnis> e0ne: Thanks!
16:53:03 <smcginnis> #topic Mid-cycle survey results
16:53:08 <smcginnis> Drumroll...
16:53:09 <e0ne> smcginnis: I'll wait your and jgriffith's comments in the review
16:53:28 <smcginnis> DuncanT: How did things turn out?
16:53:43 <DuncanT> Ok
16:53:47 <kmartin> paging DuncanT
16:54:11 <Swanson> Survey results were "Ok"?  Not a detailed survey?
16:54:22 <e0ne> :)
16:54:27 <DuncanT> 25th - 29th won by a fair bit.
16:54:27 <DuncanT> 25th - 29th won by a fair bit.
16:54:27 <smcginnis> :D
16:54:28 <scottda> c'mon Drama King, out with it!
16:54:35 <kmartin> lol
16:54:36 <DuncanT> Sorry, connection issues
16:54:46 <smcginnis> DuncanT: OK, overlap with nova, but that's not a huge deal.
16:55:02 <smcginnis> No air raids during Cinder meetings please.
16:55:10 <jgriffith> LOL
16:56:03 <smcginnis> DuncanT: Did we lose you again?
16:56:16 <diablo_rojo> the silence is killing me
16:56:18 <scottda> https://www.irccloud.com/pastebin/xv2c1tKP/
16:56:24 <smcginnis> He;s just building suspense.
16:56:25 <scottda> From DuncanT ^^^
16:56:40 <jungleboyj> I CAN'T TAKE IT!
16:56:44 <scottda> https://www.irccloud.com/pastebin/3LpS8zyW/
16:56:50 <smcginnis> Dublin and Raleigh near neck -and -neck, but 15 couldn't make Dublin .v. 1 who
16:56:53 <smcginnis> can't make the US.
16:57:03 <smcginnis> Internet pastebin chat - IPC
16:57:36 <hemna> sorry I missed the meeting.   I forgot it was at 8am, not 9am.  :(
16:57:45 <smcginnis> tbarron: Does hosting still work for you?
16:57:46 <scottda> That's all I've got from DuncanT ^^
16:57:59 <DuncanT> Thanks, Scott
16:58:12 <smcginnis> DuncanT: Yay, he's back!
16:58:15 <DuncanT> I think that covers it
16:58:34 <smcginnis> DuncanT: So week of the 25th, Raleigh or Dublin, but Dublin would be a few less attendees?
16:58:40 <DuncanT> Yup
16:58:46 <flip214> then lets take Dublin ;)
16:58:51 <DuncanT> 15 less according to the servey
16:59:22 <tbarron> smcginnis: sure,
16:59:23 <hemna> oh survey results ?
16:59:31 <bswartz> Dublin would be better in the summer than the winter IMO
16:59:37 <DuncanT> bswartz: +1
16:59:39 * eharney forgot about the time change, hi everyone
16:59:41 <smcginnis> bswartz: Yeah
16:59:52 <hemna> eharney, you aren't the only one.
16:59:55 <tbarron> smcginnis: sorry, am doing two meetings at once
16:59:56 <smcginnis> hemna: At least you beat eharney. ;)
17:00:02 <scottda> out of time
17:00:02 <hemna> smcginnis, yeah!!!!
17:00:10 <DuncanT> My big take-out from this is that a non-US midcycle is probably coming, but best do that for summer, not now
17:00:14 <smcginnis> Follow up later.
17:00:18 <smcginnis> Thanks everyone.
17:00:22 <jungleboyj> DuncanT: ++
17:00:24 <smcginnis> #endmeeting