17:31:41 <mfedosin> #startmeeting glare
17:31:41 <openstack> Meeting started Mon Jul 11 17:31:41 2016 UTC and is due to finish in 60 minutes.  The chair is mfedosin. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:31:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:31:45 <openstack> The meeting name has been set to 'glare'
17:32:08 <mfedosin> #topic Updates
17:32:25 <mfedosin> nikhil hi :)
17:32:33 <mfedosin> thanks for review
17:32:35 <nikhil> hello
17:32:39 <nikhil> yw :)
17:33:16 <mfedosin> let me begin with updates
17:33:36 <mfedosin> kairat and dshakhray are implementing functional tests for glare
17:33:52 <mfedosin> and also fixing small bugs if they are found
17:34:20 <mfedosin> sskripnick is developing POC for app-catalog
17:34:38 <mfedosin> it was decided to start using glare from gerrit
17:34:50 <mfedosin> and don't wait for the code to merge
17:35:32 <mfedosin> also we have discussed artifact type for Heat with Heat team
17:35:52 <mfedosin> we implemented the structure and decided to organize another meeting this Friday
17:36:36 <mfedosin> these are all updates to this moment
17:36:51 <mfedosin> nikhil can we discuss your comments?
17:36:55 <mfedosin> on the spec
17:37:04 <mfedosin> #topic Glare API spec
17:37:42 <nikhil> I would prefer the discussion to be on the spec but we can discuss some things here that can be copied
17:37:52 <nikhil> (for faster resolution)
17:38:14 <mfedosin> first of all, glare supports various db backends for artifact types
17:38:43 <mfedosin> so, it's absolutely okay to store images artifact in one table and other types in unified db
17:39:15 <mfedosin> that's why I'm confused by the phrase '"we can never use images as artifacts"'
17:39:36 <mfedosin> we can and we use :)
17:40:22 <mfedosin> I don't mind if image artifact type won't be merged initially, but in future we will need it
17:40:46 <mfedosin> btw, link to the spec:
17:40:49 <mfedosin> #link https://review.openstack.org/#/c/283136/
17:41:17 <nikhil> what you are saying is that glare will use glance db for accessing images
17:41:50 <nikhil> but there won't be a artifact called images (which will be same as other artifacts, given images will need workarounds)
17:42:21 <nikhil> this means cinder volumes and nova images can never be separate entities
17:43:34 <mfedosin> hm... we can store images artifacts in images tables easily
17:43:50 <mfedosin> yes, some workarounds are required, but it's not hard
17:44:18 <mfedosin> more over, we've already implemented an adapter for images
17:44:57 <mfedosin> and if you look at my old demos you'll see that glare is able to work with images in parallel with glance
17:45:24 <nikhil> mfedosin: sure, impl wise I've seen it work and that means it's not hard initially, but in the long run it's a load on maintenance. also, I don't think there's been enough knowledge sharing for that sort of logic to be maintained by the large group so I dunno what the plans are and what people are agreeing to.
17:45:55 <nikhil> I don't think a compat layer in glare for images API is okay
17:46:06 <nikhil> in the future, if we glare need to operate on images, I think the community needs to take that decision. the upload/download of images is a controvetial topic and the reference implementation of the images API is in glance
17:46:29 <mfedosin> anyway we have to implement image artifact type for app-catalog
17:46:36 <nikhil> if there are multiple implementation of the same thing (without compatibility), we will have trouble with interop, adoption, etc.
17:46:59 <nikhil> mfedosin: what you are saying is a requirement, it's not an agreement.
17:47:29 <mfedosin> there are fewer changes between glare/glance v2, than glancev1/glance v2 :)
17:47:51 <nikhil> I don't think glance v1/v2 and glare can be compared
17:48:08 <nikhil> we have communicated clearly that glance v2 is the long term support version of the images api
17:48:38 <nikhil> so, we cannot have another implemtation in the near future that will be drastically different
17:49:11 <mfedosin> yeah, I agree
17:49:13 <nikhil> especially when they different fundamentally like dependency mgmt (w/o immutability)
17:49:24 <mfedosin> I mean, no one forces to use glare as a replacement for glance
17:49:46 <mfedosin> and enable image artifact type on their clouds
17:50:02 <nikhil> yeah and that's the conversations I'm trying to have with DefCore who are very against two different types of API for the same thing.
17:50:35 <nikhil> they are against this approach for simply import, so they will be very against such for a complete service.
17:51:00 <nikhil> there are many reasons for that, one of the imp ones being 'adoption and interop'.
17:51:30 <mfedosin> btw, how work for image-import-refactoring is going?
17:51:49 <nikhil> we are discussing a few blockers due to their testing constraints atm
17:52:23 <mfedosin> with whom?
17:52:39 <nikhil> I plan to propose a declaration of intent based on the updates this week and hopefully we will have a sync with them before their midcycle.
17:54:16 <mfedosin> that's great :)
17:54:38 <mfedosin> so, let's decide something with the spec
17:55:02 <mfedosin> what should I add/change there to make it merged?
17:55:24 <mfedosin> your comments make sense, but some of them are not relevant to the spec
17:55:33 <mfedosin> especially swift config
17:55:47 <nikhil> mfedosin: please respond with your comments on the spec, I think the API by itself looks great but we just need to come to consensus. if we can by tomorrow COB, we should have a spec merge before n2.
17:56:02 <mfedosin> cool!
17:56:21 <nikhil> mfedosin: that's okay if they are not related, kairat asked me to add them to the spec so that they can be discussed.
17:56:22 <mfedosin> I'll answer you immediately
17:56:44 <nikhil> mfedosin: you can find the full convo from thurs as per link provided in the comments.
17:56:53 <nikhil> thanks.
17:57:22 <mfedosin> about oslo.vo and upgrade path...
17:57:41 <mfedosin> Stan Lagun has already asked about it
17:58:16 <nikhil> sure, I just posted my questions. you can say where you have added comments and if they are relevant I won't reraise.
17:58:17 <mfedosin> oslo.vo supports hooks for upgrading artifacts with different versions
17:59:03 <mfedosin> We follow standard oslo.vo recommendations here. In simple cases we can rely on coercing (so, if type was changed from integer to string, then values will be automatically cast by oslo.vo: for example 123 to '123'). In complicated cases, when oslo.vo coercing is not enough, artifact type author has to take care about version compatibility and implement method 'obj_make_compatible' https://github.com/openstack/oslo.versionedobjects/blob/m
17:59:04 <mfedosin> aster/oslo_versionedobjects/base.py#L478
17:59:17 <mfedosin> https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/base.py#L478
18:00:08 <mfedosin> okay, we're out of time
18:00:26 <mfedosin> thanks for your reviews again nikhil!
18:00:34 <mfedosin> #endmeeting