| *** lei-zh has joined #openstack-searchlight | 01:06 | |
| openstackgerrit | Travis Tripp proposed openstack/searchlight: Zero Downtime Reindexing Proposal https://review.openstack.org/243386 | 01:55 |
|---|---|---|
| *** bpokorny_ has joined #openstack-searchlight | 02:14 | |
| *** bpokorny has quit IRC | 02:17 | |
| *** bpokorny_ has quit IRC | 02:18 | |
| *** flwang has quit IRC | 02:25 | |
| *** yingjun has joined #openstack-searchlight | 03:35 | |
| *** david-lyle has joined #openstack-searchlight | 04:07 | |
| *** akanksha_ has joined #openstack-searchlight | 04:15 | |
| *** lei-zh has quit IRC | 04:40 | |
| *** bpokorny has joined #openstack-searchlight | 05:02 | |
| *** bpokorny has quit IRC | 05:32 | |
| *** yingjun has quit IRC | 05:46 | |
| *** yingjun has joined #openstack-searchlight | 05:46 | |
| *** yingjun has quit IRC | 05:47 | |
| *** yingjun has joined #openstack-searchlight | 05:51 | |
| yingjun | ping TravT | 05:53 |
| *** ig0r__ has quit IRC | 06:05 | |
| *** ig0r__ has joined #openstack-searchlight | 06:09 | |
| *** lei-zh1 has joined #openstack-searchlight | 06:19 | |
| *** itisha has joined #openstack-searchlight | 06:57 | |
| *** gb21 has quit IRC | 07:20 | |
| *** gb21 has joined #openstack-searchlight | 07:32 | |
| *** openstackgerrit has quit IRC | 07:46 | |
| *** openstackgerrit has joined #openstack-searchlight | 07:47 | |
| *** akanksha_ has quit IRC | 07:58 | |
| *** TravT has quit IRC | 08:25 | |
| *** openstackgerrit has quit IRC | 08:31 | |
| *** openstackgerrit has joined #openstack-searchlight | 08:32 | |
| openstackgerrit | Li Yingjun proposed openstack/searchlight: OS::Glance::Metadefs to OS::Glance::Metadef https://review.openstack.org/243458 | 08:45 |
| openstackgerrit | Li Yingjun proposed openstack/searchlight: Fix Internal Server Error when query isn't specified https://review.openstack.org/243478 | 09:18 |
| *** yingjun has quit IRC | 09:35 | |
| *** yingjun has joined #openstack-searchlight | 09:35 | |
| *** yingjun_ has joined #openstack-searchlight | 09:35 | |
| *** yingjun has quit IRC | 09:40 | |
| *** yingjun_ has quit IRC | 09:40 | |
| *** lei-zh1 has quit IRC | 10:04 | |
| *** lei-zh has joined #openstack-searchlight | 10:04 | |
| *** TravT has joined #openstack-searchlight | 10:08 | |
| *** nikhil_k has joined #openstack-searchlight | 10:29 | |
| *** nikhil has quit IRC | 10:30 | |
| *** lei-zh has quit IRC | 10:34 | |
| *** ig0r__ has quit IRC | 10:40 | |
| *** itisha has quit IRC | 11:21 | |
| *** vkmc has joined #openstack-searchlight | 11:41 | |
| *** yingjun has joined #openstack-searchlight | 12:00 | |
| *** gb21 has quit IRC | 12:03 | |
| *** gb21 has joined #openstack-searchlight | 12:36 | |
| *** gb21 has quit IRC | 12:37 | |
| *** gb21 has joined #openstack-searchlight | 12:53 | |
| *** gb21 has quit IRC | 12:53 | |
| *** gb21 has joined #openstack-searchlight | 13:10 | |
| *** gb21 has quit IRC | 13:10 | |
| yingjun | ping TravT | 14:05 |
| *** tsufiev_ has quit IRC | 14:26 | |
| *** tsufiev has joined #openstack-searchlight | 14:30 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 14:45 | |
| *** lakshmiS has joined #openstack-searchlight | 14:58 | |
| TravT | yingjun: hello | 14:58 |
| *** daddyjoseph97 has joined #openstack-searchlight | 14:59 | |
| yingjun | Hi, TravT, i’m trying searchlight, and find this Demo video https://youtu.be/eGnGr48E5_4, is there patch available? | 15:01 |
| lakshmiS | briancline: TravT: sjmc7: ready for the meeting? | 15:03 |
| sjmc7 | hey | 15:03 |
| TravT | yingjun: yes | 15:04 |
| TravT | https://review.openstack.org/#/c/227036/ | 15:04 |
| TravT | that is on master | 15:04 |
| TravT | not liberty | 15:04 |
| TravT | i do intend on publishing a liberty patch that people can use if needed. | 15:04 |
| TravT | lakshmiS: sjmc7: briancline: i'll be back in about 2 minutes. just have to grab my cup of coffee | 15:06 |
| TravT | if briancline: arrives, go ahead and start chatting without me. | 15:06 |
| TravT | nikhil_k: FYI we were going to talk swift at this time. | 15:06 |
| briancline | lakshmiS: yep | 15:06 |
| TravT | brb | 15:06 |
| lakshmiS | hey | 15:07 |
| yingjun | Trait, Okay, thanks | 15:07 |
| yingjun | TravT, Okay, thanks | 15:07 |
| briancline | morning | 15:07 |
| daddyjoseph97 | morning | 15:07 |
| lakshmiS | briancline: i started looking at all the possible data that could be stored in searchlight from swift | 15:08 |
| daddyjoseph97 | <-- Jason Galyon, works with briancline at SoftLayer on Object Storage (swift) | 15:08 |
| lakshmiS | hi daddyjoseph97: | 15:08 |
| lakshmiS | starting with UserMetaData and SystemMetaData for Account, Container and Objects | 15:09 |
| lakshmiS | what else do you think we can index in searchlight? | 15:09 |
| lakshmiS | briancline: ^ | 15:10 |
| briancline | I'd say content type, account name, container name, object path (within the container), object size, etag, timestamp | 15:10 |
| briancline | I'm probably forgetting one or two others | 15:10 |
| daddyjoseph97 | ACLs | 15:10 |
| TravT | morning daddyjoseph97 | 15:11 |
| yingjun | i uploaded 2 small patches,could any one have a look, thanks! https://review.openstack.org/243458, https://review.openstack.org/243478 | 15:11 |
| TravT | yingjun: sure, will take a look later today | 15:11 |
| lakshmiS | daddyjoseph97: ACL's sound good | 15:12 |
| yingjun | Thanks TravT, and is anyone working on this bp: https://blueprints.launchpad.net/searchlight/+spec/openstack-client-search-initial-plugin ? | 15:12 |
| TravT | yingjun: no, i don't think so. | 15:12 |
| briancline | lakshmiS: daddyjoseph97: also the type of entity.. so an account or container or object | 15:12 |
| TravT | yingjun: if you want to start working on it, that'd be great. | 15:13 |
| lakshmiS | regarding the usermetadata do you think there is any known set of properties that could be predefined? | 15:13 |
| yingjun | I’d like to:) | 15:13 |
| TravT | first thing is to come up with some more details on the proposal | 15:13 |
| briancline | lakshmiS: I'd probably shy away from it -- we've seen a huge range of stuff that folks use, but I'm not sure how much overlap there's been | 15:14 |
| daddyjoseph97 | lakshmiS: disabling dynamic type setting in Elasticsearch is important, otherwise that meta tag is doomed to what was initially guessed | 15:14 |
| sjmc7 | something that we discussed after the preesntation in tokyo was that for the kinds of use cases being shown it’d be necessary to let deployers specify mappings for the kinds of metadata they knew about in their installation | 15:15 |
| sjmc7 | maybe that’s a second step though after the basic information | 15:15 |
| TravT | yingjun: go ahead and assign that BP to yourself. And then start putting in more details on proposed CLI on the BP. | 15:16 |
| lakshmiS | without dynamic type setting, every property has to be predefined | 15:16 |
| sjmc7 | right | 15:16 |
| yingjun | TravT, Okay, will have a look first | 15:16 |
| daddyjoseph97 | sjmc7: we've discussed that as well, for a range of anticipated meta keys, for example if we knew wanted a type to run aggregations on | 15:16 |
| daddyjoseph97 | lakshmiS: yes, when we discussed that initially we settled on strings but then have exceptions as sjmc7 mentioned | 15:17 |
| sjmc7 | yeah. and if there’re examples you know about where e-s does a bad job of guessing types, that would be a case for allowing them to be specified | 15:17 |
| daddyjoseph97 | ^^^ yes, especially WRT date and time data | 15:18 |
| sjmc7 | i’d be happy getting something working with just the basics and expanding from there | 15:18 |
| daddyjoseph97 | sjmc7: I don't have any use cases currently | 15:19 |
| daddyjoseph97 | concur | 15:19 |
| briancline | +1 | 15:19 |
| sjmc7 | and not to derail this, but my bigger concern is that we can’t get notifications at the moment | 15:19 |
| lakshmiS | right | 15:19 |
| briancline | that's the really fun part | 15:19 |
| sjmc7 | :) | 15:19 |
| daddyjoseph97 | briancline enjoys pain | 15:19 |
| sjmc7 | i saw the zaqar patch, but it sounded like there was some dissent from cores about it | 15:19 |
| sjmc7 | we also weren’t clear if there was still objection to oslo-messaging notifications | 15:20 |
| briancline | yeah, sam didn't think it was ready, and didn't like affixing everything to tokens | 15:20 |
| TravT | briancline: what is this about affixing everything to tokens? | 15:20 |
| sjmc7 | yeah.. i think using zaqar for that would be tough for several reasons | 15:20 |
| TravT | i don't understand using zaqar as the default at all. | 15:20 |
| briancline | I brought it up to them in chat last week, john thought it was an interesting question, but didn't get very far. I think it was too early for most everyone else to be around | 15:21 |
| sjmc7 | TravT - that posting to a zaqar queue needs a token | 15:21 |
| TravT | right, because it is multi-tenant | 15:21 |
| sjmc7 | the one you posted the object to swift with might expire/not be scoped for zaqar | 15:21 |
| sjmc7 | so then you get into trusts | 15:21 |
| TravT | so you can't use service accounts? | 15:22 |
| sjmc7 | it’s not insurmountable, but it is a different use case than for oslo-messaging | 15:22 |
| TravT | briancline: daddyjoseph97: was zaqar something that the swift team initially wanted instead of oslo? | 15:22 |
| briancline | yeah, i think the zaqar use case they're after (but didn't clearly define in the spec) was that the notifications should be tenant-consumable | 15:22 |
| sjmc7 | right, that might be a solution. btu it’s more complex than the original patch | 15:22 |
| TravT | briancline: ah, ok. i understand that use case. | 15:23 |
| sjmc7 | yeah.. so that particular patch isn’t useful to our (searchlight)’s case, and actually that use case was discussed more widely since it’s useful for lots of services to do that | 15:23 |
| briancline | TravT: yes, in vancouver they were thinking more about zaqar, partially wanting to be opinionated about it (in the same way they are about statsd, which I didn't feel like was a very fair comparison) | 15:23 |
| sjmc7 | i suppose the question is, if we proposed a swift middleware for oslo notifications, would that just be a no-go from the start? and if so, are there other options? | 15:24 |
| briancline | TravT: but what's strange is all the use cases we were coming up with (metadata search notifications, notifications to backend pieces for tiering/archiving older objects, etc), were all non-tenant facing | 15:24 |
| sjmc7 | briancline - what’s been the position on metering in swift in the past? this was normally the driver for notifications | 15:24 |
| briancline | sjmc7: they'll probably say the spec needs reworking first because it mentions using Zaqar, though not so much as an all-out requirement if memory serves | 15:25 |
| lakshmiS | briancline: can you post the link to the spec | 15:25 |
| briancline | sjmc7: it depends on who you ask, in my experience. some say out of band tools like slogging, others say use the ceilometer middleware to emit those | 15:25 |
| sjmc7 | well, maybe a second spec | 15:25 |
| sjmc7 | i wouldn’t want to get caught in a war between tenant and non-tenant notifications. there’s possibly a case for both | 15:26 |
| briancline | lakshmiS: http://specs.openstack.org/openstack/swift-specs/specs/in_progress/notifications.htmlb | 15:26 |
| briancline | sjmc7: yeah, there definitely is. I could see that being a separate spec | 15:27 |
| sjmc7 | yeah, that spec doesn’t really match the patch | 15:27 |
| briancline | I am quite sure that once you get into it, they'll certainly complain about the dependency chain that oslo.messaging introduces. but a lot of those are already there if someone is using keystone | 15:27 |
| sjmc7 | yeah, i saw your comment about that last week - could you elaborate a bit? | 15:28 |
| TravT | briancline: do you have to original gerrit review, so we can see the comments on it | 15:28 |
| briancline | sure, one sec | 15:28 |
| TravT | funny that they'd be okay with hard dependency on zaqar but not oslo messaging which is an abstraction layer | 15:29 |
| briancline | TravT: https://review.openstack.org/#/c/180914/ | 15:29 |
| TravT | thanks... looking | 15:30 |
| sjmc7 | given that spec’s approved, and has a patch up, a second one (specifying notifications in the system sense) makes sense to me | 15:30 |
| briancline | sjmc7: I couldn't speak for most of them, but I've seen it come up before - strong aversion to additional dependencies. and late adopters to much of anything oslo. probably some history there I don't know | 15:30 |
| sjmc7 | the problem being… that then has to get approved | 15:31 |
| briancline | yeah | 15:31 |
| sjmc7 | wow - swift’s requirements file is really short! | 15:31 |
| lakshmiS | there was some mention of batching up of notifications but nothing concrete. that would be really usefull for performance | 15:32 |
| daddyjoseph97 | lakshmiS: I am interested in that, any docs or discussion available? | 15:33 |
| lakshmiS | i was looking at line 35 in the spec which mentions of batch but that was for reading from log files. | 15:34 |
| lakshmiS | but it would be nice to group the updates when sending notifications as an config option | 15:34 |
| TravT | briancline: this spec actually seems to have gone through pretty smoothly... not that many comments and revisions. | 15:34 |
| TravT | is that because there were lots of side conversations? | 15:35 |
| daddyjoseph97 | concur, we have discussed also the need to be adaptive to rate of write operations (and thus notifications) of a given account or even container or object | 15:35 |
| lakshmiS | somehow spec didnt capture that but hoping that comes up in the patch | 15:36 |
| briancline | TravT: yeah, I was a little surprised. had I known how the patch would have turned out, I would have probably been a bit more critical | 15:37 |
| briancline | TravT: I think it was mostly because there were so few interested parties | 15:37 |
| lakshmiS | so is there a review patch up for code or still being developed? | 15:37 |
| TravT | i'm kinda surprised john dickinson didn't comment | 15:37 |
| TravT | he spoke to me 2 - 3 times in vancouver about doing searching in searchlight | 15:38 |
| briancline | lakshmiS: https://review.openstack.org/#/c/196755/ | 15:38 |
| briancline | TravT: same here, I had a discussion with him in Tokyo and he mentioned he was going to try to come to the searchlight session that I came to, but must have gotten tied up in a swift discussion | 15:39 |
| TravT | there's a comment in there basically about accepting lossy messaging. | 15:40 |
| sjmc7 | regarding dependencies, it looks like (for instance) keystonemiddleware is installed as an optional component if you want to use it (which i imagine most people do unless they’re running a swift-only install), so adding an oslo-messaging dependency in the same way might be moot - if you want it, install it, if not, don’t | 15:40 |
| TravT | sjmc7: that's what I was thinking as well. | 15:41 |
| *** gb21 has joined #openstack-searchlight | 15:41 | |
| *** gb21 has quit IRC | 15:41 | |
| briancline | sjmc7: +1 | 15:41 |
| TravT | briancline: daddyjoseph97: seeing your patch is helping me to start piece the puzzle together. thanks for baring with us as we come up to speed on your work so far | 15:41 |
| daddyjoseph97 | sjmc7: +1 | 15:41 |
| briancline | that's another reason why I was hoping the notification middleware would be a bit more driver-focused | 15:42 |
| briancline | no problem. also, I should say this isn't my patch ;) | 15:42 |
| daddyjoseph97 | a hearty 'not mine' from me as well | 15:42 |
| TravT | okay... | 15:43 |
| TravT | looking at https://review.openstack.org/#/c/196755/7/swift/common/middleware/notifications.py | 15:43 |
| TravT | it is kind of funny. | 15:44 |
| TravT | it is a reverse driver | 15:44 |
| TravT | "we define message format and messaging system must conform" | 15:44 |
| briancline | TravT: yeah :-/ I wasn't too crazy about that | 15:44 |
| TravT | or am i skimming that wrong? | 15:44 |
| briancline | I would rather have the serialization been pluggable so long as a well structured dict is passed in, then have the transport layer do whatever it needs with that payload | 15:45 |
| sjmc7 | it requires that the “driver” accept HTTP requests and understand this format | 15:45 |
| TravT | briancline: that makes more sense to me. | 15:45 |
| sjmc7 | yes, me too. but again, i think the case for using zaqar notificaitons versus system ones is quite different | 15:45 |
| briancline | sjmc7: yeah, I took more issue with the strict HTTP requirement | 15:45 |
| sjmc7 | it’s not just a different backend | 15:45 |
| briancline | not that it's a bad thing, but that will add a *lot* of connection churn for really busy swift proxies | 15:46 |
| lakshmiS | there's one thing on consistency of sending notifications. if there are no free threads notifications are not guaranteed | 15:46 |
| sjmc7 | my preference if we were to propose a patch would be to make it specific to oslo | 15:47 |
| briancline | could always hold keepalive connections open in each proxy worker, but still | 15:47 |
| briancline | sjmc7: yeah, same here | 15:47 |
| TravT | +1 | 15:47 |
| sjmc7 | i guess my question is still if we were to propose a patch (maybe under that existing spec) would it stand any chance of acceptance, even as optional? | 15:47 |
| TravT | I think a patch proposed that makes oslo optional makes sense | 15:48 |
| sjmc7 | because if the answer to that is no, there’s really little we can do | 15:48 |
| lakshmiS | going by the code it doesnt look like a lot to generate notifications for oslo | 15:48 |
| sjmc7 | lakshmiS - no, it’s specific to zaqar | 15:48 |
| TravT | i really don't like that patch at all. | 15:49 |
| sjmc7 | we could also perhaps request they rename the file in that patch | 15:49 |
| lakshmiS | i guess neeed to understand it more | 15:49 |
| TravT | briancline: who is the patch author? is he a core or something on swift? | 15:50 |
| sjmc7 | the other option is something out of tree that deployers can install if they want it, i guess | 15:50 |
| briancline | TravT: that's christian schwede from redhat, he's a core | 15:50 |
| TravT | ok, good to know. | 15:51 |
| briancline | sjmc7: yeah, that's been a backup plan I've come to terms with if it needs to go there | 15:52 |
| TravT | i'm open to hosting an external plugin in searchlight if needed. | 15:52 |
| TravT | just make it part of the integration instructions | 15:52 |
| briancline | I think it stands some chance, though. I'd certainly get behind it. maybe a good discussion topic during their weekly meeting? | 15:52 |
| sjmc7 | yep. that would be step 1, i think. the searchlight side of things is simple, at least for that basic information | 15:53 |
| sjmc7 | performance, metadata, initial indexing etc have some wrinkly bits | 15:53 |
| briancline | right | 15:55 |
| lakshmiS | we could chat with christian to see if he is interested in author/coauthoring on oslo patch | 15:56 |
| lakshmiS | which might lead to discussion on swift weekly meeting | 15:56 |
| TravT | http://eavesdrop.openstack.org/#Swift_Team_Meeting | 15:57 |
| *** gb21 has joined #openstack-searchlight | 15:57 | |
| *** gb21 has quit IRC | 15:57 | |
| lakshmiS | really odd timing for me | 15:58 |
| briancline | in the mean time can we help get some of the specifics documented on fields to index and some of the other stuff we've talked about? maybe in wiki? or somewhere in the repo? | 15:59 |
| TravT | ok, maybe we need to summarize things here. | 16:00 |
| daddyjoseph97 | +1 | 16:00 |
| TravT | I think we can start on etherpad, perhaps | 16:00 |
| TravT | so we can all work together | 16:00 |
| TravT | https://etherpad.openstack.org/p/searchlight-swift-workpad | 16:00 |
| lakshmiS | yeah starting with what we talked about today on data | 16:00 |
| lakshmiS | i will add those items there | 16:00 |
| TravT | Regarding the ability to map data | 16:01 |
| TravT | the need to allow mapping definitions for user metadata is not exclusive to swift | 16:01 |
| TravT | i think we can have a BP just on that | 16:01 |
| sjmc7 | yep | 16:02 |
| TravT | because glance images, cinder volumes, instances, etc all also have user metadata | 16:02 |
| TravT | so we should come up with a common way to do that. | 16:02 |
| daddyjoseph97 | I am very interested in how you previously handled sysmeta indexing, specifically restricted access to it for tenants | 16:02 |
| lakshmiS | thats the tricky part on RBAC | 16:03 |
| sjmc7 | we record the project-id in the index | 16:03 |
| TravT | daddyjoseph97: https://www.youtube.com/watch?v=0jYXsK4j26s | 16:03 |
| TravT | maybe watch that later | 16:03 |
| daddyjoseph97 | excellent, thanks | 16:03 |
| TravT | that gives intro | 16:04 |
| TravT | and then we have several BPs this release related to improving admin field searching | 16:04 |
| lakshmiS | i guess next task for me is to get a patch up on initial indexing of data mentioned on the etherpad | 16:05 |
| lakshmiS | using REST api | 16:05 |
| *** yingjun has quit IRC | 16:06 | |
| *** yingjun has joined #openstack-searchlight | 16:06 | |
| TravT | Yeah that wouldn't hurt. | 16:06 |
| lakshmiS | notifications will slow us down from any real usage of the data though but will be good to have something | 16:07 |
| TravT | Well, we can start looking at some concrete cases | 16:07 |
| daddyjoseph97 | what about an option for a notification to actually have payload? | 16:08 |
| TravT | daddyjoseph97: that is the desired state | 16:08 |
| lakshmiS | so the notifications dont have a payload now for zaqar? | 16:08 |
| TravT | for incremental updates | 16:08 |
| daddyjoseph97 | gotcha | 16:08 |
| TravT | we have a couple concepts. | 16:08 |
| TravT | initial indexing takes you from empty ES to and an ES with all the current data | 16:09 |
| TravT | notifications are for keeping up to date. | 16:09 |
| TravT | and initial indexing is also used to re-index in the case that ES gets out of sync | 16:09 |
| TravT | we have BP to improve on that this release which we need to work through. | 16:10 |
| daddyjoseph97 | TravT, ok, good thing y'all are talking about that (btw, yes I am Texan). Backfilling has been a painful point for us | 16:10 |
| *** yingjun has quit IRC | 16:11 | |
| TravT | would love your feedback on a BP related to that. | 16:11 |
| *** yingjun has joined #openstack-searchlight | 16:11 | |
| TravT | we don't have specs repo right now, because we were trying to stay light weight, but launchpad is not good for tracking feedback. | 16:11 |
| briancline | ...or much of anything else ;-) | 16:12 |
| daddyjoseph97 | lol | 16:12 |
| sjmc7 | yeah, i’m leaning heavily towards specs in git now | 16:12 |
| TravT | so this week, i'm toying with trying to do a hybrid model of sorts | 16:12 |
| daddyjoseph97 | I held my tongue... (rare) | 16:12 |
| TravT | https://review.openstack.org/#/c/243386/ | 16:12 |
| TravT | this will be a topic i put on this weeks searchlight agenda | 16:12 |
| TravT | maybe trying to do a specs repo of sorts in our own documentation in our repo | 16:13 |
| TravT | still need to bake on that idea a bit more | 16:13 |
| *** gb21 has joined #openstack-searchlight | 16:14 | |
| TravT | ok, back to summary | 16:14 |
| TravT | lakshmiS: will put up an initial patch for doing base indexing | 16:15 |
| TravT | does somebody want to file a BP on allowing mapping files for user metadata or do you want me to go ahead and do that? | 16:15 |
| * TravT also has some things to put in there related to glance metadata catalog. | 16:16 | |
| TravT | we need to follow up with swift team relating to OSLO notifications. | 16:16 |
| daddyjoseph97 | TravT, I haven't filed a BP before but would be happy to work with you on one | 16:17 |
| TravT | daddyjoseph97: that'd be great. Very easy at the moment. | 16:17 |
| sjmc7 | i’m happy to follow up about notifications | 16:17 |
| sjmc7 | or at least turn up to a swift meeting and provide support | 16:18 |
| lakshmiS | sjmc7: that would be a great since its in the middle of night for me from india | 16:18 |
| TravT | briancline: daddyjoseph97: how do you want to work together on swift team? | 16:18 |
| briancline | TravT: I'll get something added to their agenda for tomorrow's meeting to discuss | 16:19 |
| TravT | ok, cool. then the rest of us can show up in support | 16:19 |
| TravT | i was considering adding a comment -1 on that current patch | 16:20 |
| briancline | TravT: unless we want to let some of the details brew for a week and try next week instead. but sounds like we have plenty to work with right now | 16:20 |
| briancline | yeah, I've got a few comments drafted on it I need to submit along with a -1 as well | 16:20 |
| TravT | I think we might as well get the conversation going | 16:20 |
| sjmc7 | no, let’s do it now | 16:20 |
| briancline | works for me | 16:20 |
| TravT | it can take awhile to get the wheels rolling in openstack and people rarely agree immediately on things. | 16:21 |
| TravT | so best to just get conversations going. | 16:21 |
| daddyjoseph97 | action item: get addresses to send bribes to, check | 16:21 |
| TravT | lol | 16:21 |
| lakshmiS | :) | 16:21 |
| briancline | agreed | 16:22 |
| TravT | daddyjoseph97: i can put up initial BP and then you add to it or i can step you through getting one up and i'll add to it? whichever way you like | 16:22 |
| TravT | for user metadata data mapping | 16:23 |
| TravT | BTW: this is the BP in searchlight for swift: https://blueprints.launchpad.net/searchlight/+spec/swift-plugin | 16:25 |
| daddyjoseph97 | TravT, I'll opt for help with submitting an initial one and you add to it :) | 16:26 |
| TravT | ok, super easy. | 16:26 |
| TravT | just go to here: | 16:26 |
| TravT | https://blueprints.launchpad.net/searchlight | 16:26 |
| TravT | click register blueprint | 16:26 |
| TravT | use this as template | 16:27 |
| TravT | https://blueprints.launchpad.net/searchlight/+spec/searchlight-blueprint-template | 16:27 |
| TravT | at least until / if we move to spec repo or something else | 16:27 |
| daddyjoseph97 | Thanks, TravT | 16:28 |
| nikhil_k | TravT: thanks for the ping. I was however afk for a presentation and totally missed this :/ | 16:29 |
| TravT | nikhil_k: only 90 minutes of IRC reading to do | 16:29 |
| TravT | ;) | 16:29 |
| nikhil_k | TravT: haha, true | 16:30 |
| *** bpokorny has joined #openstack-searchlight | 16:32 | |
| briancline | thanks for the discussion guys | 16:34 |
| TravT | yes, thank you! I'm really excited to get to work with everybody on this | 16:35 |
| briancline | definitely excited here too :) | 16:35 |
| lakshmiS | thanks! | 16:36 |
| daddyjoseph97 | thank you indeed :) | 16:41 |
| daddyjoseph97 | laksmiS have a great sleep! | 16:41 |
| daddyjoseph97 | lakshmiS: have a great sleep | 16:41 |
| sjmc7 | thanks chaps | 16:41 |
| *** yingjun has quit IRC | 16:49 | |
| *** lakshmiS has quit IRC | 16:50 | |
| *** itisha has joined #openstack-searchlight | 16:52 | |
| openstackgerrit | Merged openstack/searchlight: OS::Glance::Metadefs to OS::Glance::Metadef https://review.openstack.org/243458 | 17:08 |
| *** rosmaita has quit IRC | 17:37 | |
| sigmavirus24 | sjmc7: did you see github.com/sigmavirus24/openstack-ansible-searchlight ? | 19:26 |
| sjmc7 | i have a tab open with it that i got distracted from | 19:27 |
| sjmc7 | i’ll take a look, though we don’t use openstack-ansible directly | 19:27 |
| sjmc7 | it looks ok from a once-over. if i get some spare time i’ll try getting osa working | 19:32 |
| sigmavirus24 | sjmc7: yeah I'd like to make it work without the rest of OSA | 19:44 |
| sigmavirus24 | Just haven't had time to make it more self-contained | 19:44 |
| sjmc7 | our deployments are ansible based but not OSA, so the tasks and config files’ll be somewhat similar but i don’t know how reusable | 19:45 |
| *** itisha has quit IRC | 21:31 | |
| *** daddyjoseph97 has quit IRC | 21:36 | |
| *** gb21 has quit IRC | 22:04 | |
| *** gb21 has joined #openstack-searchlight | 22:19 | |
| *** nikhil_k has quit IRC | 22:33 | |
| *** nikhil has joined #openstack-searchlight | 22:33 | |
| *** tsufiev has quit IRC | 22:34 | |
| *** tsufiev has joined #openstack-searchlight | 22:37 | |
| *** bpokorny_ has joined #openstack-searchlight | 22:59 | |
| *** bpokorny has quit IRC | 23:03 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 23:29 | |
| *** bpokorny_ has quit IRC | 23:34 | |
| *** bpokorny has joined #openstack-searchlight | 23:35 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!