20:00:05 <markwash> #startmeeting glance
20:00:06 <openstack> Meeting started Thu Apr  3 20:00:05 2014 UTC and is due to finish in 60 minutes.  The chair is markwash. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:10 <openstack> The meeting name has been set to 'glance'
20:00:15 <markwash> roll call!
20:00:16 <markwash> o/
20:00:19 <arnaud> o/
20:00:23 <zhiyan> o/
20:00:26 <hemanth_> o/
20:00:43 <ameade> 0\
20:01:16 <markwash> lol ameade your emoticon greeting looks kind of like someone scratching their head :-)
20:01:20 <rosmaita> o/
20:01:31 <ameade> haha
20:01:52 <markwash> okay. . let's roll
20:01:59 <markwash> #topic project status updates
20:02:11 <markwash> probably you noticed, but we cut rc1
20:02:19 <markwash> so we're in business for juno development
20:02:25 <markwash> and feature freeze is over
20:02:30 <ameade> weeee
20:03:09 <markwash> we're still in that cold part where there may be important bugs we want to fix, so if we can hold off on being *too* dramatic in changes over the next few weeks, it might save someone work on backporting bug fixes
20:03:26 <markwash> but just keep that in mind for core reviewing
20:03:46 <markwash> any questions about the project status?
20:03:58 <markwash> or juno
20:04:16 <markwash> going
20:04:17 <markwash> goin
20:04:21 <markwash> gone
20:04:29 <markwash> #topic artifacts design doc
20:04:48 <markwash> I think we still need some sort of general communication about what the whole "artifacts" plan is
20:04:53 <markwash> so that people can get up to speed
20:05:04 <arnaud> agree
20:05:06 <markwash> gokrokve: ping
20:05:20 <gokrokve> Hi Mark!
20:05:35 <ameade> +1
20:06:02 <markwash> Hi gokrokve, how's it going?
20:06:06 <gokrokve> Alex is on vacation, so there is no any significant changes from the previous meeting.
20:06:30 <markwash> gokrokve: do you know when we expect him back?
20:06:47 <ameade> this is something we want implemented in juno right?
20:06:49 <gokrokve> Next week he will be available.
20:07:00 <arnaud> ameade: yes
20:07:09 <gokrokve> Yes. Here is API draft
20:07:10 <gokrokve> http://docs.artifacts.apiary.io/
20:07:39 <markwash> gokrokve: I don't suppose that api draft has seen a lot of changes since our in person discussion, has it?
20:07:55 <gokrokve> I delivered to him etherpad and qhiteboard with our API discussion for references
20:08:07 <gokrokve> No. There is no much chnages.
20:08:17 <markwash> okay cool
20:08:28 <markwash> so should we expect something more from him in 2 weeks?
20:08:43 <gokrokve> Here is the etherpad with more details about references: https://etherpad.openstack.org/p/glance-artifacts-discussion
20:09:07 <gokrokve> markwash: I think next week he will devote to Artifacts :-)
20:10:14 <markwash> okay, so folks who are interested can have a look at that etherpad which is a little bit scattered
20:10:35 <markwash> and otherwise we can hope for more specific documentation in a few weeks
20:11:07 <markwash> I will try to check in with ativelkov in time to give an update at next meeting of just where we're at
20:11:20 <markwash> any thoughts folks want to share on the artifacts stuff now?
20:12:22 <arnaud> gokrokve: can we discuss of what kind of progress we expect?
20:12:48 <arnaud> do we expect everything (db/api/business logic, etc) to be implemented by the end of juno?
20:12:59 <gokrokve> I think as master is opened for Juno contribution we will start implementation
20:13:06 <ameade> +1
20:13:13 <arnaud> do we expect only atielkov to work on the implementation?
20:13:16 <ameade> i would like some sort of schedule
20:14:29 <arnaud> this we can organize our respective schedules to be able to contribute when needed
20:14:29 <gokrokve> arnaud: No. There will be several engineers. But we need to finish Murano 0.5 which should be released in two weeks.
20:14:57 <arnaud> but then you will have Murano 0.x
20:15:12 <arnaud> will artifact be the priority over Murano?
20:17:04 <arnaud> basically my question is do you expect (code) input from Glance developers?
20:17:10 <markwash> gokrokve: not to hold your feet to the fire, but ^^ :-)
20:17:17 <arnaud> yeah :)
20:17:37 <markwash> I think there is some good build up of understanding among other glance devs as they are exposed to the artifacts idea
20:17:43 <markwash> and some design docs would push it further
20:17:50 <markwash> so there may be other resources that could be brought to bear
20:18:15 <gokrokve> arnaud: Yes. Artifacts right now have more priority then Murano. Just for IceHouse we had to implements it in Murano.
20:18:41 <arnaud> ok sounds good! :)
20:18:51 <gokrokve> I think we expect to have contribution to Artifacts from: Glance team, Murano and Heat teams
20:19:08 <markwash> there is a session proposed for artifacts discussion at the summit
20:19:20 <arnaud> yes actually
20:19:25 <arnaud> I wanted to bring this up
20:19:27 <markwash> it will be nice to have some late stage design / early stage code review at that time
20:19:30 <arnaud> is 1 session enough markwash ?
20:19:46 <markwash> arnaud: probably not
20:21:11 <markwash> okay, so I think we still have more questions than answers at this point, let's carry some of those forward into the next two meetings
20:21:25 <markwash> hopefullly with some more design inputs we can structure the summit session nicely
20:21:42 <markwash> any more thoughts folks want to share before we move on?
20:21:53 <markwash> thoughts/concerns
20:22:34 <gokrokve> I think we will have something like a final draft in two weeks.
20:22:50 <gokrokve> Then we can discuss it in ML and then on f2f meeting in Atlanta
20:23:31 <markwash> all right, thanks for the info gokrokve
20:23:51 <markwash> #topic deactivate image bp
20:24:02 <markwash> #link https://blueprints.launchpad.net/glance/+spec/deactivate-image
20:24:33 <hemanth_> should I give a brief background?
20:24:34 <markwash> so I think where we left off on this
20:24:40 <markwash> hemanth_: sure go for it
20:25:08 <hemanth_> so, this bp proposes to 'deactivate' a 'bad' image
20:25:27 <hemanth_> what does deactivate mean? prohibiting the download of such 'bad' images
20:25:54 <hemanth_> what does 'bad' mean? not sure yet, but when we find a suspicious image that was imported or crafted within the cloud
20:26:27 <hemanth_> most likely reported by ops/monitoring folks, we give them a way to inidicate that a particular image maybe bad
20:26:44 <hemanth_> and it shall not be used until futher investigation is performed on it
20:27:05 <hemanth_> after which, the image can activated again or deleted
20:27:11 <hemanth_> *be
20:27:27 <markwash> so its a little handwavy, but I want to give my blessing (fwiw) to the concept of deactivation
20:27:53 <markwash> its a reasonably general purpose, and my main concern was it would complicate the state transitions. . but turns out it does not complicate it
20:28:01 <markwash> a resource can only go from active to deactivated
20:28:09 <markwash> it will not be possible to deactivate an image that is in any other state
20:28:16 <rosmaita> +1
20:28:29 <markwash> (well, and it can go from deactivated to active, or be deleted)
20:28:38 <ameade> yeah i think this is a fair use case
20:29:01 <markwash> anybody have questions they want to raise about the use case?
20:29:20 <ameade> i am wondering if this would make sense to be used when you don't want people booting off an image in general but you still want to allow access to image metadata
20:29:29 <ameade> is it still true that you can do a show on a deleted image?
20:29:33 <ameade> perhaps we can change that
20:29:35 <hemanth_> ameade: yes
20:29:45 <markwash> ameade: yeah it feels like that is the right way to think about "deactivation"
20:29:49 <hemanth_> ameade: all operations except download are allowed
20:29:59 <ameade> cool beans
20:30:35 <markwash> hemanth_: one addendum, only users with certain roles can ever "reactivate" correct?
20:30:57 <hemanth_> markwash: yes, its an admin-only operation
20:31:26 <hemanth_> both de-activating and re-activating
20:31:35 <markwash> so, unless there are more use case questions, we can talk a bit about the api (whether or not to use PATCH)
20:31:35 <ameade> could this have it's own policy instead?
20:31:56 <ameade> kind of like 'publicize_image'?
20:32:04 <markwash> hemanth_: ameade: yes I was interpreting "admin only" as meaning it would actually have a policy on the operation
20:32:12 <hemanth_> ameade: +!
20:32:14 <zhiyan> i think dedicated api is better then PATCH api for status field changing
20:32:25 <hemanth_> +1
20:32:36 <ameade> hemanth_: make sure to lay out these clarifications in the bp
20:32:47 <ameade> it could help a bunch with docs later on
20:32:51 <hemanth_> ameade: sure, will do
20:33:22 <zhiyan> and i'm a little concerned on the direct changing of image model
20:33:25 <markwash> all right. . so lets now jump into the api
20:33:43 <markwash> #topic deactivate image api
20:34:24 <markwash> so the original bp proposed a dedicated api
20:34:32 <hemanth_> I am a little apprehensive about patch because it is not inconsistent with the way we deal with status in glance currently
20:34:34 <markwash> I think I pushed back and said "why not just use PATCH?"
20:34:46 <hemanth_> *is inconsistent
20:34:47 <zhiyan> actually i *think* probably the better way for this kind of functions is be placed as an extension for glance api
20:35:20 <nikhil__> well, this is a first level operation on the image
20:35:52 <markwash> a regular user still won't be able to modify status, correct?
20:35:52 <nikhil__> so, an extension would mean some level of value added service which does not fall in this category, right?
20:36:18 <hemanth_> markwash: yes
20:36:53 <markwash> it just seems inconsistent in API terms to have one way of updating one part of a json document, and another way to update the other part
20:37:03 <markwash> I think we have some of those inconsistencies already, but I'd rather not add to them
20:37:44 <markwash> but I guess the feeling on the other side is that status is special?
20:38:56 <markwash> just hoping to understand. . hemanth_ zhiyan rosmaita ^^
20:39:10 <rosmaita> well, i don't view the api as allowing json doc changes
20:39:18 <rosmaita> the json doc is a representation of the system
20:39:24 <rosmaita> that's why patch is so weird
20:39:32 <rosmaita> at least for me
20:39:55 <rosmaita> patch seems doc oriented, not resource oriented
20:40:07 <rosmaita> whereas API calls should be resource oriented
20:40:26 <markwash> interesting. . I think we share the same core view of the system in terms of the relationship of json to the actual features
20:40:42 <markwash> so I'm not quite sure yet where we diverge on PATCH :-)
20:40:56 <markwash> I think the idea is, you have a resource, you want to make changes to it
20:40:58 <ameade> so are we all saying no to PATCH?
20:41:07 <markwash> no no, sorry I'm still saying yes to Patch
20:41:18 <rosmaita> ameade: not "no" just "not liking it"
20:41:34 <markwash> I'm just trying to figure out precisely where our viewpoints diverge
20:41:35 <zhiyan> markwash: do you like see deactivation function as a "core" function around image resource?
20:42:26 <markwash> zhiyan: maybe, "core" in contrast with "extension" ?
20:42:37 <zhiyan> yes
20:43:13 <markwash> yeah, it feels like core to me
20:43:21 <markwash> its on the "edge" of "core" :-)
20:43:26 <markwash> to me
20:43:34 <zhiyan> imho, i think patch api is working for image main model: changing the fields of image object
20:44:47 <zhiyan> for the deactivation function, on implementation level, we can add a new status to "status" field of main model
20:45:07 <markwash> fwiw, my resistence to a separate api route for this is just that I want to be able to give a good explanation that I believe in when people ask me about it in the future
20:45:21 <zhiyan> or add a new table to do the deactivation status booking...
20:45:21 <markwash> :-)
20:45:58 <markwash> zhiyan: I think adding in a new status field to the main model is the proposed way of doing this bp
20:46:01 <markwash> hemanth_: ^^ correct?
20:46:07 <hemanth_> markwash: yes
20:46:14 <rosmaita> markwash: this is a very focused use
20:46:25 <rosmaita> patch is a very unfocused way of making changes
20:46:45 <rosmaita> at least that's how i see it
20:47:01 <ameade> i see it as changing the state of an image, and patch is how we do that
20:47:03 <markwash> I just see patch as a way of putting several modifications to the resource into a single transaction
20:47:04 <arnaud> rosmaita: could you explain why you are saying this in an unfocused way of making changes?
20:47:06 <ameade> so replace on status makes sense to me
20:47:32 <arnaud> +1 ameade
20:47:40 <rosmaita> arnaud: patch seems to open up everything for grabs
20:47:56 <rosmaita> so if we were allowing a lot of state transition changes, i could seee that
20:48:06 <rosmaita> but we just want active->deactivated and back
20:48:09 <rosmaita> nothing else
20:48:16 <rosmaita> it just seems different to me
20:48:39 <hemanth_> rosmaita: +1
20:49:03 <markwash> I'm not sure I'll quite find resolution to this in the next 12 minutes
20:49:09 <arnaud> :)
20:49:13 <ameade> heh
20:49:21 <rosmaita> i think by not using patch, we explicitly say "this is different"
20:49:30 <rosmaita> and we want this to be completely different
20:49:43 <zhiyan> tbh, i still think this function don't like a core function for image resource.. it's out of image object core CRUD function list
20:49:57 <zhiyan> to me
20:50:49 <ameade> it's an update in my mind
20:50:59 <markwash> yeah, same here
20:51:08 <markwash> and rosmaita why is it completely different?
20:51:20 <arnaud> the crud operation is update: not the state in which will be the resource
20:52:09 <rosmaita> markwash: because we have a nice state transition diagram for how images should work, and we are interferring with it (but in a very precise way)
20:52:20 <hemanth_> markwash: coz it is not in the usual lifecycle of an image?
20:52:36 <ameade> well isn't that what we are changing? the image state diagram?
20:52:45 <ameade> state machine*
20:52:47 <rosmaita> i'm afraid using patch will give peeple all sorts of great ideas of how to put all sorts of epicycles into the diagram
20:53:09 <rosmaita> maybe it's just a matter of taste
20:53:18 <markwash> lol epicycles :-)
20:53:23 <hemanth_> markwash: this is like temporary state we keep an image in, like an off-the-band thing
20:53:24 <markwash> great reference!
20:53:24 <zhiyan> i think the key reason you think it's "update" is that you are thinking this from implementation POV. but from enc user, i think image deactivation is a separated function from CRUD
20:53:59 <markwash> I think the administrator viewpoint is most relevant here
20:54:15 <ameade> it's all about how you word it, am i 'deactivating' an image or am i making it 'deactivated'
20:54:17 <markwash> to me, if they already know how to modify an image, why shouldn't this modification be just like the others?
20:54:36 <markwash> ameade: oh interesting point
20:54:38 <ameade> we are supposed to give a state to the api and the system takes care of it
20:55:08 <markwash> <joke> obviously the solution is to create a new HTTP verb </joke>
20:55:28 <rosmaita> markwash: MONKEY
20:55:48 <markwash> I don't mean to be pushy, but I think the burden is on the "update the image differently" side of the argument
20:55:54 <rosmaita> MONKEY /v2/images/UUID/changestatetodeactive
20:56:01 <markwash> lol
20:56:11 <rosmaita> markwash: as PTL, you can be pushy, that's ok
20:56:17 <markwash> I think we can move ahead with the implementation
20:56:31 <markwash> don't encourage me
20:56:33 <markwash> :-)
20:56:54 <rosmaita> thanks for standing again for PTL by the way
20:57:12 <arnaud> +1
20:57:23 <markwash> well, you folks are a great bunch of people to work with
20:57:28 <ameade> i dont wanna make the RESTful argument but there are only four verbs and those are CRUD lol
20:57:29 <markwash> so thank you
20:58:16 <markwash> so to tidy up
20:58:23 <markwash> can we plan on PATCH for now?
20:58:30 <markwash> and bring up other objections later?
20:59:19 <markwash> or will that be a blocker for you hemanth_ ?
20:59:23 <hemanth_> markwash: ok, will try to find more onjections :_
20:59:24 <hemanth_> :)
20:59:32 <markwash> hemanth_: lol good enough
20:59:37 <markwash> okay we're about out of time
20:59:48 <markwash> everybody: vote for  the other guy
21:00:01 <ameade> lol
21:00:06 <markwash> sorry we missed on the taskflow discussion again
21:00:19 <markwash> I need to run
21:00:22 <arnaud> no problem
21:00:23 <markwash> #endmeeting