14:01:01 <nikhil_k> #startmeeting glance drivers
14:01:02 <openstack> Meeting started Tue Jul 21 14:01:01 2015 UTC and is due to finish in 60 minutes.  The chair is nikhil_k. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:05 <openstack> The meeting name has been set to 'glance_drivers'
14:01:09 <nikhil_k> Courtesy Glance Drivers' meeting reminder: nikhil_k, flaper87, sigmavirus24, rosmaita
14:01:15 <nikhil_k> #topic agenda
14:01:18 <nikhil_k> #link https://etherpad.openstack.org/p/glance-drivers-meeting-agenda
14:02:01 <jokke_> o/
14:02:22 <rosmaita> o/
14:03:04 <nikhil_k> Welcome guys
14:03:04 <ativelkov> o/
14:03:13 <rosmaita> i looked at the specs i promised to review last week, but must admit that i didn't get to today's specs
14:03:30 <nikhil_k> We've a few important items to discuss
14:03:51 <nikhil_k> rosmaita: no worries, I encouraged people to add items to push them through early if they were interested
14:04:03 <nikhil_k> Let's get started
14:04:07 <nikhil_k> #topic Feedback on the oslo.versionedobjects
14:04:28 <nikhil_k> ativelkov: gave us some updated in the artifacts sync up yday
14:04:51 <nikhil_k> there were a few things that would be good to be discussed here so I asked him to add this item
14:05:22 <ativelkov> I've contributed most of the complicated validation logic which we had in "declarative framework" into the o.vo. Part is already merged, two more are on review there
14:05:26 <nikhil_k> basically,  early feedback on the overall approach and direction
14:05:46 <nikhil_k> #link https://review.openstack.org/#/c/198798/
14:06:55 <ativelkov> This is an initial commit which actually declares the types to define artifact properties and defines the generic artifact properties using them.
14:07:24 <ativelkov> Looking for the initial feedback on this before I move on and the patch becomes some hundreds LoC more :)
14:08:23 <nikhil_k> ativelkov: can the fields be inheritable?
14:08:29 <nikhil_k> basically nesting
14:08:44 <nikhil_k> for example a list of tuples
14:08:46 <ativelkov> nikhil_k: yes, this is part of o.vo basic functionality
14:08:50 <jokke_> you lost me already here: declares the types to define artifact properties and defines the generic artifact properties :P
14:09:12 <ativelkov> my english ) Sorry
14:09:36 <jokke_> no worries, not important :)
14:10:01 <ativelkov> Well there are "Fields" (like "Integer", "String", "Array", "Set" etc), and type definitions, which combine these fields to form an artifact schema
14:10:26 <ativelkov> Array or Set or Dict fields may be of elements of other types
14:11:16 <nikhil_k> ativelkov: sorry I don't get if this indicates that https://review.openstack.org/#/c/198798/3/glance/artifacts/types/base.py ?
14:11:23 <nikhil_k> or are you working in that direction?
14:11:50 <ativelkov> nikhil_k: indicates what?
14:11:58 <nikhil_k> ativelkov: Array or Set or Dict fields may be of elements of other types
14:13:14 <ativelkov> No issues here. This file is just a base class common for all the artifacts. There are no common properties of type Array or Dict (yet there is a "tags", which is a Set of Strings)
14:13:23 <nikhil_k> ativelkov: nvm, I see the compond obj now
14:13:29 <nikhil_k> compound*
14:13:44 <nikhil_k> line 93 https://review.openstack.org/#/c/198798/3/glance/artifacts/types/fields.py
14:14:13 <nikhil_k> ok, that was my intial browse and it looks good
14:14:30 <nikhil_k> I guess you can keep poking people here or in other meetings as development happens
14:15:08 <nikhil_k> If there's nothing more, we need to move on in the interest of time
14:15:26 <nikhil_k> #topic OVF-Lite BP to handle upload of OVF container for single disk image OVAs
14:15:27 <ativelkov> sure, thanks
14:15:35 <nikhil_k> #link https://review.openstack.org/#/c/194868/
14:17:14 <nikhil_k> This is a big one. We need to define the scope of this before approving it. I say that because we agreed on the idea that this proposal looks good for an intial basic impl in v2. More complex one can follow as a part of artifacts.
14:19:45 <nikhil_k> I browsed over it and ignored any minor errors. lgtm as problem desc and work items are precise.
14:20:21 <nikhil_k> #action all: priority review for the week https://review.openstack.org/#/c/194868
14:20:34 <nikhil_k> we can approve it next week
14:20:49 <nikhil_k> #topic Federated Images
14:21:02 <nikhil_k> #link https://review.openstack.org/#/c/191897/
14:22:07 <nikhil_k> tbh, I am not sure if this is the right way to go (in a dilemma)
14:22:44 <nikhil_k> Also, the scope if too broad. We need to trim down the spec to actionable work items for a single cycle.
14:24:22 <jokke_> nikhil_k: that sounds like brilliant first candidate for our import task plugin incubator :P
14:24:25 <nikhil_k> Two things that need to go in there are: 1) more decriptive problem description 2) breakddown of the work items into anticipated code changes (besides a broader feature enhancement perspective)
14:24:35 <jokke_> nikhil_k: sorry being late OVF stuff I mean
14:24:44 <nikhil_k> jokke_: ah yeah, def
14:24:52 <rosmaita> jokke_: +1
14:25:17 <nikhil_k> Any feedback on federated images for today?
14:25:55 <nikhil_k> If nothing, I will open up the discussion.
14:26:05 <nikhil_k> #topic open discussion
14:26:35 <nikhil_k> So, I would like encourage people to attend the mid-cycle at least virtually (next week)
14:26:49 <nikhil_k> we should discuss the specs process evolution and finalize the documentation
14:26:58 <jokke_> sorry I'm really slow today ... just comment on the federated image
14:27:03 <nikhil_k> so that it's not stuck in some ML thread or pending review somewhere
14:28:06 <jokke_> before we start even thinking 2 glance deployments talking to each other, as a first stem I'd like to see export/import that could be used for that ... so that we can export image from one glance instance and import it to another ... lets talk how we automate that delivery in between after that
14:28:32 <jokke_> first step even
14:29:27 <nikhil_k> jokke_: I see your point. Though I think this was to extend implementing cloning as a third type of task. But it would good to have first import/export working
14:30:08 <nikhil_k> One thing I missed to updated earlier
14:30:24 <jokke_> nikhil_k: I'd like to see cloning moving to utilize that as well so we could just dump that really messy cloning logic we have instead of extending it
14:30:29 <nikhil_k> I have asked a couple of documentation folks to help keep our specs cleaner
14:31:07 <nikhil_k> Hope to hear from them this week and update next week (midcycle).
14:31:23 <nikhil_k> jokke_: it could make sense to keep common logic together
14:31:33 <nikhil_k> We are out of time
14:31:38 <nikhil_k> Thanks all for joining.
14:31:47 <nikhil_k> #endmeeting