16:01:00 <eglute> #startmeeting defcore
16:01:03 <openstack> Meeting started Wed Nov 16 16:01:00 2016 UTC and is due to finish in 60 minutes.  The chair is eglute. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:06 <markvoelker> o/
16:01:07 <openstack> The meeting name has been set to 'defcore'
16:01:11 <catherine_d|1> o/
16:01:13 <shamail> o/
16:01:13 <eglute> #chair markvoelker
16:01:14 <openstack> Current chairs: eglute markvoelker
16:01:17 <hogepodge> o/ (from SuperComputing 16)
16:01:22 <eglute> #chair hogepodge
16:01:23 <openstack> Current chairs: eglute hogepodge markvoelker
16:01:32 <eglute> Hello Everyone!
16:01:37 <eglute> #topic agenda
16:01:52 <eglute> please review the agenda for today: #link https://etherpad.openstack.org/p/DefCoreRoble.3
16:02:31 <eglute> #topic meeting time
16:03:02 <GheRivero> o/
16:03:07 <eglute> with all the travel, conferences and time changes, we missed a couple last meetings. With the time change, does this time still work for everyone?
16:03:19 <markvoelker> This timeslot continues to be fine for me.
16:03:31 <eglute> works for me as well :)
16:03:43 <markvoelker> And FWIW, I plan on being available next week--leaving for Thanksgiving almost right after this meeting though. =)
16:03:50 <hogepodge> works for me
16:03:54 <shamail> +1
16:04:00 <gema> o/
16:04:10 <catherine_d|1> I would prefer it to be one hour later ... but will try to attend at the current time
16:04:33 <hogepodge> Same for me on American Thanksgiving holiday, despite my travel unavailability over the last month. I need a holiday.
16:04:59 <gema> being thanksgiving next week maybe we should cancel and discuss the time for the week after
16:05:05 <eglute> catherine_d|1 noted about one hour later... lets see what others say
16:05:25 <eglute> gema good suggestion
16:05:31 <catherine_d|1> eglute: thank you
16:06:12 <gema> one hour later works for me also probably better
16:06:14 <eglute> i can be around next week, but seems like some will be out.
16:06:20 <eglute> gema noted!
16:06:36 <markvoelker> An hour later would actually be challenging for me...
16:06:58 <eglute> #action discuss meeting time change after next week
16:07:09 <eglute> markvoelker we need you at this meeting, so lets see how things look in a couple weeks
16:07:15 <hogepodge> I prefer to keep the UTC time, since changing it twice a year is a pain.
16:07:23 <eglute> hogepodge agreed..
16:07:27 <hogepodge> Most projects don't move their meeting time from what I understand.
16:07:56 <dmellado> o/
16:08:06 <eglute> ok... so just to get consensus on next week
16:08:16 <eglute> +1 if we should cancel next week
16:08:35 <gema> +1
16:08:37 <shamail> +1
16:08:38 <hogepodge> +1
16:08:38 <catherine_d|1> +1
16:08:43 <dmellado> +1
16:08:52 <markvoelker> +0 (fine either way)
16:09:08 <kgarloff> +0
16:09:27 <eglute> +0 for me as well, but canceling seems to win
16:09:55 <luzC> o/
16:09:57 <eglute> #agreed no meeting next week
16:10:18 <eglute> #topic Flag volume_from_snapshot test from 2016.08
16:10:34 <eglute> #link https://review.openstack.org/#/c/385216/
16:10:55 <markvoelker> This one is abandoned
16:11:15 <eglute> oh, i am too slow!
16:11:22 <eglute> i guess we are good then
16:11:37 <eglute> #topic 2017.01 Guideline
16:11:50 <eglute> shamail do you have an update on cinder?
16:12:31 <shamail> Hi eglute, I do not.  I had to leave the summit early and didn’t check the etherpad yet.  I will work on this update later this week and early next week (if needed).
16:12:59 <eglute> thanks shamail
16:13:05 <eglute> Moving on to swift
16:13:06 <shamail> you’re welcome
16:13:29 <eglute> I started breaking out the patch i had originally submitted
16:13:49 <eglute> new patch for new capabilities: #link https://review.openstack.org/#/c/398428/
16:14:18 <eglute> i am not sure how to handle some of the things, like consolidating existing capabilites
16:14:22 <eglute> one of them is that
16:14:59 <eglute> also, one renamed capability
16:15:04 <eglute> and one brand new one
16:15:16 <eglute> i scored others as well, as suggested by ptl
16:15:23 <eglute> please review my scoring :)
16:16:08 <eglute> i still have to submit a patch with new tests that were suggested, i will work on that today
16:16:14 * markvoelker plans to work on that this week now that post-summit stuff has calmed down
16:16:59 <eglute> thanks markvoelker... catching up after this summit has been really hard
16:17:23 <markvoelker> yup
16:17:57 <eglute> any comments on swift? or ideas how to handle renames for capabilities? or suggestions on adding new tests to capabilities?
16:18:35 <markvoelker> eglute: none off the cuff, but I may once I get a chance to look at it more (probably tomorrow)
16:18:59 <eglute> thanks markvoelker!
16:19:14 <eglute> if no comments on swift, can move to nova
16:19:22 <eglute> #link https://review.openstack.org/#/c/385781/
16:19:32 <eglute> thanks luzC for reviewing it
16:19:39 <hogepodge> this has been the busiest I've even been after a summit, and I've done very little defcore work outside of logo and test admin
16:20:37 <hogepodge> MT will be catchup days for me on 2017.01 reviews
16:20:59 <eglute> hogepodge i understand! I been slow to catch up as well
16:21:00 <eglute> there are some good comments on the nova patch
16:21:03 <eglute> thanks shamail for submitting it
16:22:00 <markvoelker> One thing I noted in that review was the comment about AZ's, which I think has some merit
16:22:37 <markvoelker> I need to go look at those tests a bit, but seems like lisitng AZ's is sound addition.
16:22:58 <eglute> agree... also new capabilities need to be as advisory first
16:22:59 <shamail> I can remove list-api-versions since it is already added.  I scored it again because I was unfamiliar with the process.
16:23:34 <eglute> also, i think the compute-flavors-list was already there at some point. i think i said i would look into it and never did
16:23:40 <shamail> The reason I added them was because they have been around for multiple releases (I assumed advisory for newly added functionality, not capabilities guidelines)
16:23:44 <markvoelker> shamail: I think it's fine...sometimes scores change over time, so it's perfectly fine to update them
16:23:45 <shamail> but happy to change that as well
16:24:28 <shamail> Do all new guidelines go through advisory first? (asking for my own benefit)
16:24:35 <eglute> yes
16:24:41 <shamail> Okay :)
16:24:45 <shamail> Will update
16:24:58 <eglute> well, they should.
16:25:11 <eglute> except in swift case, i have one where it is a rename or something like that. still a grey area on that one
16:25:21 <eglute> until we decide what to do :)
16:26:21 <eglute> #action eglute research what happened to compute-flavors-list
16:26:34 <eglute> everyone, please review nova patch
16:26:34 <markvoelker> Is it grey?  We're explicitly allowed to change groupings.  http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/2016A.rst#n71
16:26:58 <eglute> oh, that helps! thanks markvoelker!
16:27:45 <eglute> any other comments on nova?
16:28:17 <eglute> if not, moving on to heat
16:28:34 <eglute> catherine_d|1 gema and I met with the Heat team in Barcelona
16:28:58 <eglute> Heat is considering moving Gabbi tests: https://review.openstack.org/#/c/348076/
16:29:13 <eglute> Problem: Tempest currently does not support Gabbi, so additional delay.
16:29:22 <eglute> All tests will be new, so would have to go through the "stable test" period. Suggestion: add them as advisory before they are considered "stable" for 2 cycles, and potentially keep them for advisory 2-3 cycles.
16:29:31 <eglute> these were my notes from that meeting
16:29:49 <eglute> catherine_d|1 gema please add or correct if i missed anything
16:30:10 <eglute> but basically, heat doesnt look good
16:30:18 <eglute> for adding them soon
16:30:38 <catherine_d|1> eglute: yea looks like that is the case
16:31:01 <catherine_d|1> Just one note that with Gabbi .. these would be pure API tests ...
16:31:23 <eglute> i think that would be ok
16:31:27 <markvoelker> And currently still planned for in-heat-tree vs in-tempest-tree, right?
16:31:48 <eglute> gabbi would help with the in tempest tree part
16:32:01 <catherine_d|1> it will be in-heat tree with tempest plugin interface first
16:32:44 <markvoelker> Ok, so as things currently stand with the TC they'd still be hard to consider anyway...
16:33:41 <catherine_d|1> Once test are in Tempest plug-in interface moving to Tempest would be easy
16:33:44 <hogepodge> the idea was that tests would move only when required
16:33:47 <eglute> i think once they have gabbi tests, we can consider them when they are still in plugin, with the understanding that they would move the tests
16:34:16 <hogepodge> per conversation with dhellmann at summit
16:34:17 <catherine_d|1> hogepodge: exactly .. that is why all new tests development will be in-tree with plug-in implementation first
16:34:35 <hogepodge> so start with plug in and move tests if added to defcore
16:34:36 <markvoelker> sounds good
16:34:46 <catherine_d|1> hogepodge: yup
16:35:05 <eglute> any other comments on heat?
16:35:40 <catherine_d|1> I am good
16:35:45 <eglute> thanks catherine_d|1!
16:35:53 <eglute> moving on to keystone
16:36:05 <eglute> hogepodge, did you have a chance to look at it?
16:36:23 <hogepodge> eglute: no, I can give it attention starting Monday
16:36:29 <eglute> thanks hogepodge!
16:36:37 <markvoelker> I've got a couple of candidates from the PTL...it's late, but I can probably push a scoring patch this week if folks can review it
16:36:56 <hogepodge> yes please.
16:36:59 <eglute> markvoelker that would be good!
16:37:02 <markvoelker> It will be fairly short, so not hard to review. =)
16:37:06 <eglute> :)
16:37:23 <eglute> Neutron: patch was merged, thanks markvoelker!
16:37:32 <markvoelker> Basically list user's groups, list user's projects, change user's password, and show user I think.
16:37:49 <eglute> sounds good!
16:38:01 <eglute> Glance: markvoelker did you have a chance to look at it?
16:38:24 <markvoelker> Yeah, I talked this over with some Glance folks.  I don't think we're going to have a lot of additions here, but a little housekeeping might be in order
16:38:37 <eglute> works for me!
16:38:54 <markvoelker> E.g. we have a few places where we say something like "v1 API is SUPPORTED but not the CURRENT version"...but v1 is now DEPRECATED
16:39:18 <markvoelker> That should be a pretty trivial patch, which I can probably also push this week
16:39:20 <eglute> oh yeah, def. need to do something about that
16:39:25 <eglute> thanks markvoelker
16:40:16 <eglute> any other comments/updates on 2017.01 guideline?
16:40:59 <eglute> #topic Name change
16:41:15 <eglute> markvoelker shamail hogepodge any updates?
16:41:40 <hogepodge> I need to check with fungi about the mailing list.
16:41:57 <hogepodge> I ran it by him at the summit, and need to follow up.
16:42:02 <shamail> None, but I think the note in the etherpad is worth mentioning
16:42:03 <fungi> yep, i promised to show you what file to propose a change to
16:42:14 <shamail> Please switch to the #openstack-interop channel if you haven’t already done so
16:42:33 <eglute> thanks shamail
16:42:44 <shamail> hogepodge: can you also ask about the Wiki?
16:42:44 <eglute> thanks hogepodge and fungi
16:42:52 <hogepodge> The procedure there would be to set up new mailing list, send an announcement to everyone on current list to move, then shut down old list by removing all membership and leaving the archive intact.
16:42:55 <shamail> There is a copy option but I didn’t want to try it without asking
16:43:07 <markvoelker> We had discussed a goal to get all the wheels in motion on the name change by the end of the year IIRC.  So I plan on taking this up a bit more once I get 2017.01 cleared off my plate.
16:43:20 <markvoelker> I know I've got a few AI's outstanding, and have patchwork started on a couple of them
16:43:40 <shamail> The meeting doesn’t really need to change (besides the name)… I can submit that patch soon too
16:43:50 <hogepodge> December seems like a good month to finish it off, and aligns with the schedule I had in my mind.
16:43:57 <eglute> hogepodge can the subscribers be copied to the new mailing list?
16:44:04 <shamail> The gerrit and git repo changes are probably the ones you want to handle markvoelker
16:44:16 <markvoelker> shamail: yep, on my list
16:44:17 <hogepodge> eglute: I don't believe so. The general policy for mailings is opt-in
16:44:24 <shamail> Not that I am aware of eglute (we are going through the same task in Product WG)
16:44:39 <shamail> As admins, you can seee the current subscribers but cant subscribe them
16:44:48 <fungi> yeah, it's a question of whether you can vs whether you should
16:45:01 <shamail> my recommendation would be to get the list of current subscribers and send them a BCC’d note informing them about the change and a link to sign up
16:45:19 <shamail> a one time notification/heads up isn’t overkill
16:45:23 <hogepodge> shamail: The change info will go out to all subscribers, so everyone will be notified.
16:45:35 <shamail> good point
16:45:43 <fungi> there is a mass subscribe page you have access to as list admins but it can be a bit surprising for people to suddenly find themselves subscribed to a new mailing list they dodn't request
16:45:44 <hogepodge> If they miss it because of mail filters, then they may not want to subscribe to the new one anyway
16:46:00 <shamail> fungi: +1, I think opt-in is best
16:46:46 <markvoelker> yeah, I don't think subscribing to an ML is too much action to request of anyone that actually wants to be involved. =)
16:47:15 <eglute> ok, so opt-in it is for the new mailing list
16:47:49 <shamail> fungi: Will the action > move option in wikis help us migrate our wiki to a new name?
16:47:59 <shamail> or is it better to just do it by hand?
16:48:14 <shamail> I wasn’t sure what the impact would be to the existing page if that option is used.
16:48:25 <fungi> shamail: moving wiki pages works fine
16:48:32 <shamail> Thanks
16:48:36 <fungi> it will optionally (and by default) leave a redirect from the old name for you too
16:48:46 <shamail> That’s perfect.
16:48:51 <shamail> I will go ahead and take that one then
16:49:22 <eglute> any other comments on the rename?
16:49:36 <eglute> #action shamail to move wikis
16:49:38 <fungi> per recent additional security measures we put in place, you have to be a "verified" (autopatrolled) account to be able to move wiki pages now, but pretty much all of you are already
16:50:37 <eglute> thanks fungi!
16:50:45 <shamail> Thank you fungi and hogepodge!  Great information.
16:50:59 <eglute> #topic Documenting how projects can become part of Guidelines
16:51:02 <eglute> markvoelker updates on this?
16:51:08 <eglute> ah, no updates
16:51:28 * eglute read etherpad
16:51:40 <markvoelker> On my backlog.  I'll probably not get to this until after Thanksgiving, realistically
16:51:48 <eglute> thanks markvoelker!
16:51:52 <eglute> no rush on that one
16:52:06 <eglute> #topic Upcoming events: PTG
16:52:22 <eglute> hogepodge, any updates on the time slot?
16:52:38 <hogepodge> eglute: Uhm, it's not great news
16:52:59 <eglute> oh?
16:53:19 <hogepodge> the ptg is reserved for TC approved projects. We could possible take advantage of time set aside for refstack, but dedicated space over the course of several days will not be made available to us
16:53:46 <gema> hogepodge: shall we then continue to have our own separate midcycles?
16:53:51 <catherine_d|1> RefStack can request for room .. but seems like not many RefStack team member will be able to attend PTG ... I wonder whether we can combine the RefStack and DefCore meeting at PTG
16:54:25 <eglute> i like the catherine_d|1 suggestion for now, but we need to resolve the "not TC project" part
16:54:47 <hogepodge> catherine_d|1: that was proposed as a solution, but keep in mind that this is a lot of shared space that will be allocated according to project size and need
16:55:00 <eglute> opinions?
16:55:24 <markvoelker> Sounds to me like a separate midcycle might actually work better if we don't think refstack can get much time/space
16:55:33 <hogepodge> I'm not thrilled about it, but it's the TCs purview
16:55:43 <markvoelker> hogepodge: ++
16:55:59 <eglute> how do people feel about dedicated midcycle?
16:56:12 <hogepodge> It we want to push it, we could raise it formally at a TC meeting.
16:56:15 <eglute> I am sure Rackspace would be happy to host it in San Antonio :)
16:56:48 * markvoelker wonders if anyone would be interested in hosting us in ATL, say, the week of the PTG...
16:56:55 <hogepodge> eglute: I was looking forward to the PTG promise of less travel, but the meetings have been important so I'll continue to support them
16:56:58 <gema> markvoelker: that would be rad x)
16:57:00 <eglute> I think because of the work we do, we should fall under crossprojects somwhere
16:57:12 <hogepodge> markvoelker: heh, that sounds like a good idea
16:57:26 <gema> catherine_d|1: does IBM have offices there?
16:57:32 <gema> or rackspace :D
16:57:46 <eglute> i like the suggestion of asking TC for space at PTG
16:58:11 <eglute> I can find out out about our office in Atlanta, not sure how big/small it is
16:58:23 <gema> :)
16:58:37 <catherine_d|1> I don't recall that we have development site .... I doubt it but can check
16:59:09 <eglute> we are almost out of time-- hogepodge could ask TC for space at PTG?
16:59:18 <hogepodge> to be clear, we're invited to the PTG, we just can't get a dedicated room or extended resources. Meeting for cross project work is encouraged
16:59:31 <shamail> I can’t make it, kids are off from school that whole week.
16:59:47 <eglute> lets ask for dedicated room if most of us would be able to make it
16:59:49 <hogepodge> eglute: sure, I can put it on the agenda
16:59:52 <eglute> thank you hogepodge
16:59:54 <shamail> Will Interop WG still have a midcycle or is PTG the midcycle for this team
17:00:11 <shamail> nm
17:00:21 <shamail> catching up on the previous messages
17:00:26 <eglute> and we are out of time... lets move to openstack-interop channel
17:01:00 <eglute> will discuss last topic next meeting
17:01:01 <eglute> thansk everyone
17:01:02 <eglute> #endmeeting