17:00:49 #startmeeting glance_artifacts_sub_team 17:00:55 Meeting started Mon Feb 1 17:00:49 2016 UTC and is due to finish in 60 minutes. The chair is mfedosin. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:56 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:57 #link https://etherpad.openstack.org/p/glance-artifacts-sub-team-meeting-agenda 17:00:59 The meeting name has been set to 'glance_artifacts_sub_team' 17:00:59 o/ 17:01:03 O/ 17:01:20 glad to see you here today :) 17:01:32 so, we have several topics to discuss 17:02:15 but before I have to mention that I'm writing a document about glare architecture 17:02:42 it's almost done and I'll publish it tomorrow after today's decisions 17:02:52 excellent, can't want to see 17:03:13 you can see a picture from there 17:03:45 yes, the pic is pretty cool indeed 17:03:52 last Friday Nikhil asked me to write some thoughts about glare... 17:04:06 like brainstorming the architecture 17:04:18 #link https://etherpad.openstack.org/p/mitaka-glare-api-brainstorm 17:04:38 I did it, but here we can discuss it 17:04:51 first think about public and private api 17:05:15 I think it's unnecessary and we can have only one public api 17:06:00 and if DefCore wants some standardization we can do it with images api only 17:06:23 other plugins are optional 17:06:47 nikhil, your thoughts? 17:06:52 yeah, mfedosin and I had a brief starter discussion on what the architecture looks like. I wanted to see how the "schema on schema" idea looks like. 17:07:15 My feeling is that we need to have a structured scope around the API (only public API) 17:07:20 and for that we need semantics 17:07:28 there are two ways of doing it 17:07:34 the oslo.vo is one way 17:07:35 nikhil absolutely agree with you 17:07:53 but the primary origination of oslo.vo is 17:08:09 having a static feeling to dynamic language (ie python) 17:08:32 that helps with the DB upgrades and asynchronous calls (Bcast and multi cast) etc 17:08:53 I think it might be worth adding the scope of our requirements and bring that to the oslo.vo core team 17:09:03 given we choose to take that route 17:09:10 also oslo.vo helps with architecture 17:09:16 if all works out that seems like a good idea 17:09:19 agreed 17:09:37 I mean we can map Blob type directly to store with coercing 17:09:53 you may see my example from the etherpad 17:10:33 I think we need to investigate how oslo.vo behaves in our case 17:10:53 I need more time to absorb that example and fit it into bigger pic 17:10:58 yes 17:11:19 but we can leave oslo.vo as the main priority for glare 17:11:51 if it doesn't fir we can return to the idea of 'schema-on-schema' 17:12:07 *fit 17:12:16 are there more comments that we might expect on the etherpad ? 17:12:30 I asked kairat to look there too 17:12:36 ah cool 17:12:55 hopefully we can get something today 17:13:04 but we discussed it today and he agrees we the direction 17:13:06 else, let's move forward with oslo.vo 17:13:46 okay, about the documentation 17:14:06 as I mentioned last week it's called What is Glare? 17:14:27 and it provides an eagle view on the service 17:14:55 Does it describe current doc?) 17:14:56 it will help community members to be more familiar with Glare 17:15:09 Current impl 17:15:34 or future implementation 17:15:36 and also will describe some usecases for our customers 17:15:51 great 17:16:22 kairat_: it's something between Alex wanted to see and something that will work :) 17:16:38 Heh 17:16:41 so, I have a picture of that 17:17:09 #link https://dl.dropboxusercontent.com/u/13626875/glare.png 17:17:35 it's based on oslo.vo 17:18:28 idea is that we have unified api for all plugins (or 'oslo versioned objects' if you want) 17:18:53 then we have a unified api that all plugins must implement 17:19:18 but each plugin may have it's own data_api 17:19:36 That's simple and great imo 17:19:43 Good to hear 17:19:51 for example, for images it will be current Image tables 17:19:53 what is a data_api ? 17:20:09 Api to database 17:20:17 nikhil: the same thing we have in glance-api.conf 17:20:24 ah 17:20:41 seems logical 17:21:43 that's how heat does it https://github.com/openstack/heat/blob/master/heat/objects/stack.py#L25 17:22:25 so, we need to think about 2 things 17:22:40 1. REST api - Alex almost did it for us 17:23:06 we just need to add there requests for data upload/download 17:23:14 and we're cool :) 17:23:15 yeah, not sure where heat separates it's data but glance does for metadefs and imgaes 17:24:07 2. Interface for oslo.vo classes 17:24:50 like 'save' data to db, 'get' from db, 'add_tag' and so on 17:25:55 also there is a patch from Alex to move glance v3 api to Glare v0.1 17:26:19 nikhil: if you have time please review it and let's merge it 17:26:27 sounds good 17:26:51 #link https://review.openstack.org/#/c/255274/ 17:27:16 after that we will be able to start the development of glare v1 :) 17:27:39 ++ 17:27:52 We need to merge glare xlient code as well 17:27:52 and also - no Glance/Glare separation! 17:28:02 we will stay in glance repo 17:28:22 But it is not a blocker 17:28:42 kairat_: you will be a core member tomorrow 17:28:49 What about murano requirements 17:29:00 Oops, cool)) 17:29:04 you will be able to merge everything 17:29:10 Heh 17:29:14 we will help you 17:29:43 hi I have a small request 17:29:44 but let's begin with a standalone service 17:29:53 given we have a min or so 17:29:53 nikhil shoot 17:30:02 can we move this meeting to 1730 UTC 17:30:08 in this channel 17:30:15 just checked and the slot is open 17:30:24 I have a conflict at this time 17:30:24 I think it easy 17:30:28 Ok for me 17:30:37 same for me 17:30:38 awesome, will send a review and email ML 17:30:44 Need to notify to dec mail 17:30:45 thanks guys 17:30:46 nikhil please do 17:30:53 Dev mail 17:30:56 yeah 17:31:23 okay, thank you all :) 17:31:37 glare is coming! 17:31:44 #endmeeting