14:01:32 <johnthetubaguy> #startmeeting nova
14:01:32 <openstack> Meeting started Thu Jun 11 14:01:32 2015 UTC and is due to finish in 60 minutes.  The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:34 <ndipanov> yo
14:01:34 <mnestratov> hi all
14:01:36 <openstack> The meeting name has been set to 'nova'
14:01:37 <gilliard> o/
14:01:38 <alaski> o/
14:01:39 <alex_xu> o/
14:01:39 <claudiub> o/
14:01:40 <n0ano> o/
14:01:43 <edleafe> o/
14:01:44 <markus_z> o/
14:01:44 <mnestratov> o/
14:01:45 <dansmith> o/
14:01:46 <andreykurilin> o/
14:01:46 <jlvillal> o/
14:01:46 <bauzas> \o
14:01:52 <jaypipes> o...../
14:01:56 <johnthetubaguy> welcome
14:02:04 <johnthetubaguy> #topic release status
14:02:20 <johnthetubaguy> #info June 12: spec review day
14:02:23 <johnthetubaguy> #info June 23-25: liberty-1 (spec freeze)
14:02:38 <ndipanov> spec freeze or proposal freeze?
14:02:41 <johnthetubaguy> so any questions about our release deadlines?
14:02:43 <johnthetubaguy> freeze
14:02:46 <ndipanov> :(
14:02:48 <ndipanov> jk
14:02:51 <ndipanov> cool
14:03:03 <johnthetubaguy> #link https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule
14:03:12 <johnthetubaguy> so I tried to describe all the dates in the above wiki
14:03:21 <johnthetubaguy> it even talks about exception process
14:03:33 <johnthetubaguy> now its probably wrong or confusing, as its a first draft
14:03:45 <johnthetubaguy> but we can evolve that, so we don't keep making it up each release
14:03:56 <dims_> o/
14:04:20 <johnthetubaguy> so tomorrow is spec review day
14:04:26 <johnthetubaguy> basically we burn down on this
14:04:33 <johnthetubaguy> #link http://russellbryant.net/openstack-stats/nova-specs-openreviews.html
14:04:36 <johnthetubaguy> at least roughly
14:04:55 <johnthetubaguy> so, we have quite a few blueprints to discuss
14:05:08 <johnthetubaguy> I am not sure this meeting is the most efficient way, so ideas on a postcard
14:05:14 <johnthetubaguy> but lets do it this way for now...
14:05:20 <johnthetubaguy> #link https://blueprints.launchpad.net/nova/+spec/virtuozzo-instance-resize-support
14:05:28 <johnthetubaguy> #link https://blueprints.launchpad.net/nova/+spec/virtuozzo-container-boot-from-volume
14:05:36 <johnthetubaguy> #link https://blueprints.launchpad.net/nova/+spec/rename-pcs-to-virtuozzo
14:05:43 <danpb> nb  virtuozzo is the new names for parallels
14:05:51 <johnthetubaguy> now they are all things with a single driver impact
14:05:55 <danpb> so this is about the libvirt parallels support
14:05:56 <johnthetubaguy> danpb: ah, good point, thanks
14:06:11 <mnestratov> most of them are feature parity
14:06:20 <johnthetubaguy> given these are "me too" I say we talk about them in the code review
14:06:22 <johnthetubaguy> any objections with that?
14:06:28 <jaypipes> nope
14:07:10 <danpb> seems fine
14:07:14 <johnthetubaguy> +1s for those happy with it would be good too, btw
14:07:19 <johnthetubaguy> #link https://blueprints.launchpad.net/nova/+spec/ploop-snapshot-support
14:07:24 <johnthetubaguy> this is parallels apparently
14:07:33 <johnthetubaguy> honestly ploop sounded made up, turns out its real
14:07:34 <bauzas> yup
14:07:36 <jaypipes> sounds nasty.
14:07:39 <danpb> yep, ploop is their disk equivalent to qcow2
14:07:52 <johnthetubaguy> I like the honesty of that name
14:08:04 <danpb> so anything nova does with qcow2, they'll need to do some porting work for ploop
14:08:08 <johnthetubaguy> anyways, it seems small, so best reviewed in code?
14:08:20 <johnthetubaguy> danpb: oh, thats going to be messy...
14:08:25 <danpb> the devils in the details, but since its all feature parity stuff its fine in general imho
14:08:38 <johnthetubaguy> danpb: would moving to libvirt storage pools help us here?
14:08:47 <danpb> if the code reviews look like they're getting too messy we can push back to have a spec later i think
14:09:02 <danpb> i don't think we have storage pools support for ploop in libvirt currently
14:09:13 <johnthetubaguy> danpb: do we want to push for that, to keep nova clean?
14:09:53 <danpb> its certainly one option, but i'm loathe to put a dependancy on the storage pools code as its author is no longer working on it
14:10:05 <danpb> so not sure when the storage pools conversion will get done
14:10:35 <johnthetubaguy> danpb: true, I just worry about the long term with that one
14:10:47 <johnthetubaguy> one more...
14:10:50 <johnthetubaguy> #link https://blueprints.launchpad.net/nova/+spec/hyper-v-imagecache-cleanup
14:11:01 <johnthetubaguy> that one looks a little me too, and isolated
14:11:16 <johnthetubaguy> they have a spec, but approving the BP will be quicker
14:11:18 <danpb> johnthetubaguy: yep, that's why i said we should reserve the right to ask for a spec later if the code review turns out to look too messy
14:11:28 <mnestratov> danpb: let us know if anything requiers to pay attention
14:11:40 <mnestratov> danpb: i mean storage pools
14:11:49 <danpb> mnestratov: sure
14:11:58 <johnthetubaguy> danpb: I think we should assume thats always true, we could approve it assuming that, lets come back to that
14:12:03 <alexpilotti> hjohnthetubaguy there’s also a similar one for Hyper-V Fibre Channel support
14:12:12 <johnthetubaguy> alexpilotti: got the link?
14:12:17 <alexpilotti> claudiub: ^
14:12:25 <alexpilotti> johnthetubaguy: sure
14:12:45 <johnthetubaguy> any more spec less blueprint people want to talk about?
14:12:53 <danpb> the hyperv imagecache cleanup looks like a no brainer - presumably its scope is entirely within hyperv anyway
14:12:53 <lpetrut> here's the Hyper-V FC spec https://review.openstack.org/#/c/190107/
14:13:46 <johnthetubaguy> #link https://blueprints.launchpad.net/nova/+spec/hyperv-fibre-channel
14:13:58 <johnthetubaguy> I will see how the spec looks after
14:13:59 <johnthetubaguy> so...
14:14:15 <johnthetubaguy> I will look at these after the meeting, and approve them using my judgement
14:14:28 <johnthetubaguy> if you think i screwed up, let me know, and we can ask for a spec
14:14:47 <johnthetubaguy> if the code review goes south, and its clear we need a spec, lob a -2 on it, and lets talk about getting a spec merge
14:14:55 <johnthetubaguy> does that seem a cool approach?
14:15:12 <johnthetubaguy> any obvious objections around these ones?
14:15:15 <johnthetubaguy> if not, we can move on
14:15:21 <alexpilotti> johnthetubaguy: looks good for us, almost all those BPs are specific to the Hyper-V driver
14:15:46 <johnthetubaguy> OK... moving on
14:15:56 <alexpilotti> falling in the “trivial” category (no API, database, etc impact)
14:16:10 <johnthetubaguy> #topic tracking liberty progress
14:16:19 <johnthetubaguy> #link https://etherpad.openstack.org/p/liberty-nova-priorities-tracking
14:16:35 <johnthetubaguy> #link http://specs.openstack.org/openstack/nova-specs/priorities/liberty-priorities.html
14:16:38 <johnthetubaguy> so we merged the above
14:16:41 <johnthetubaguy> but...
14:17:03 <johnthetubaguy> #action need to work out what specs are need for each priority, owners please update things in: https://etherpad.openstack.org/p/liberty-nova-priorities-tracking
14:17:10 <bauzas> right
14:17:27 <johnthetubaguy> any major updates on priorities before I move on?
14:17:37 <bauzas> so, some changes are on the fly but until we really consider them mergeable, we don't put them in
14:17:57 <johnthetubaguy> bauzas: do create a second list, for stuff the subteam is still looking at
14:18:01 <johnthetubaguy> bauzas: if thats helpful
14:18:06 <bauzas> johnthetubaguy: fair point
14:18:19 <johnthetubaguy> bauzas: particularly for specs that are being debated
14:18:24 <alaski> I created a second list under cells, for visibility
14:18:38 <johnthetubaguy> alaski: yes, thank you for that, was really useful
14:18:48 <bauzas> yup, level down the exigence
14:18:58 <n0ano> we have a wiki for scheduler specs/bps, I can add a link to the priority spec
14:19:05 <bauzas> n0ano: no please
14:19:11 <johnthetubaguy> bauzas: why not?
14:19:17 <n0ano> what johnthetubaguy said
14:19:32 <johnthetubaguy> I mean I would prefer it written in the etherpad, but linking from there is the next best thing
14:19:33 <bauzas> johnthetubaguy: n0ano: because I would like to only have the changes directly, and not go to the wiki
14:19:52 <johnthetubaguy> bauzas: yeah, I will let you argue that in the scheduler meeting if thats OK?
14:19:58 <bauzas> and wiki is not the best for providing quick updates IMO
14:20:00 <bauzas> johnthetubaguy: sure
14:20:03 <johnthetubaguy> its up to the sub team to find what works for them
14:20:25 <johnthetubaguy> I have a preference for the etherpad, but thats just me
14:20:28 <bauzas> (also the wikipage is named Gantt/Liberty ;) )
14:20:28 <n0ano> I think a spec is even harder but we'll talk about it at the net meeting
14:20:38 <bauzas> n0ano: let's discuss that off-topic
14:20:43 <n0ano> +1
14:20:51 <johnthetubaguy> thats cool, its a good debate about process
14:21:02 <johnthetubaguy> I am keen to adopt what works for the sub team
14:21:07 <johnthetubaguy> just be sure to tell us all whats happening
14:21:15 <bauzas> np
14:21:19 <johnthetubaguy> but I am assuming it will be made obvious in the etherpad
14:21:24 <bauzas> +1
14:21:31 <n0ano> fer sur
14:21:33 <bauzas> moving on ?
14:21:34 <johnthetubaguy> cools
14:21:43 <edleafe> bauzas: I renamed that page to Scheduler/Liberty
14:21:55 <johnthetubaguy> #topic stuck spec reviews
14:22:07 <johnthetubaguy> now we might end up talking more about this during the spec review day
14:22:11 <bauzas> edleafe: ack, but I would prefer to keep it in the Nova space :)
14:22:35 <lchen> delete-retired-services - https://blueprints.launchpad.net/nova/+spec/delete-retired-services
14:22:46 <lchen> forgot to add the link to the wiki
14:22:53 <johnthetubaguy> #info some specs are blocked by us not having made a decision on something, when that happens list it at the bottom of here: https://etherpad.openstack.org/p/liberty-nova-priorities-tracking
14:23:10 <bauzas> lchen: that's not a stuck review IMHO
14:23:12 <johnthetubaguy> lchen: lets hold that debate till the end if thats OK?
14:23:24 <johnthetubaguy> so the stuck specs on that list don't all have -1s form me
14:23:34 <lchen> bauzas, johnthetubaguy yep,  thanks!
14:23:38 <johnthetubaguy> they probably should, but I felt bad about it
14:23:52 <johnthetubaguy> basically the list is where we need a general policy debate
14:24:03 <johnthetubaguy> make and agreement, allowing us to move forward
14:24:08 <johnthetubaguy> right now I am just making a list
14:24:21 <johnthetubaguy> an example
14:24:32 <johnthetubaguy> https://review.openstack.org/#/c/169638/9/specs/liberty/approved/selecting-subnet-when-creating-vm.rst,cm
14:24:36 <johnthetubaguy> https://review.openstack.org/#/c/182242/6/specs/liberty/approved/user-controlled-sriov-ports-allocation.rst,cm
14:24:41 <johnthetubaguy> https://review.openstack.org/#/c/187812/3/specs/liberty/approved/add-volume-type-to-create-server-api.rst,cm
14:24:50 <johnthetubaguy> now we said no more proxy apis
14:24:59 <johnthetubaguy> no more pass through apis to cinder and neutron
14:25:07 <johnthetubaguy> ....but we haven't delete those APIs yet either
14:25:23 <johnthetubaguy> we need to sort out that, and decide what we want in the future
14:25:41 <johnthetubaguy> jaypipes: whats your take on these, from the API group point of view?
14:26:31 <johnthetubaguy> OK... so jaypipes has run away
14:26:32 <johnthetubaguy> anyways
14:26:33 <jaypipes> johnthetubaguy: have not had a chance to review. will do so today.
14:26:35 <sdague> honestly, I'd suggest we punt on removing the proxies until next cycle
14:26:48 * jaypipes need to go into windows to get on webex :(
14:26:51 <johnthetubaguy> sdague: so that could well be the correct call
14:26:55 <johnthetubaguy> jaypipes: sad times :(
14:27:10 <johnthetubaguy> so...
14:27:10 <sdague> we could really use some breathing room to do a polish on the the whole API through story, including getting our documentation flowing well
14:27:34 <johnthetubaguy> #action johnthetubaguy to make an ML thread and policy proposal for each of the "stuck" topics early next week
14:27:37 <sdague> there is so much in flight with the API right now, I don't want to add any more big changes in liberty (especially as it's a short cycle)
14:28:02 <johnthetubaguy> sdague: yeah, so thats a good point I think
14:28:06 <neiljerram> johnthetubaguy: THis may not be the place, but I'd like to understand better what you mean by pass-through APIs.
14:28:36 <johnthetubaguy> neiljerram: thats another good point, I try to define that here: http://docs.openstack.org/developer/nova/devref/project_scope.html#no-more-api-proxies
14:28:38 <bauzas> could we consider feature branches as one possible answer to that kind of problems ?
14:28:54 <johnthetubaguy> bauzas: thats just creating merge pain
14:28:55 <bauzas> saying 'for the moment, we don't have them, but we're considering them'
14:29:11 <johnthetubaguy> bauzas: but we could totally make more use of branches for some things, and we should look into
14:29:23 <neiljerram> johnthetubaguy: OK, thanks, I understand now - I'm familiar with the security groups example.
14:29:24 <johnthetubaguy> bauzas: I think its better to say, "please go away for this release, we are full"
14:29:27 <bauzas> johnthetubaguy: agreed, my point is, since we don't this flexibility, it directly collapses with all our efforts to reduce the debt
14:29:39 <johnthetubaguy> neiljerram: yeah, thats where we screwed it up the most
14:30:00 <johnthetubaguy> bauzas: not sure I get that, but we should probably keep moving at this point
14:30:12 <johnthetubaguy> so... basically I am trying to collect areas where we need to make a decision
14:30:20 <johnthetubaguy> then I will propose one for discussion on the ML
14:30:30 <johnthetubaguy> so we can tell these poor spec writers what they should do
14:30:44 <bauzas> johnthetubaguy: nvm, my take is just to say 'that's not possible by now'
14:30:55 <johnthetubaguy> the options are: merge the spec, for this release, go onto the backlog for later, go away its not in scope
14:31:16 <johnthetubaguy> bauzas: yeah, I want folks to not be left in limbo hoping they might just sneak something in though
14:31:31 <johnthetubaguy> bauzas: we used to do that alot, and it was very painful
14:31:37 <johnthetubaguy> mostly for the submitter
14:31:48 <johnthetubaguy> partly for me telling them know in 5 months time
14:31:53 <johnthetubaguy> but anyways, lets move on
14:31:56 <bauzas> agreed
14:32:12 <johnthetubaguy> this is a problem I see, and I have a plan to fix it, help making that list much appreciated
14:32:41 <johnthetubaguy> #topic Bugs
14:32:48 <johnthetubaguy> anyone got a bug thing to discuss
14:32:58 <bauzas> yup
14:33:01 <bauzas> one critical
14:33:24 <bauzas> https://bugs.launchpad.net/nova/+bug/1462424 which I consider non-critical since it's only impacting one driver
14:33:25 <openstack> Launchpad bug 1462424 in OpenStack Compute (nova) "VMware: stable icehouse unable to spawn VM" [Critical,Confirmed]
14:33:39 <bauzas> (and a stable branc)
14:33:52 <johnthetubaguy> yeah, i just made that high
14:33:59 <bauzas> cool, was about to ask
14:34:14 <bauzas> also 33 bugs to triage yet
14:34:17 <markus_z> I try to update the devref with a few thoughts and would appreciate feedback: https://review.openstack.org/#/c/187571
14:34:43 <markus_z> Should end in a "one pager" for bug handling in nova
14:34:50 <bauzas> https://bugs.launchpad.net/nova/+bug/1456228 is also waiting for a nova-core feedback
14:34:51 <openstack> Launchpad bug 1456228 in OpenStack Security Advisory "Trusted vm can be powered on untrusted host" [Undecided,Incomplete]
14:34:57 <johnthetubaguy> markus_z: love the diagram by the way, its nice
14:35:09 <johnthetubaguy> ...so
14:35:14 <johnthetubaguy> this is stuck bugs and critical bugs
14:35:20 <johnthetubaguy> lets not get distracted
14:35:21 <markus_z> johnthetubaguy: thanks
14:35:26 <markus_z> ok
14:35:53 <bauzas> that's it for me about bugs
14:36:01 <johnthetubaguy> any news on the gate
14:36:02 <bauzas> the client has no bugs
14:36:08 <bauzas> I mean no criticals :D
14:36:09 <johnthetubaguy> I assume people would shout if we broke it right now
14:36:21 <johnthetubaguy> #topic Open Discussion
14:36:25 <gilliard> About the gate...
14:36:33 <johnthetubaguy> gilliard: ah, fire away
14:36:46 <gilliard> There was a regression around live migration this week, caught by the multinode job but that's non-voting, because of...
14:36:57 <gilliard> #link https://bugs.launchpad.net/nova/+bug/1462305
14:36:58 <openstack> Launchpad bug 1462305 in OpenStack Compute (nova) "multi-node test causes nova-compute to lockup" [Undecided,Incomplete] - Assigned to Joe Gordon (jogo)
14:37:07 <gilliard> and
14:37:07 <johnthetubaguy> oh thats good one to point out
14:37:08 <gilliard> #link https://bugs.launchpad.net/nova/+bug/1445569
14:37:08 <openstack> Launchpad bug 1445569 in OpenStack Compute (nova) "No dhcp lease after shelve unshelve" [High,Confirmed]
14:37:36 <gilliard> so if anyone can spare any time to see if they have any ideas, it'd be really appreciated.  jogo and I looked at them recently but no progress yet :(
14:37:49 <johnthetubaguy> yeah, slammed right now, but very curious
14:37:55 <johnthetubaguy> gilliard: thanks for those, they are good ones
14:38:08 <johnthetubaguy> #help please look at above two bugs to get the multi host job voting
14:38:18 <gilliard> Thanks.
14:38:28 <johnthetubaguy> #link http://doodle.com/eyzvnawzv86ubtaw
14:38:40 <johnthetubaguy> #info the poll will close right after this meeting, be quick if you missed it
14:38:53 <johnthetubaguy> thats the poll for the preferred meeting time for this meeting
14:38:57 <jlvillal> Just a note.  The Ironic bugs are being slowly worked on.  Appreciate the reviews.  Have got 3-4 fixes merged so far.  We continue to triage and work them.
14:39:21 <johnthetubaguy> jlvillal: are you adding the ready patches to that etherpad, and getting reviews from that?
14:39:35 <jlvillal> johnthetubaguy, Yes we are.
14:39:55 <johnthetubaguy> jlvillal: cools
14:40:06 <jlvillal> johnthetubaguy, And delete them once they have been merged.
14:40:08 <johnthetubaguy> lchen: so you had a blueprint to talk about?
14:40:18 <lchen> johnthetubaguy, yep
14:40:22 <johnthetubaguy> jlvillal: awesome, stuff is moving thats the main thing
14:40:35 <lchen> https://blueprints.launchpad.net/nova/+spec/delete-retired-services
14:40:48 <lchen> johnthetubaguy, Can you please this little nava-manage util enhancement again?
14:41:02 <lchen> Can you please consider this little nava-manage util enhancement again?
14:41:27 <johnthetubaguy> lchen: do we want folks to use the API rather than nova-manage really, I don't quite understand the request
14:41:39 <johnthetubaguy> I mean we want, not do we want
14:41:46 <johnthetubaguy> s/do we/we/
14:42:21 <lchen> johnthetubaguy, this can be helpful in some cases like what I explained in the bp and the code review..
14:42:36 <dansmith> I think we've previously said,
14:42:43 <dansmith> that nova-manage should only be for things we can't do via the API
14:42:48 <johnthetubaguy> dansmith: +1
14:43:11 <lchen> johnthetubaguy, we already have things like list/enable/disable in nova-manage actually
14:43:22 <johnthetubaguy> lchen: so you can setup environment variables for the same user as nova-mange to make it the same?
14:43:48 <johnthetubaguy> lchen: thats some stuff we keep meaning to remove really, there is a spec to fix us that those are broken, where that might get discussed
14:43:57 <dansmith> lchen: those are from before we made it a goal to not add more things to nova-manage
14:44:24 <lchen> johnthetubaguy, dansmith,  ok.
14:44:51 <johnthetubaguy> lchen: I think we need to get people used to using python-novaclient (although thats about to die, but lets ignore that for this moment...)
14:45:00 <lchen> that makes sense.  I will think of other ways to do that
14:45:07 <johnthetubaguy> lchen: Ok, thank you
14:45:18 <lchen> that't alright.
14:45:20 <johnthetubaguy> lchen: help sharing that best practice with folks would really help
14:45:43 <lchen> johnthetubaguy, dansmith, sure.  thanks
14:46:00 <johnthetubaguy> lchen: by which I mean, it would be great if you update the docs so its more obvious about the best way to do that, if you fancy that
14:46:08 <johnthetubaguy> lchen: was there another spec?
14:46:31 <lchen> johnthetubaguy, no,  this is just a specless bp
14:46:53 <johnthetubaguy> cool, np
14:46:59 <johnthetubaguy> any more for any more today?
14:47:16 <johnthetubaguy> request-based-filter-selection
14:47:20 <johnthetubaguy> is on the wiki
14:47:30 <lchen> johnthetubaguy, yeah
14:47:34 <johnthetubaguy> https://blueprints.launchpad.net/nova/+spec/request-based-filter-selection
14:47:35 <lchen> I added it in
14:48:06 <lchen> johnthetubaguy, It's just a simple idea to save some computational cost of the scheduler
14:48:22 <lchen> let me find the link
14:48:38 <bauzas> https://blueprints.launchpad.net/nova/+spec/request-based-filter-selection
14:48:40 <lchen> https://blueprints.launchpad.net/nova/+spec/request-based-filter-selection
14:48:46 <lchen> bauzas, thanks
14:48:53 <bauzas> lchen: I see no changes in the whiteboard
14:49:20 <johnthetubaguy> lchen: so it feels like that needs a spec, just to agree the direction that might affect all current filters and weights
14:49:23 <lchen> bauzas, it's all in the description.
14:49:39 <bauzas> lchen: also, that's part of an action I have to write to explain why amending filt_props needs a spec
14:50:00 <lchen> johnthetubaguy, yep,  np
14:50:25 <lchen> johnthetubaguy,  we can discuss about it after a spec is composed.
14:50:33 <bauzas> lchen: well, I have questions and concerns about your blueprint, so indeed I would love a spec
14:50:35 <lchen> johnthetubaguy, bauzas thanks for the information
14:50:44 <johnthetubaguy> yeah, too many questions, lets do a spec
14:50:45 <sdague> johnthetubaguy: open question about the tree restructure to clean up the v3 bits on disk which confuse folks. What's the best way to get concensus on the final tree structure we should have? I'd like to sort that late this week, early next, then get plouging through that next week
14:50:52 <lchen> johnthetubaguy, bauzas sure
14:51:08 <sdague> mailing list thread, etherpad it, spec?
14:51:14 <edleafe> sdague: discuss on the spec?
14:51:22 <sdague> edleafe: there isn't a spec
14:51:32 <gilliard> #link https://review.openstack.org/#/c/189218/ ?
14:51:46 <sdague> oh, apparently there is one that I never saw :)
14:51:50 <johnthetubaguy> sdague: good question, maybe a spec is a good idea, with an ML point to spot to the spec?
14:51:53 <johnthetubaguy> ah, cool
14:52:00 <edleafe> gilliard: thx - you beat me to it
14:52:15 <johnthetubaguy> lets add this to the API priority etherpad to track it
14:52:20 <sdague> yep
14:52:22 <sdague> ok
14:52:44 <johnthetubaguy> sdague: possibly all of the above then
14:52:57 <johnthetubaguy> sdague: its one of those things we probably want to warn people just before we merge it
14:52:59 <sdague> yeh, sure, I didn't realize edleafe and alex_xu were already running with it
14:53:05 <johnthetubaguy> like the unit test thing
14:53:09 <johnthetubaguy> all good
14:53:14 <johnthetubaguy> so one thing about that
14:53:28 <johnthetubaguy> we probably want to remove the plugin/extension idea at the same time?
14:53:35 <johnthetubaguy> well not remove the idea
14:53:46 <alex_xu> johnthetubaguy: yes, it should be another spec?
14:53:49 <johnthetubaguy> but you know, move it to something else
14:53:55 <edleafe> johnthetubaguy: the capability to load the extensions?
14:54:00 <sdague> yeh, it feels like if we are giving everyone merge conflict hell we should try to do it only once
14:54:00 <johnthetubaguy> alex_xu: its just the path, but yes, thats a different spec
14:54:09 <johnthetubaguy> sdague: exactly my thinking there
14:54:19 <sdague> I'm not convinced it's a different spec
14:54:32 <sdague> I think we want to talk about what we want our api on disk structure to look like eventually
14:54:35 <edleafe> sdague: johnthetubaguy: yeah, the merge conflict problem has been what I've been thinking about the most
14:54:48 <johnthetubaguy> sdague: so the remove all the silly extensions and the mechanism can be separate, but yeah, lets get the path correct first time
14:54:53 <sdague> and it's steps to get there, but we should think about the whole end game
14:54:57 <johnthetubaguy> so its possible the move breaks on the config
14:54:59 <johnthetubaguy> sdague: true
14:55:01 <jlvillal> 5 minutes left
14:55:07 <johnthetubaguy> so we should probably break the config first
14:55:20 <johnthetubaguy> jlvillal: yeah, we are almost done I think
14:55:26 <sdague> johnthetubaguy: right, removing the extension optionality is another spec, but moving things around should be all part of this one
14:55:33 <johnthetubaguy> sdague: +1
14:55:50 <johnthetubaguy> so turns out we are probably all thinking the same thing here
14:55:56 <johnthetubaguy> but we should agree that on the spec
14:56:03 <johnthetubaguy> ...so that means we are done I guess?
14:56:16 * johnthetubaguy waits for tumble weed to go past
14:56:21 <edleafe> +1 to discussing on the spec
14:56:55 <johnthetubaguy> so thanks all, and happy spec review day for tomorrow (ish)
14:57:05 <johnthetubaguy> #endmeeting