14:03:48 <markwash> #startmeeting glance
14:03:49 <openstack> Meeting started Thu Feb 13 14:03:48 2014 UTC and is due to finish in 60 minutes.  The chair is markwash. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:03:52 <openstack> The meeting name has been set to 'glance'
14:03:55 <flwang> \o/
14:04:15 <rosmaita> o/
14:04:20 <arnaud__> hi!!
14:04:27 <gokrokve> Hi!!
14:04:53 <jokke_> Ehlo
14:04:59 <markwash> Hi folks!
14:05:00 <flwang> rosmaita: morning
14:05:04 <hemanth_> 0/
14:05:12 <markwash> I was busy at the nova meetup yesterday and have not prepared the agenda very much
14:05:23 <markwash> hemanth_ has an item he woulld like to discuss
14:05:55 <markwash> and some time after that I'd like to run through the icehouse-3 blueprints again to see what progress we've made or if there are other changes we should make
14:06:24 <markwash> #topic suspending and image (hemanth_)
14:06:36 <markwash> hemanth_: would you like to introduce the idea?
14:06:40 <hemanth_> markwash: sure
14:08:03 <hemanth_> with import, we can see a wide range of images getting imported into the cloud. Most of these may be created outside the cloud and thereby may not be very trusted
14:08:53 <hemanth_> so, in the event we see a 'bad' image getting imported, we need a way to stop further operations on this image.
14:09:12 <hemanth_> like booting servers off of it and sharing it further with other users
14:09:51 <markwash> so is this sort of an admin api use case?
14:09:55 <rosmaita> i think it's not so much the import action itself, it's just the existence of a "bad" image in the cloud
14:10:01 <flwang> hemanth_: so it sounds like an admin operation
14:10:03 <flwang> ?
14:10:16 <rosmaita> could protect with policies
14:10:17 <hemanth_> markwash, flwang: one of the use cases admin bp, yes
14:10:20 <flwang> rosmaita: +1
14:10:41 <rosmaita> could also be a user-level operation in some clouds
14:11:04 <flwang> seems we should say the import action make the bad image possibility more bigger
14:11:16 <jokke_> How about user flagging possibility?
14:11:23 <markwash> if an image is suspended, no one can boot it? or no one its shared with can boot it?
14:11:27 <rosmaita> flwang: not necessarily, you can take a snapshot of a current server and shar that
14:11:38 <rosmaita> markwash: i think no one can boot it
14:11:52 <hemanth_> markwash: no one can boot it
14:12:06 <rosmaita> but we don't control booting, so i guess no one can download it?
14:12:25 <flwang> hemanth_: could we just mark the image with a reserved tag?
14:12:40 <zhiyan> rosmaita: and don't expose direct location maybe
14:13:22 <rosmaita> well, for this to be effective I guess no locations should be exposed
14:13:33 <arnaud__> is it the responsibility of Glance of checking if a guest OS is trusted?
14:14:03 <rosmaita> arnaud__: i don't think so
14:14:13 <flwang> arnaud__: +1, and I think it's hard to detect
14:14:21 <rosmaita> but we do need to supply a way to stop user of images under investigation
14:14:21 <Guest15113> arnaud__: no, however the catalog needs to have a way to flag that
14:14:30 <hemanth_> arnaud__: not glance's responsibility but we want glance to know abut such an image
14:14:48 <flwang> hemanth_: I agree from this POV
14:14:58 <rosmaita> all i can thnink of as a current option, is just delete the image
14:15:08 <flwang> nikhil__: hey there
14:15:10 <rosmaita> which is really bad in event of a mistake
14:15:15 <nikhil__> hey
14:15:21 <arnaud__> ok, so this might look silly but why would you keep this image in your cloud?
14:15:25 <zhiyan> actually i'm a little trend to think that client side, e.g. nova (or others like cinder ?) should also do some change to take care that flag..
14:15:27 <rosmaita> the other image statuses don't seem appropriate , e.g., queued
14:15:39 <rosmaita> arnaud__: in case you are wrong
14:15:49 <rosmaita> this is a public cloud use case, i guess
14:15:52 <zhiyan> like do a check before vm snapshot
14:16:11 <zhiyan> to prevent guest upload a bad image
14:16:12 <flwang> zhiyan: check what?
14:16:23 <rosmaita> zhiyan: what flwang said
14:16:27 <zhiyan> flag within the metadata
14:16:32 <hemanth_> zhiyan: if the instance was booted from a suspended image?
14:16:33 <markwash> darn it, I started talking in the wrong chat room :-(
14:16:41 <arnaud__> lol
14:16:41 <hemanth_> hah
14:17:07 <flwang> welcome back to earth, markwash
14:17:07 <zhiyan> hemanth_: i think it is
14:17:08 <nikhil__> arnaud__: to do more checks on the image and determine it's usability
14:17:10 <markwash> haha
14:17:30 <markwash> I was thinking, it seems like this could be done with protected properties and client-side behavior as well
14:17:57 <nikhil__> markwash: copy pasting your chat from other window
14:17:59 <markwash> it seems like restricting download is a bit heavy-handed
14:18:00 <arnaud__> nikhil__: ok so the admin is still able to download the image
14:18:14 <nikhil__> arnaud__: may be (optionally)
14:18:16 <arnaud__> nikhil__: otherwise, how can you check something that you cannot get
14:18:17 <arnaud__> :)
14:18:25 <zhiyan> markwash: (i'm thinking latter one maybe using image handler in nova...)
14:18:32 <hemanth_> markwash: +1 but that would be an implicit way of doing things maybe?
14:18:50 <nikhil__> arnaud__: yeah, something like that restricting the image to validator or auditor of some sort
14:18:57 <arnaud__> I see
14:19:04 <nikhil__> 09:15:14 [ markwash] its an interesting idea, its a bit hard to think of how it might work though, since it seems like glance doesn't really control the booting process
14:19:07 <hemanth_> markwash: like as a user if I see my image in state 'suspended' I would know there is something wrong
14:19:08 <nikhil__> 09:15:24 [ markwash] and restricting download is a bit heavy handed
14:19:11 <nikhil__> 09:15:46 [ markwash] maybe there could be a protected property "suspended" that nova would honor?
14:19:14 <nikhil__> 09:16:16 [ markwash] or something that functions equivalently?
14:19:18 <rosmaita> arnaud__ you could restrict/allow access by policies
14:19:35 <arnaud__> rosmaita: ok this makes sense
14:19:53 <markwash> hemanth_:  I think you could still see "suspended = yes" on the image
14:20:13 <flwang> FWIW, I think we need a way to avoid the bad image be spreaded
14:20:41 <rosmaita> markwash: i don't like the nova-honor-flag idea, if we know at the glance level that this is not a good image, should handle it here
14:20:43 <arnaud__> a bad image can be still shared?
14:20:50 <nikhil__> nope
14:20:56 <rosmaita> arnaud__ i think yes
14:21:05 <rosmaita> why not, no one can boot from it?
14:21:15 <zhiyan> flwang: avoid the bad image be used. usage including: download; direct access via location info; snapshot vm which based on that bad image...and others?
14:21:16 <rosmaita> and if bad, it will ultimately be destroyed
14:21:24 <rosmaita> if a mistake, un-suspend, and no harm done
14:21:32 <markwash> rosmaita: so suspended would prevent download and make sharing behave as 'private' ?
14:21:59 <flwang> markwash: sounds reasonable
14:22:07 <rosmaita> i don't know if we need to affect sharing
14:22:17 <flwang> it would a suspend/resume
14:22:26 <rosmaita> as long as you can't boot
14:22:32 <arnaud__> +1 flwang
14:22:41 <rosmaita> i'm thinking we don't have to make it too complicated
14:22:42 <markwash> I guess its just, there is no "image.boot" action :-)
14:22:54 <rosmaita> right, so that's why no-download
14:22:56 <flwang> rosmaita: I prefer to prevent sharing
14:23:01 <markwash> that's the only reason I feel a bit weird about it
14:23:14 <rosmaita> well, look at it this way
14:23:28 <rosmaita> booting is the thing we want to prevent ultimately
14:23:37 <rosmaita> but right now, we just don't want anyone using the image
14:24:00 <arnaud__> is you do an image-list, do you plan to have the image listed? yes I assume
14:24:13 <rosmaita> yes
14:24:15 <arnaud__> s/is/if
14:24:22 <flwang> arnaud__: yes, it will be there
14:24:41 <rosmaita> with status 'suspended' or 'inactive'
14:24:51 <markwash> well, the general problem description makes a lot of sense to me, and it seems like the proposed approach has merit
14:25:01 <flwang> flwang: and I would like to see there is a tag or property indicating the suspending status
14:25:02 <markwash> so, blueprint?
14:25:16 <flwang> rosmaita: are you saying add a new status?
14:25:30 <rosmaita> flwang: yes, that's what i think
14:25:34 <nikhil__> my assumption might be a bit pessimistic however, feel like we should not allow sharing
14:25:47 <rosmaita> need to settle whether that's a good idea befoe going to a bp, i think
14:25:55 <rosmaita> (a new status, i mea)
14:26:02 <rosmaita> s/mea/mean/
14:26:04 <zhiyan> probably adding a new status is a easy way to go: https://github.com/openstack/nova/blob/master/nova/compute/api.py#L600
14:26:04 <nikhil__> as that would mean that validator is being trusted and that may not always be true
14:26:36 <nikhil__> as we want to restrict bad images and allow "only" good images
14:26:46 <hemanth_> I like adding a new status
14:26:51 <nikhil__> all shades of gray should be considered bad images, no?
14:26:55 <markwash> rosmaita: I think we can go with the new status strategy as the currently planned approach and write up the blueprint and spec?
14:27:11 <rosmaita> hemanth: want to work with me on this?
14:27:15 <markwash> we also need to think about how users will find out about this, probably through nova or cinder
14:27:19 <hemanth_> rosmaita: gladly
14:27:22 <zhiyan> hemanth_: so i think it will be better if you can create a bp, and give a definition for "suspend".
14:27:33 <rosmaita> zhiyan: +1
14:27:40 <hemanth_> zhiyan: sure
14:27:43 <markwash> I think you should also consider the case of nova server rebuild
14:27:49 <flwang> markwash: and I would like to see some thoughts from the consumer POV
14:27:59 <flwang> such as Nova, Ironic..
14:28:14 <zhiyan> flwang: and cinder
14:28:15 <rosmaita> ok, we will add some options
14:28:22 <zhiyan> image <==> volume conversion
14:28:22 <markwash> okay, next up
14:28:39 <markwash> #topic status checkin for artifacts api
14:29:27 <markwash> jbernard: i have not had time to digest your email
14:29:39 <gokrokve> Hi
14:29:45 <markwash> gokrokve: hi there!
14:29:49 <gokrokve> We have submitted couple new BPs
14:29:52 <jbernard> markwash: the response was good, a few minor issues
14:30:02 <arnaud__> gokrokve: could you share URL here?
14:30:46 <gokrokve> https://blueprints.launchpad.net/glance/+spec/artifact-repository-api
14:32:40 <gokrokve> Hm. There should be another BP for datamodel, but I don't see it.
14:32:45 <gokrokve> I will open it.
14:32:47 <markwash> so it looks like we're making some progress in the design phase
14:33:06 <markwash> gokrokve: based on our discussions I'll be very easy to see the data model bp :-)
14:33:08 <iccha_> hey
14:33:28 <gokrokve> Yes. We have a question about storage.
14:33:31 <flwang> iccha_: hey there
14:33:33 <arnaud__> hi iccha_!
14:33:50 <gokrokve> I think it will be possible to use existing storage drivers to store artifacts.
14:34:03 <jbernard> i hope so :)
14:34:16 <gokrokve> Great. So we will abb BP for that too.
14:34:17 <zhiyan> gokrokve: do you think if we need some new interface to store driver?
14:34:45 <gokrokve> zhiyan: No. Artifacts itself just text files or binaries.
14:34:54 <markwash> okay cool
14:34:54 <zhiyan> gokrokve: thanks
14:35:08 <markwash> so more blueprints from gokrokve
14:35:24 <markwash> and jbernard after a little more feedback on the instance template stuff will share it a bit more widely
14:35:27 <markwash> sounds good to me
14:35:36 <gokrokve> As I see now, artifact will be parsed by plugin during upload and then glance will store it as a solid entity.
14:35:38 <zhiyan> gokrokve: but iirc, you had mentioned versionning, maybe it's another case..
14:35:46 <jbernard> yep, i think it should come together nicely
14:36:02 <arnaud__> gokrokve: what do you mean by solid entity?
14:36:29 <gokrokve> Glance do not split or modify them for storing.
14:36:57 <rosmaita> gokrokve: +1 for solid entity
14:37:16 <arnaud__> does that mean that if an artifact contain (1 metadata file, 1 binary, 1 image) it will be a solid entity?
14:37:28 <zhiyan> A little confused on "plugin", glance now doesn't support api extension/plugin mechanism
14:37:40 <gokrokve> Yes, it should be apackage which has one ID.
14:37:51 <markwash> well, I think there's a lot of details we'll need to see in the context of the blueprints
14:37:57 <gokrokve> zhiyan: We plan to add this in artifacts API
14:38:01 <markwash> its a little confusing to find out about them trickle by trickle
14:38:13 <arnaud__> but can you still access only the metadata file for example, without accessing the binary?
14:38:13 <flwang> markwash: it would be nice if there is a wiki page associated with the bp
14:38:36 <flwang> arnaud__: let discuss the details in Glance channel?
14:38:41 <arnaud__> yes
14:38:42 <arnaud__> sure
14:38:49 <gokrokve> arnaud__: I dont think so. Metadata will be stored separately
14:39:16 <jbernard> it will be nice when this is all documented
14:39:25 <flwang> gokrokve: yep, since glance can store metadata
14:39:37 <gokrokve> The idea was that Glance artifact plugin can parse artifact content ant pass some data to associated metadata
14:39:48 <markwash> for my part, I pitched the instance template idea somewhat here at the nova meetup
14:39:54 <markwash> and it was met with some support
14:40:10 <markwash> it seems like once we get it going, we can add a nova extension that allows booting through instance templates
14:40:13 <rosmaita> it might be good to do a FAQ on this so we can ask questions and see the vision on one page
14:40:24 <gokrokve> jbernard: Sure. We are working on that. We had no much time for that during this week as we are working on Murano incubation documents now.
14:40:32 <flwang> markwash: sounds cool
14:40:32 <markwash> and it should not require a ton of internal nova changes
14:40:33 <arnaud__> flwang: I have the ovf use case in mind and I would like to store the ovf and the image associated as an artifact. In this case I don't want the ovf to be stored as metadata. I want to make sure this use case is covered
14:40:45 <markwash> re FAQ and more documentation, I don't really think we should do design review in this meeting
14:40:48 <zhiyan> markwash: so mark, i think seems we'd better start to think about plugin framework for glance .. seems, for now i'm not sure the "plugin" in this context is working on which level
14:41:03 <markwash> mostly just checking in to see what folks are working on, and do the design review with documents offline
14:41:10 <flwang> arnaud__: I was thinking the ovf case as well, we can discuss that offline
14:41:20 <arnaud__> flwang: yes sure :)
14:41:23 <flwang> arnaud__: I think it's not very related to this, right?
14:41:24 <markwash> zhiyan: yes, its unclear from the details given here, but I believe the plugin aspect will make plenty of sense later
14:42:04 <arnaud__> flwang: I think we need more details about the scope of artifacts. so let's wait for some initial doc :)
14:42:15 <markwash> let's have a look at blueprints for icehouse-3
14:42:20 <markwash> #topic blueprints for icehouse-3
14:42:26 <zhiyan> markwash: i just think this part seems is  dedicated then artifacts api
14:42:38 <markwash> #link https://launchpad.net/glance/+milestone/icehouse-3
14:43:09 <markwash> nikhil__: any new work available for async / export / import?
14:43:21 <markwash> is it more obvious now which of those bps should be in icehouse and which should not?
14:44:06 <nikhil__> markwash: we found some more complications added to both import and export script which was demonstrated in the summit (it's still internal)
14:44:28 <nikhil__> I'm working through it to fiure out how and what we can scrap things from it to make them pluggable
14:45:04 <markwash> nikhil__: previously we said maybe the async bp could be dropped and track the work under "import" does that sound okay?
14:45:09 <nikhil__> so, in short did not get enough time to push up a new MP however, have come to a better idea of what needs to be done
14:45:44 <nikhil__> markwash: many of the previous MPs are under that so, may be move them or rename it?
14:45:52 <nikhil__> not sure how the process works
14:46:13 <nikhil__> that = async bp
14:46:18 <markwash> are the MPs still out and active in gerrit?
14:46:23 <markwash> or are these ones that have merged?
14:46:26 <flwang> nikhil__: maybe you just need to update the commit message?
14:46:33 <nikhil__> yeah, the merged ones
14:46:43 <markwash> for merged ones it doesn't matter
14:46:46 <nikhil__> and one of flwang's glanceclient MP is out in gerrit
14:46:49 <flwang> nikhil__: I don't think we need care aout the merged
14:47:05 <markwash> okay, then I'm going to mark asynch as superceded by import
14:47:15 <nikhil__> sure
14:47:15 <flwang> nikhil__: we can just leave the glance client patch there
14:47:20 <markwash> moving on to glance.stores
14:47:31 <markwash> flaper87: you've put together some documents about the glance.store approach
14:47:36 <markwash> I have not digested them yet
14:47:48 <flaper87> markwash: yup
14:47:57 <flaper87> I linked it to the blueprint
14:48:02 <markwash> cool
14:48:05 <flaper87> in case other folks want to chime it
14:48:07 <flaper87> in
14:48:22 <flaper87> I'd love to have some feedback from other folks
14:48:25 <markwash> #link https://etherpad.openstack.org/p/glance-store-package
14:48:32 <flaper87> about the migration plan I wrote there
14:49:02 <markwash> sounds good, let's take the feedback onto some designated section of the etherpad, if that's okay
14:49:07 <markwash> and we'll leave this one in
14:49:26 <markwash> #topic image location status property
14:49:37 <markwash> it looks like the code was updated and some merged for the migration, correct?
14:49:43 <markwash> zhiyan: ^
14:50:10 <zhiyan> markwash: yes just been merged (and catch a race condition bug)
14:50:26 <markwash> zhiyan: all the code for this is up for review now, correct?
14:50:38 <markwash> so I could mark the blueprint as "needs code review"
14:50:43 <zhiyan> markwash: YES, pls folks give reviews thanks
14:50:54 <markwash> zhiyan: thanks!
14:50:55 <zhiyan> markwash: thanks mark
14:51:25 <markwash> #topic virtual image size
14:51:27 <markwash> #link https://blueprints.launchpad.net/glance/+spec/split-image-size
14:51:28 <nikhil__> win 26
14:51:49 <markwash> flaper87: it looks like you have code up for both the migration and api bits
14:51:54 <markwash> so this just needs review as well?
14:52:09 <flaper87> markwash: it was actually approved earlier today but it conflicted with zhiyan patch
14:52:19 <flaper87> so, I just rebased it and it's up waiting for a ninja approve
14:52:22 <flaper87> :D
14:52:35 <markwash> okay great
14:52:42 <zhiyan> (i believe 033 migration version is been used by location status db change)
14:52:49 <flaper87> zhiyan: right
14:52:54 <flaper87> I allocated 34
14:53:02 <markwash> #topic i18n message improvements (flwang)
14:53:08 <markwash> #link https://blueprints.launchpad.net/glance/+spec/i18n-messages
14:53:24 <markwash> flwang: is all the code up for this as well?
14:53:28 <zhiyan> flwang: i will revist it on my tomorrow morning
14:53:31 <flwang> markwash: the patch has been reviewed several rounds, and no more patch for this bp
14:53:39 <flwang> zhiyan: thanks
14:53:44 <markwash> flwang: great, I'll look again soon as well
14:53:45 <flwang> markwash: yes
14:53:54 <flwang> markwash: cool, thanks
14:54:12 <markwash> #topic community-level sharing
14:54:18 <markwash> iccha_: you have some questions about the initial direction on this one
14:54:31 <iccha_> i think i am going along with rosmaita s proposal in wiki
14:54:34 <iccha_> and started work on it
14:54:39 <markwash> great!
14:55:17 <markwash> okay I think that covers our blueprints for icehouse-3 that have >low priority
14:55:40 <zhiyan> thank you markwash
14:55:56 <markwash> has anyone had a chance to look at this bug
14:55:58 <markwash> #link https://bugs.launchpad.net/glance/+bug/1236868
14:56:27 <markwash> there has been code up for a while
14:56:41 <zhiyan> markwash: tbh, iiuc, i think that metadata query is necessary, since
14:57:12 <zhiyan> markwash: the status of image can be change via another client upload request, under concurrent context
14:57:41 <markwash> hmm, but I thought the goal was to make it so that we *only* update to active or killed if no other client has already changed it from 'saving' ?
14:58:03 <zhiyan> markwash: i think that just is what dosaboy try to prevent by this fixes
14:58:45 <zhiyan> markwash: so dosaboy need a query
14:58:54 <zhiyan> to mark sure the *current* status of the image
14:59:12 <markwash> hmm, maybe we better follow up in the review due to time limitations
14:59:19 <zhiyan> sure
14:59:23 <markwash> just wanted to keep the priority on this one high :-)
14:59:34 <markwash> all right, I've got a 15 hour drive to catch
14:59:38 <bugsduggan> Something to draw your attention to - python-swiftclient enabling SSL cert checking https://review.openstack.org/#/c/69187/
14:59:51 <bugsduggan> just FYI
15:00:10 <markwash> bugsduggan: thanks!
15:00:15 <markwash> bye folks!
15:00:21 <iccha_> bye markwash !
15:00:24 <flwang> bye
15:00:27 <bugsduggan> \o
15:00:29 <arnaud__> bye
15:00:30 <flwang> thanks, markwash
15:00:33 <zhiyan> good luck
15:00:42 <markwash> zhiyan: I have a day full of driving, could not message you privately for some reason, but unfortunately I have to go and won't be back until tomorrow
15:00:50 <markwash> #endmeeting