17:30:40 <mfedosin> #startmeeting glare
17:30:41 <openstack> Meeting started Mon Mar 28 17:30:40 2016 UTC and is due to finish in 60 minutes.  The chair is mfedosin. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:30:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:30:44 <openstack> The meeting name has been set to 'glare'
17:30:54 <mfedosin> #topic agenda
17:31:10 <mfedosin> #link https://etherpad.openstack.org/p/glance-artifacts-sub-team-meeting-agenda
17:31:27 <mfedosin> #topic Updates
17:31:53 <mfedosin> there are a lot of updates in last week...
17:32:12 <mfedosin> first of all, here is the link
17:32:17 <mfedosin> #link https://review.openstack.org/#/c/292327/9
17:33:02 <mfedosin> first, now Glare has FaultWrapper middleware
17:33:25 <mfedosin> it catches all exceptions from Glare and maps them to webob exceptions
17:33:32 <nikhil> \o/
17:33:38 <mfedosin> so, no more 500s :)
17:33:44 <nikhil> amazing work!
17:34:00 <mfedosin> Darja did it :)
17:34:19 <mfedosin> I will tell her
17:34:46 <nikhil> :)
17:34:52 <mfedosin> then, we put blob uploading/downloading in engine
17:35:22 <mfedosin> so, artifact type works only with dicts, that describe blob
17:36:02 <mfedosin> as you may know engine is a thing that represents glance Domain model in Glare
17:36:42 <mfedosin> it does the same things: policies, notifications, sharing, and work with storage
17:36:56 <mfedosin> but does it in one place
17:37:24 <mfedosin> and the code is not distracted among the project
17:37:45 <mfedosin> #link https://review.openstack.org/#/c/292327/9/glance/glare/engine.py
17:38:32 <mfedosin> also, I finished listing for Glare, but it's not merged yet
17:38:38 <nikhil> I still don't get it
17:38:54 <mfedosin> nikhil: what?
17:38:58 <nikhil> so, does this mean it won't have the proxy and unproxy objects?
17:39:02 <nikhil> this == engine?
17:39:31 <nikhil> what's not spread over the project is what I'm mostly curious about
17:40:06 <mfedosin> currently we have code of Domain model separated in glance
17:40:21 <mfedosin> policy.py, location.py etc
17:40:49 <mfedosin> and there it uses composition to combine them in one
17:40:58 <kairat> yep
17:40:58 <mfedosin> engine is a flat structure
17:41:03 <nikhil> yes, it does chaining
17:41:04 <kairat> that's much simplier
17:41:15 <nikhil> ok, there are tradeoffs to both approaches
17:41:29 <nikhil> the flat code has tendency to bloat
17:41:40 <nikhil> but it's okay if we want to take this route
17:41:53 <mfedosin> we will keep it slim :)
17:41:59 <nikhil> v1 has flat structure (and may be you like it may be you don;t :) )
17:42:39 <kairat> v1 doesn't have oslo vo
17:42:50 <mfedosin> I think size of method matters
17:43:05 <mfedosin> if you have one method in 200 lines - it's bad
17:43:32 <mfedosin> we just try to use the base practice - method should fit in one screen
17:43:44 <nikhil> cool
17:43:56 <nikhil> we can chat more on your concerns at the summit
17:43:56 <mfedosin> so, all methods there are really small
17:44:04 <nikhil> just trying to make sure everyone is on the same page here
17:44:29 <mfedosin> okay, I don't mind
17:44:38 <nikhil> I'm not opposed to the approach, let's make sure all the new and old devs are aware of this.
17:44:50 <kairat> ah, ok,
17:44:50 <mfedosin> I always like to chat at the summit :)
17:44:58 <kairat> maybe worth mention this in spec also
17:45:06 <nikhil> :)
17:45:09 <nikhil> kairat: good idea
17:45:14 <nikhil> developer impact
17:45:50 <mfedosin> #action Describe developer impact in the spec
17:46:02 <kairat> I also can't see big troubles to move to layers
17:46:08 <kairat> if they really needed
17:46:18 <mfedosin> kairat: ++
17:46:25 <nikhil> cool
17:46:31 <kairat> because splitting is always easier than merging
17:46:36 <mfedosin> okay, let's move to the next topic
17:46:47 <mfedosin> #topic Listing of all artifacts. Do we need it?
17:46:59 <mfedosin> we had a meeting today
17:47:21 <mfedosin> where they say that we need to support listing of all artifacts
17:47:48 <mfedosin> nikhil: what do you think about this use case?
17:48:04 <nikhil> mfedosin: who are they :) ?
17:48:04 <mfedosin> it's primarily app-catalog feature
17:48:07 <kairat> that's required for app-catalog
17:48:15 <nikhil> ah
17:48:29 <kairat> I would say app-catalog guys and murano guys
17:48:34 <mfedosin> yup, they == Mirantis members of app-catalog
17:48:44 <nikhil> ah cool
17:48:49 <nikhil> quick question on that then:
17:48:53 <nikhil> do we have a final verdict on how we are going to implement glance.objects?
17:49:07 <mfedosin> as we plan, I suppose
17:49:19 <mfedosin> some of them will be in glance repo
17:49:21 <nikhil> I mean are we okay on keeping a separate repo openstack/glare.objects ?
17:49:30 <kairat> ah
17:49:35 <nikhil> or whatever glare_objects?
17:49:36 <mfedosin> others may be placed in separate lib
17:50:08 <nikhil> if we can ensure that the Glance API will expose certain specific Artifacts always..
17:50:17 <kzaitsev_mb> I'd say, that listing of all the artifacts is desired on the app-catalog side of things
17:50:26 <mfedosin> for exxample, 'image' is a part of Glare and must be in Glance repo
17:50:29 <nikhil> meaning there's nothing optional here and only they can be listed as a part of the _all_ call
17:50:59 <kzaitsev_mb> if there is no such API — the only way to do it would be to issue n requests for each art type
17:51:00 <nikhil> sure, I think to pass DefCore we need something that everyone is okay to expose as a part of the public api
17:51:19 <nikhil> kzaitsev_mb: my feeling is that we implement this call in the glare_client
17:51:26 <kzaitsev_mb> and it would be really nice to have the api call that abstracts it away
17:51:27 <nikhil> like the n requests thing you mention
17:51:49 <kzaitsev_mb> yep, I understand, that in any case it would be a slow call
17:51:52 <nikhil> keeping in the client would ensure that we don't expect all services to implement this separately
17:51:55 <mfedosin> I wanted to create new read-only artifact type 'all'
17:52:10 <mfedosin> so - listing all artifacts will be like
17:52:16 <mfedosin> /v1/artifacts/all
17:52:18 <mfedosin> GET
17:52:46 <nikhil> that's the exact item that was pushed back last cycle, no?
17:53:10 <mfedosin> then it takes all artifacts without their type-specific properties
17:53:14 <mfedosin> kind off
17:53:28 <mfedosin> but it will be optional
17:53:49 <nikhil> Let's keep DefCore and API_WG in loop for such calls. It would be worse if we don't get approved for one call!
17:54:09 <mfedosin> so if operator wants this feature he can enable it in his config
17:54:13 <mfedosin> nikhil: agree
17:54:15 <nikhil> vs. keeping in client would ensure we don't have to worry about performance in the API
17:54:28 <nikhil> the pagination and sorting logic can be kept int he client too
17:54:29 <mfedosin> but Alex told me that it was main defcore request
17:54:38 <mfedosin> to have these requests
17:54:55 <nikhil> oh, I see.
17:55:08 <nikhil> ok, let's get in touch with them this week if possible.
17:55:26 <mfedosin> do they have any irc meeting?
17:56:12 <nikhil> yes
17:56:23 <nikhil> http://eavesdrop.openstack.org/#DefCore_Committee_Meeting
17:56:56 <nikhil> I don't see agenda there
17:57:07 <nikhil> I will ping separately, you guys can continue this meeting until then
17:57:17 <mfedosin> I'll be there
17:57:40 <mfedosin> but we planned to organize kinda interview at this time
17:57:52 <mfedosin> Okay, now we have 5 minutes, and I'm going to tell you what should be done this week:
17:58:14 <mfedosin> #topic Future work
17:58:41 <mfedosin> 1. Separate base properties from custom properties in image artifact type
17:58:49 <mfedosin> 2. Implement tags support
17:58:59 <mfedosin> 3. Add coercing for blobs
17:59:18 <mfedosin> 4. Start working on new Context middleware
18:00:03 <mfedosin> I think if there are no question we can finish here
18:00:09 <kairat> =1
18:00:12 <kairat> +1
18:00:17 <mfedosin> thanks all, see you next week!
18:00:25 <mfedosin> #endmeeting