14:01:31 <markwash> #startmeeting glance
14:01:31 <scottda_> hi
14:01:31 <openstack> Meeting started Thu Mar 13 14:01:31 2014 UTC and is due to finish in 60 minutes.  The chair is markwash. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:34 <openstack> The meeting name has been set to 'glance'
14:01:36 <flwang> arnaud: welcome to join the team, though you're already at here
14:02:16 <markwash> team meeting agenda follows
14:02:18 <markwash> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:02:24 <markwash> but there's not much there yet
14:02:48 <markwash> I'll say a few quick project-y update things and then yield to other agenda items
14:03:00 <markwash> as a warning, I need to leave at 45 past the hour
14:03:12 <markwash> so, we are in feature freeze, as everyone knows
14:03:22 <markwash> we can still fix bugs or tweak tests
14:04:01 <markwash> if there are any especially important bugs, please mark their priority accordingly and put them into the icehouse-rc1
14:04:27 <markwash> https://launchpad.net/glance/+milestone/icehouse-rc1
14:05:02 <markwash> that's about it from me
14:05:32 <markwash> we have one agenda item otherwise so far
14:05:45 <markwash> #topic vm template support
14:05:53 <markwash> who will start us off on this topic?
14:05:56 <arnaud> markwash: the deadline for rc1 is April 17th?
14:06:16 <zhiyan> it's trying to figure out a way to make vm template support in glance, then nova could provision vm from it.
14:06:24 <arnaud> or March 27th
14:06:28 <arnaud> https://wiki.openstack.org/wiki/Icehouse_Release_Schedule
14:07:20 <markwash> arnaud: ideally march 27th but there is a window in there for rc2/rc3 as needed
14:07:32 <arnaud> got it
14:07:38 <markwash> sorry zhiyan, go ahead
14:08:52 <zhiyan> IMHO we can use existing location mechanism to implements it. i have wrote the whole design in the etherpad, like to know team's input/comments.
14:10:13 <markwash> it seems similar to what was being discussed around artifacts -> server templates
14:10:32 <markwash> I'm not sure I like putting more overloaded meanings into the existing image schema
14:11:05 <arnaud> I think the key point here is that for a template the location would redirect to a metadata file and not the actual image
14:11:13 <zhiyan> probably artifacts could cover this case, but iiuc, current it's not clear
14:11:26 <arnaud> it is supposed to be the case for ovf in the current implementation, but afaik ovf is not used anywhere
14:11:53 <markwash> oh, also I might be mistaken. . are VM templates a specific technology?
14:11:59 <zhiyan> arnaud: yes, but as we discussed, if artifacts does not support >1 bulks, the similar limitation will be happened as well
14:12:20 <zhiyan> yes, hypervisor specified
14:12:36 <arnaud> markwash: vmware specific at this point
14:12:41 <arnaud> there is also for hyper-v
14:12:44 <arnaud> for sure
14:13:01 <arnaud> but it seems like it would be hard to find a representation that satisfies both
14:13:12 <markwash> zhiyan: artifacts will definitely support >1 bulk data components I believe
14:13:20 <markwash> it depends on the schema of the artifact type
14:13:59 <zhiyan> markwash: ok. so do you think we should going to wait artifacts? and make template concept fit it?
14:13:59 <ativelkov> by "bulk data components" you mean the binaries?
14:14:08 <markwash> ativelkov: yup
14:14:25 <ativelkov> As I see them - yes, they should
14:14:35 <flwang> zhiyan: for short term, any known issue if we just leverage the multi location to implement the template?
14:14:44 <arnaud> zhiyan: we could have VMwareTemplateArtifact, HyperVArtifact if both of them cannot be represented in 1 model
14:15:18 <markwash> zhiyan: I think part of the motivation for artifacts is that its very hard to put all of these types of things in the same schema
14:15:27 <markwash> disk images, vm templates, etc
14:15:38 <ativelkov> However, the exact amount of them should be defined by the particular plugin
14:15:40 <zhiyan> markwash: arnaud, ativelkov: seems we need a clear doc to know its details
14:16:02 <markwash> it should give us the opportunity to expand out from a single type of object, while simultaneously increasing the clarity around each type of object
14:16:02 <arnaud> +1
14:17:24 <zhiyan> is there a doc to introduce artifacts current design/shape?
14:17:38 <ativelkov> I am writing the API spec at apiary
14:18:05 <zhiyan> i'm ok if team like to go artifacts way.
14:18:43 <markwash> so if we use locations for this, the idea is to have one location be the template metadata and other locations be any disk images that are needed?
14:19:04 <zhiyan> markwash: no.
14:19:10 <flwang> markwash: I think there is no disk image
14:19:21 <arnaud> flwang: there is *-flat.vmdk
14:19:24 <zhiyan> markwash: all the location point to metadata
14:19:25 <ativelkov> http://docs.artifacts.apiary.io
14:19:25 <ativelkov> But it is still a work in progress
14:19:25 <ativelkov> And I definetly have to update the FAQ page
14:19:35 <flwang> arnaud: on glance side?
14:19:41 <zhiyan> markwash: for vmware case, it's VMTX file
14:19:46 <arnaud> oh sorry I meant in the template
14:19:49 <zhiyan> but disk (vmdk) file
14:20:04 <flwang> arnaud: ok
14:20:11 <rosmaita> fwiw, my opinion is artifacts: +1, locations: -1
14:20:20 <markwash> how could it work if there are no disk images? wouldn't a useful template refer to a disk image somewhere?
14:20:50 <arnaud> the metadata file refers to the disk markwash
14:20:54 <zhiyan> markwash: under my idea, those disk files are already been stored in backend
14:21:22 <arnaud> the vmware driver in nova can leverage the location of just having the *.vmtx afaik
14:21:26 <zhiyan> markwash: in vmware case, those vmdk files which belongs to template are all be pre-prepared in datastore
14:21:34 <zhiyan> arnaud: yes, a handler
14:21:52 <zhiyan> arnaud: oh, maybe not. we can do it in driver directly
14:22:01 <zhiyan> arnaud: sorry, i mean leverage "clone" api
14:22:17 <arnaud> zhiyan: yes
14:22:29 <zhiyan> anyway, those functions will use standard glance api, leverage location information
14:22:50 <markwash> it seems like those image data references would do better living in the api than in a file you retrieve from the api
14:23:21 <hemanth> haha/win 41
14:23:25 <hemanth> oops
14:24:06 <zhiyan> markwash: iiuc, this vm template case is very similar with current OVF case
14:24:13 <arnaud> markwash: I think the question is also to know when we expect the artifacts to be implemented
14:24:35 <zhiyan> arnaud: and how to be implemented
14:25:58 <ativelkov_web> sorry folks, my irc proxy suddenly died
14:26:06 <arnaud> ativelkov_web: what is your timeframe for artifacts?
14:26:17 <arnaud> you expect it to land in juno?
14:26:29 <markwash> I guess it seems like supporting ova makes sense in the short term
14:26:51 <markwash> but supporting other true template formats rather than container formats really conflicts with the artifacts approach
14:26:57 <ativelkov_web> arnaud: yes
14:27:08 <markwash> the goal of which is to make things like instance templates totally above-board, rather than hiding them down in the image format
14:27:42 <ativelkov_web> In short-term I plan to complete the API spec draft by the mid of next week. Want to discuss it on the next meeting and start implementing
14:28:17 <arnaud> ativelkov_web: I fear that there will be a lot more discussions than just a week
14:28:49 <markwash> it is likely
14:29:08 <ativelkov_web> arnaud: sure. I mean, it takes too long for the initial draft, so I want to complete it asap
14:29:18 <ativelkov_web> Then the discussion will take what it takes
14:29:23 <arnaud> ok ok
14:29:25 <markwash> the issue with using a template as the image data is that when you delete the template, glance will not delete any of the underlying disks
14:29:34 <markwash> e.g.
14:29:38 <zhiyan> ativelkov_web: thanks
14:29:46 <markwash> but I suppose I'm going a bit farther than is needed
14:30:02 <zhiyan> markwash: nod, it's valid point
14:30:30 <zhiyan> markwash: and seems OVF has same "problem", for delete case
14:30:36 <markwash> zhiyan: yes
14:31:07 <flwang> markwash: so can the artifacts approach resolve this issue?
14:31:11 <zhiyan> ok, np markwash, seems you like to see it wait a while?
14:31:17 <markwash> flwang: yes, definitely
14:31:56 <markwash> jbernard was pursuing something along these lines
14:32:15 <zhiyan> tbh, i think probably we need a whole J cycle to make artifacts feature be stable..
14:32:35 <markwash> that is most likely true
14:32:52 <ameade> +1, double whatever estimates we make
14:32:53 <markwash> but I'm happier with waiting for a objects that are well defined vs overloading more possible meanings into Images
14:33:13 <zhiyan> hmm..if so can we just try to do it by location approach first? (just a quick ask, not really sure for go that way)
14:33:19 <ativelkov_web> What I want is to have some MVP to work by the end of J
14:33:32 <ativelkov_web> so other projects may start using it
14:33:39 <rosmaita> zhiyan: -1 locations for this
14:34:00 <zhiyan> rosmaita: noticed
14:34:10 <rosmaita> :)
14:34:21 <markwash> yeah I don't want to see locations used for this either
14:34:31 <markwash> I'm not sure locations can even help us with multiple formats at this point
14:34:44 <zhiyan> rosmaita: anyway actually i think even it be there (with location way), the result just like OVF, not a big deal
14:34:47 <markwash> the images resource that locations live in just prevents it, it cannot be extended in this way
14:35:11 <zhiyan> and artifacts can make it again if we like, by a plugin iiuc
14:35:49 <markwash> zhiyan: I guess I was not aware we were using ovf quite in this manner
14:35:51 <zhiyan> ok, i got it.
14:36:25 <arnaud> markwash: I don't think the ovf container format is used in nova
14:36:48 <zhiyan> arnaud: yes, it's sure currently
14:36:57 <arnaud> ova will be in Juno for the vmware driver
14:38:09 <markwash> ova and ovf are different though in terms of how the disks are stored, correct?
14:38:29 <zhiyan> arnaud: ova is cool, but i think a key situation is that there are a lot of vm template in customer's exist deployment.
14:38:38 <markwash> let's take this offline as needed, I think we've reached a conclusion for the moment
14:38:42 <markwash> #topic open discussion
14:40:37 <zhiyan> markwash: seems glance v2 stuff in nova is turning to a big blocker for us..
14:41:11 <markwash> yes, our deprecation plans are back quite a bit now
14:41:25 <zhiyan> markwash: it failed our all interesting stuff
14:41:39 <markwash> though I suppose that with the way the nova v2/v3 discussion is going perhaps we should revisit the plan
14:42:06 <zhiyan> https://blueprints.launchpad.net/nova/+spec/use-glance-v2-api
14:42:39 <zhiyan> i'd like to do some works for that, to make it landing asap
14:43:14 <ameade> markwash: is the way that is going is to hold off on v3?
14:44:05 <arnaud> zhiyan: +1!
14:44:09 <markwash> that was the sense that I got but I kinda dropped off the thread after the 100th message
14:44:12 <zhiyan> arnaud: he
14:45:07 <ameade> markwash: i think it's good for us to pay attention to how hard it is to change versions across the board
14:45:14 <markwash> yeah
14:45:25 <markwash> and to think about all the client libraries out there in the world :-/
14:45:47 <ameade> heh yeah
14:46:06 <flwang> markwash: so how about just combine all the client library like I mentioned with you?
14:46:38 <flwang> markwash: and hide the difference between api version in the common library
14:46:43 <flwang> for now and future
14:46:47 <ameade> zhiyan: we should ask esheffie1d what the status is on that, shouldn't be too far off
14:47:09 <zhiyan> ameade: yes, but i already synced up with him on my morning
14:47:11 <markwash> flwang: I think that's an important strategy
14:47:25 <markwash> I was also thinking of jclouds which I've been having to use recently
14:47:32 <markwash> anyway, I have to go catch a bus
14:47:35 <markwash> thanks everybody
14:47:35 <flwang> markwash: yep, but if it's right, why not?
14:47:37 <zhiyan> ameade: actually i have already put two "pull-request" patchs there, to follow his current change.
14:47:48 <markwash> thanks zhiyan for the discussion
14:47:51 <markwash> #endmeeting