15:03:17 <TravT> #startmeeting openstack search
15:03:17 <openstack> Meeting started Thu Nov 12 15:03:17 2015 UTC and is due to finish in 60 minutes.  The chair is TravT. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:20 <openstack> The meeting name has been set to 'openstack_search'
15:03:29 <sjmc7> ello
15:03:37 <david-lyle> o/
15:03:44 <lakshmiS> o/
15:03:54 <TravT> howdy!
15:04:10 <yingjun> ;)
15:04:23 <nikhil_k> o/
15:04:46 <TravT> Ok, here's our agenda: https://etherpad.openstack.org/p/search-team-meeting-agenda
15:04:53 <TravT> take a look and see if there's anything to add
15:05:02 <TravT> although we've got a really full plate today, i think.
15:05:03 <rosmaita> o/
15:05:27 <gb21> o/
15:05:41 <TravT> #topic Feature request workflow (blueprints, specs, bugs, etc) (TravT)
15:06:15 <TravT> I sent a message to ML: http://permalink.gmane.org/gmane.comp.cloud.openstack.devel/68786
15:07:25 <TravT> summary is, I think the time has come to document our feature request processes, and to specifically include how we handle feature requests that are more complicated
15:08:13 <sjmc7> i did wonder what the reason for seperate -specs repositories was, whenever that started (juno?)
15:08:15 <TravT> that is supporting a way to review requests that are more complicated than launchpad effectively handles
15:08:31 <sjmc7> but otherwise i’m in favor of being able to review specs in gerrit
15:09:23 <TravT> i'm not sure, maybe to support separation of core spec reviewers and core code reviewers?
15:09:38 <nikhil_k> sjmc7: it also shows up in a clean way and consolidated manner (across cycles) on specs.openstack.org
15:09:40 <TravT> also many projects have multiple repos,
15:09:53 <rosmaita> it's also a source of documentation
15:10:02 <rosmaita> specs.openstack.org
15:10:10 <nikhil_k> there was a good question if specs are documentation or workflow process for feature proposal
15:10:13 <rosmaita> what nikhil_k said
15:10:37 <sjmc7> i think both - i’m ok keeping them in the /docs directory in the source tree for now
15:10:48 <david-lyle> I think it can only be documentation of the plan
15:11:00 <nikhil_k> TravT: LP can be spammed with blueprints and fortunately hasn't been the case with SL
15:11:02 <david-lyle> final and spec may not precisely align
15:11:17 <nikhil_k> also, one critical update from cross project mtg
15:11:24 <TravT> so, with what I proposed is that we basically are doing specs when needed, but they go in our source doc tree.
15:11:40 <TravT> here's an example: https://review.openstack.org/#/c/243386/
15:11:41 <nikhil_k> the release mgmt is going away from LP into a different tool for bugs
15:11:58 <nikhil_k> that being said, teams would still have the option to maintain their own LP page
15:12:03 <rosmaita> TravT: i'm not sure what the benefit of being non-standard on this is?
15:12:34 <TravT> i debated a bit on that as well... here was some of my thinking.
15:12:45 <TravT> we document everything else in one location for searchlight
15:13:17 <rosmaita> but as david-lyle said, that's mostly finished product, not design
15:13:19 <TravT> why do we have to go somewhere else (diff website, diff source repo) etc to document designs
15:14:07 <rosmaita> TravT: because some will be approved, and of those, only some will actually be implemented
15:14:41 <david-lyle> yeah approving a spec or bp does not directly correlate to implementation
15:14:41 <nikhil_k> (nice rosmaita!) and rest of them put in the bucket list :)
15:15:06 <TravT> yeah, that part i get, which is why I included a status in the feature design template
15:15:06 <TravT> http://docs-draft.openstack.org/81/243881/2/check/gate-searchlight-docs/8270651//doc/build/html/feature-designs/template.html
15:15:24 <TravT> but there was one other idea...
15:15:42 <TravT> can we sometimes have feature requests be submitted as though there were actual doc updates?
15:15:45 <TravT> http://docs-draft.openstack.org/81/243881/2/check/gate-searchlight-docs/8270651//doc/build/html/feature-requests-bugs.html#as-user-docs
15:16:19 <TravT> some of this is coming from experience on horizon where we seem to be in a constant state of trying to get people to document there features.
15:16:30 <TravT> s/there/their
15:16:55 <TravT> and was trying to think if there was a way to streamline it all
15:17:10 <nikhil_k> good luck with that :)
15:17:11 <yingjun> Maybe it is better to make a new directory to hold the implemented feature?
15:17:15 <david-lyle> TravT: that was just poor review standards, shouldn't have happened
15:17:18 <TravT> but if you guys think we should just do specs, we can do that too.  Will just need to setup spec repo
15:17:43 <sjmc7> i’m fine with either
15:17:53 <rosmaita> TravT: we definitely want to make sure there's something to find for searchlight at specs.openstack.org
15:17:57 <sjmc7> agree that being standard is probably more sensible
15:18:01 <rosmaita> could be a redirect, i guess
15:18:07 <nikhil_k> +1
15:18:12 <rosmaita> but that could be confusing, too
15:18:33 <nikhil_k> if we can setup docs/ in searchlight to be shown at specs.openstack.org it would be great
15:18:36 <david-lyle> I would be reluctant to merge spec and code repos, but what tool houses specs, meh
15:18:40 <rosmaita> TravT: i appreciate your desire to keep things streamlined, but it might be better overall to go with the flow
15:18:49 <rosmaita> of the rest of openstack
15:18:54 <TravT> okay, that sounds reasonable.
15:19:03 <TravT> i'll put up a request for spec repo.
15:19:13 <rosmaita> +1
15:19:14 <nikhil_k> TravT: the reason is that we would be playing cat and mouse while the overall flow is driven by release team
15:19:29 <TravT> but, please give comments on rest of workflow
15:19:31 <TravT> http://docs-draft.openstack.org/81/243881/2/check/gate-searchlight-docs/8270651//doc/build/html/feature-requests-bugs.html#workflow
15:19:39 * david-lyle hopes to be watching 40 repos by the end of Mitaka
15:20:01 <TravT> basically, not require a spec for every feature.
15:20:02 <nikhil_k> #link https://review.openstack.org/#/c/243881
15:20:03 <TravT> only when needed
15:21:31 <TravT> or do you guys think one should always be required?
15:21:43 <TravT> which is contrary to previous discussions
15:22:07 * nikhil_k fine either way
15:22:09 <david-lyle> +1 for less overhead for lightweight changes
15:22:14 <sjmc7> for anything that’s really straightforward i don’t think it’s necessary
15:22:34 * nikhil_k actually doesn't care much about what process to follow too. just giving feedback.
15:22:34 <sjmc7> much as i enjoy nitpicking reviews over people’s grammar
15:22:44 <rosmaita> the argument for a spec is TravT's documentation point
15:22:54 <rosmaita> it forces some doc to work from for the "real" doc
15:23:02 <david-lyle> sjmc7: I think it's just your misunderstanding of "proper" English :P
15:23:14 <nikhil_k> ha
15:23:36 <nikhil_k> no approvals without at least one rap in the spec
15:24:05 <sjmc7> it’s going to make a comeback, any day now. i’m not that bothered either, but i think the project’s still small enough we can be a bit informal
15:24:29 <TravT> I like lightweight where we can, because I can still go through and manage them fairly easily.
15:25:07 <TravT> Ok, I'll amend the review to have a spec repo.
15:25:24 <rosmaita> maybe we propose bp only for small feature, but require a section "how this would be documented for users"
15:25:29 <nikhil_k> sorry I have to drop off for travel. will catch from logs later.
15:25:35 <TravT> thanks nikhil_k
15:25:41 <rosmaita> nikhil_k: travel safely!
15:25:45 <TravT> next boring stuff topic...
15:25:50 <TravT> #topic Reno release notes:
15:25:50 <nikhil_k> thanks guys!
15:26:00 * nikhil_k &
15:26:12 <TravT> https://blueprints.launchpad.net/searchlight/+spec/setup-reno-based-release-notes
15:26:31 <TravT> basically, relmgr wants us to put a little yml file in the repo for big features
15:26:39 <TravT> and release notes will be generated from that
15:27:22 <TravT> Are there any volunteers to set this up for searchlight (I can if nobody else is interested)?
15:27:53 <lakshmiS> i can try
15:28:06 <TravT> thx Lakshmi.
15:28:10 <TravT> I'll assign that bp to you
15:28:20 <lakshmiS> ok
15:28:30 <rosmaita> lakshmiS: doug h just did it for glance
15:29:12 <TravT> ok, now slowly move to maybe more interesting
15:29:15 <lakshmiS> thanks rosmaita: will take a look
15:29:20 <TravT> #topic Summit review
15:29:51 <TravT> The presentation Steve, Lakshmi, and I did is available on youtube.
15:30:13 <TravT> #link https://www.youtube.com/watch?v=0jYXsK4j26s
15:30:23 <TravT> FYI.
15:30:47 <TravT> The venue was rather challenging... we were in the back corner of the marketplace pretty far from the main conference sessions and the design summit
15:30:57 <TravT> I counted around 45 - 50 attendees
15:31:19 <TravT> but there were glance and horizon design sessions at the same time
15:31:32 <TravT> which were about a 15 minute walk away
15:31:55 <TravT> But overall, it went well.
15:32:29 <TravT> I took all the priorities and integrations and opened blueprints for them
15:32:58 <TravT> and took a swag at priority
15:32:59 <TravT> https://blueprints.launchpad.net/searchlight
15:33:22 <TravT> if you disagree on any, let me know
15:33:33 <rosmaita> lakshmiS: i think these are the relevant changes for reno: https://review.openstack.org/#/c/241323/ , https://review.openstack.org/#/c/243302/, https://review.openstack.org/#/c/241322/ , https://review.openstack.org/#/c/241321/
15:34:25 <TravT> But, my question is whether or not you all would be interested in doing a BP review and prioritization session next week?
15:34:26 <sjmc7> i added a couple more yesterday (at the top of the ‘undefined’ list)
15:34:54 <TravT> yeah, i also want to add one related to our /index API
15:35:09 <lakshmiS> thanks rosmaita
15:35:30 <sjmc7> i think we have a pretty good idea of the priorities coming out of the summit, that list looks good
15:35:32 <lakshmiS> TravT: that sounds good
15:35:44 <rosmaita> TravT: +1
15:35:48 <sjmc7> i’d be ok doing more design type reviews once there are more fleshed out specs
15:36:07 <TravT> i'm not sure what lakshmiS and rosmaita are +1'ing
15:36:29 <rosmaita> BP review & prioritization next week
15:36:30 <david-lyle> probably that the prioritized list meets expectatoins
15:36:34 <lakshmiS> i think its good to get everyone to review the list on BP
15:36:37 <david-lyle> or that
15:36:38 <david-lyle> :P
15:37:20 <TravT> ok, i can do tuesday or wednesday at the same time or later next week
15:38:01 <rosmaita> TravT: tues,wed same time works for me
15:38:44 <TravT> let's plan on Tuesday 15:00 UTC.  We'll start in the #openstack-searchlight
15:39:07 <TravT> let's get to some technical topics...
15:39:16 <TravT> #topic Swift integration
15:39:29 <TravT> Do we have briancline?
15:39:53 <TravT> doesn't look like it.
15:39:56 <lakshmiS> nope
15:40:20 <TravT> Well, I think it'd be good to share status updates with others.
15:40:30 <TravT> sjmc7 you went to the meeting yesterday... want to give a summary?
15:41:09 <sjmc7> the swift folks aren’t keen on bring in dependencies for things in tree, particularly oslo things (although as brian pointed out the keystone middleware brings in most of oslo)
15:41:22 <lakshmiS> :(
15:41:26 <sjmc7> but in principle there’s support for adding notifications
15:41:43 <sjmc7> so something simple out of tree is our best bet for now
15:42:17 <TravT> #link http://eavesdrop.openstack.org/meetings/swift/2015/swift.2015-11-11-21.00.log.html
15:42:21 <TravT> starting at 21:31:09
15:42:21 <TravT> FYI
15:42:29 <sjmc7> that was the summary, really, plus a lot of bike shedding
15:42:44 <TravT> sjmc7: it seemed to me that they were okay with possibly adding a soft dependency
15:42:48 <TravT> like they do with keystone
15:42:58 <TravT> how does that work for them?
15:43:09 <sjmc7> you have to install keystonemiddleware separately
15:43:32 <TravT> so, basically put it in the deploy pipeline?
15:43:36 <sjmc7> they didn’t seem very keen on adding anything in the swift tree
15:43:49 <sjmc7> yeah, then enable the middleware
15:43:56 <sjmc7> there is some precedent for external middleware
15:44:07 <lakshmiS> that would make it tough to have code sit in swift which depends on oslo directly
15:44:21 <sjmc7> right - nothing can be added to requirements.txt
15:44:47 <sjmc7> so the question is whether the file that sends notifications lives in swift or not, and the feeling i got was ‘not’, at least for now
15:45:07 <sjmc7> but i think the best plan is to put something together to show them
15:45:26 <sjmc7> nobody really had a good handle on what would be involved; they don’t use the oslo libraries much
15:45:57 <TravT> so, this could be put into searchlight repo, but that might be problematic for packaging and deploy
15:46:04 <TravT> i'm not a packaging person, so i don't know
15:46:14 <sjmc7> no, i don’t think that’s a good idea
15:46:27 <lakshmiS> agree with sjmc7 on have it use oslo and start discussing after a patch
15:46:41 <sjmc7> i think a good first step would be to put some middleware together, and possibly proopse it as a review
15:46:47 <sjmc7> alternatively stackforge it for now
15:46:53 <TravT> start it as a review
15:46:57 <sjmc7> i’m going to cobble something together today i think
15:46:59 <TravT> i'm sure it'll get bumped out.
15:47:02 <sjmc7> yeah
15:47:11 <TravT> but, might as well get it up there for their input
15:47:19 <TravT> making it easy to review is important
15:47:29 <sjmc7> yep. well, it’s one file and reasonably straightforward
15:48:19 <TravT> lakshmiS: were you able to start on the initial indexing for swift?
15:48:40 <lakshmiS> swift should consider a conditional install based on the notification approach used
15:49:52 <lakshmiS> yes started on it
15:50:34 <lakshmiS> will put WIP patch once i have the basic things working
15:50:43 <TravT> ok.
15:50:56 <TravT> daddyjoseph97: saw you joined.  anything to report related to swift integration?
15:51:52 <TravT> maybe not...
15:52:03 <daddyjoseph97> sorry, was in standup...
15:52:18 <TravT> no worries.
15:52:48 <TravT> time is running short, so just will open it up for people to talk about remaining blueprints.
15:52:52 <TravT> #topic BP review
15:52:54 <daddyjoseph97> I am in favor of conditional install just as briancline had mentioned about dependencies common to keystoneclient
15:53:39 <TravT> sjmc7 put out a request for review here:
15:53:51 <TravT> #link http://lists.openstack.org/pipermail/openstack-dev/2015-October/077962.html
15:54:04 <TravT> he and i have chatted a bit about it separately
15:54:15 <TravT> I think we need this BP into a spec repo for proper review
15:54:49 <TravT> yingjun: I saw you entered the zaqar BP
15:54:52 <sjmc7> yeah, i’ll do that once we’re agreed where they’re going
15:54:58 <TravT> https://blueprints.launchpad.net/searchlight/+spec/zaqar-notification
15:55:15 <TravT> yingjun: i will look at it today, but will try to get a spec repo up
15:55:21 <TravT> i think that one will need it
15:56:10 <TravT> gb21: are you around?
15:56:21 <yingjun> that’s not me, i think
15:56:43 <TravT> oh, my bad.
15:57:16 <yingjun> no problem:)
15:57:26 <TravT> Well, i think we've run out of time to have additional effective discussion on these BPs today.
15:57:35 <TravT> we can do that in room if needed
15:57:42 <TravT> anything else from anybody?
15:58:23 <TravT> ok, well, thanks everybody!
15:58:26 <sjmc7> thanks
15:58:26 <TravT> #endmeeting