20:01:23 <markwash__> #startmeeting glance
20:01:25 <openstack> Meeting started Thu Sep 18 20:01:23 2014 UTC and is due to finish in 60 minutes.  The chair is markwash__. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:28 <openstack> The meeting name has been set to 'glance'
20:01:41 <TravT> o/
20:02:02 * TravT takes a sip of the cocktail
20:02:13 <markwash__> #topic juno-rc1
20:02:40 <markwash__> I believe we're going to try to have rc1 out next week
20:02:48 <markwash__> so far, we've got most of our FFE's in
20:02:54 <markwash__> https://launchpad.net/glance/+milestone/juno-rc1
20:03:07 <markwash__> there was a little bit of discussion about the logging levels change
20:03:14 <markwash__> I dunno if jokke could make it today
20:03:53 <markwash__> it seems maybe someone has some docs and metadefs patches they want to see make it into rc1?
20:03:57 <kragniz> markwash__: he was catching a flight today
20:03:58 <markwash__> anyone here who can speak about that?
20:04:12 <kragniz> so I doubt he can make it
20:04:17 <TravT> I can't speak to his logging patches
20:04:27 <TravT> but did have a few requests related to RC1 and the metadefs
20:04:47 <TravT> i've been going through Nova juno blueprints and nova code.
20:04:59 <TravT> and just making sure that all the metadefs are up to date and accurate
20:05:12 <TravT> so that the definitions we offer "out of the box" are current with Juno
20:05:21 <markwash__> that sounds important :-)
20:05:25 <TravT> zhiyan has looked through most of them
20:05:47 <TravT> but still need another core to look and give comments or approve through
20:06:24 <TravT> i just posted them in the etherpad #link: https://etherpad.openstack.org/p/glance-team-meeting-agenda
20:06:26 <markwash__> okay, cool, is there a gerrit topic we can use to see them?
20:06:32 <markwash__> ah okay, great, thanks TravT
20:06:50 <TravT> also, lakshmiS and I have a couple on docs up for review
20:07:16 <markwash__> are those also in the links posted?
20:07:23 <TravT> yep
20:07:35 <markwash__> okay great
20:07:46 <markwash__> wrt rc1-targeted bugs
20:07:53 <markwash__> currently there aren't any
20:08:05 <markwash__> which just means we're not tracking anything that is considered a release blocker
20:08:36 <markwash__> unfortunately, though our recent bug day was a decent improvement, we still have a lot of New bugs
20:08:43 <markwash__> so we might be rolling the dice a bit there
20:08:59 <markwash__> but unless we find the time to triage all of those bugs, I think we're stuck with rolling the dice a bit :-(
20:08:59 <TravT> how does this work post rc1? can we still get bugs through that aren't blockers?
20:09:34 <markwash__> TravT: until the actual release, we can continue to find/target/and fix bugs
20:09:42 <TravT> \o/
20:09:49 <markwash__> often we have rc2, sometimes rc3
20:10:12 <markwash__> also, yes, bugs that aren't blockers can probably go through as long as the fixes don't seem to be destabilizing
20:10:15 <ativelkov> When the actual release branch is being created?
20:10:27 <markwash__> should be Oct 16
20:10:53 <markwash__> any other thoughts or questions about juno rc1?
20:11:28 <markwash__> okay, moving on then
20:11:34 <ativelkov> Ah, so the release branch is created only with the release? Until then master == juno?
20:11:39 <markwash__> yes
20:11:42 <ativelkov> got it
20:12:00 <markwash__> #topic container format default
20:12:10 <markwash__> so going through the bug reports found a lot of "not" bugs
20:12:17 <markwash__> but that are actually kind of serious UX problems
20:12:24 <markwash__> or at least difficulties
20:12:35 <markwash__> and I think it caused me to reverse course on some longstanding issues
20:12:43 <markwash__> first up, requiring container format
20:12:55 <markwash__> I think this causes a lot of confusion for users of glanceclient
20:13:17 <markwash__> so I'd like to endorse the various folks who have proposed making 'bare' the default
20:13:24 <markwash__> (in bug tickets etc)
20:13:42 <markwash__> anybody hate this idea? or should I just file a spec?
20:13:59 <markwash__> I probably should put this on the ML as well. . .
20:14:11 <ativelkov> is this just a default for CLI, or API as well?
20:14:19 <markwash__> ativelkov: actually it could be either
20:14:25 <markwash__> but I'm considering proposing it for the API first
20:14:32 <markwash__> and seeing if it meets resistence
20:15:11 <markwash__> its a slightly incompatible change no matter how you slice it, but if it were just the glanceclient shell I think we'd certainly be able to afford that cost
20:16:02 <markwash__> okay, well, I can take that issue to the ML, and let us move on
20:16:19 <markwash__> #topic image-create without arguments
20:16:23 <markwash__> this was another issue
20:16:31 <markwash__> but specifically just for the shell
20:16:50 <markwash__> I think we could add an option that says '--just-reserve-id' or something that gives the current behavior
20:17:01 <markwash__> as background
20:17:09 <markwash__> currently, image-create with no arguments actually creates an image
20:17:13 <markwash__> that has no properties and no data
20:17:13 <ativelkov> i.e. set the state to queued?
20:17:16 <markwash__> except an id
20:17:23 <markwash__> ativelkov: yes
20:17:28 <TravT> it currently sets to queued.
20:17:36 <TravT> which is kind of funny, actually
20:17:47 <markwash__> so what I would propose is making image-create with no arguments give usage
20:18:17 <markwash__> and if you want the existing behavior, you pass a special arg
20:18:25 <rosmaita> so is the problem that people are creating bunches of images by mistake?
20:18:29 <markwash__> yes
20:18:31 <rosmaita> "images"
20:18:34 <markwash__> heh
20:18:34 <rosmaita> ok
20:18:35 <kragniz> I think that's a better behaviour
20:18:39 <TravT> and then they just hang out?
20:18:46 <TravT> i mean images that are always in queued
20:18:48 <ativelkov> But will not be a breaking change to the API? Probably somebody is doing this intentiaonlly?
20:19:04 <markwash__> ativelkov: this would just be a glanceclient shell change I think, so the API would stay the same
20:19:13 <markwash__> I know that the shell is also an API
20:19:26 <markwash__> but, it has different requirements in my view
20:19:38 <rosmaita> i agree this makes sense for the shell
20:19:46 <kragniz> ativelkov: is the way it behaves with no arguments clearly documented somewhere?
20:20:09 <TravT> probably...
20:20:22 <TravT> they just updated CLI docs for us. I have the link. just a s ec
20:20:30 <ativelkov> kragniz: well, at least all the arguments are documented as optional
20:20:54 <TravT> #link: http://docs.openstack.org/cli-reference/content/glanceclient_commands.html
20:21:20 <ativelkov> so this change will make at least some of the opts as required, right? file, or copy-from, or location?
20:21:55 <markwash__> ativelkov: not quite, at least how I was thinking of it at first
20:22:00 <TravT> no, he was saying that adding --just-reserve-id would work as it does now
20:22:03 <markwash__> *some* option would be required to actually create an image
20:22:21 <markwash__> alternately, we could add "image-reserve" which does not take anything but properties and works the way image-create does today
20:22:31 <TravT> glance image-create --reserve-id
20:22:41 <markwash__> and then have image-create require file or copy-from or location
20:22:42 <ativelkov> Ok, let's put it this way: what should happen after the change when I just type "glance image-create"
20:22:49 <kragniz> markwash__: that actually sounds like a nicer way to do it
20:22:50 <markwash__> ativelkov: you would get usage
20:23:13 <ativelkov> ok, so at least one of the "source" options is required
20:23:14 <markwash__> that is, parser.print_usage()
20:23:31 <markwash__> I think I'm being a bit confusing, unfortunately
20:23:45 <markwash__> if this idea doesn't sound completely terrible, i can send out an email with a more clear summary
20:24:19 <TravT> what is the normal workflow with the current example?
20:24:26 <TravT> people queue up an image
20:24:30 <TravT> and then upload data?
20:24:54 <markwash__> the typical use case for shell users is to just image-create with --container-format, --disk-format, name, and then image data
20:25:08 <ativelkov> BTW, this may be a slightly different topic, but is there a way to import (i.e. copy-from) data to an existing (but queued) image in v2?
20:25:22 <markwash__> ativelkov: there isn't really
20:25:27 <ativelkov> afair, there is an import-image task, but it creates a new image
20:25:40 <markwash__> that was one of the use case ideas for import-image
20:25:49 <markwash__> but I don't think anyone has worked on that specific case
20:26:15 <markwash__> oh
20:26:21 <markwash__> I didn't understand
20:26:44 <markwash__> ativelkov: you're asking about --copy-from for image-update
20:26:50 <ativelkov> yes
20:27:14 <markwash__> ativelkov: yes that is a supported option
20:27:20 <markwash__> I haven't used it myself
20:27:34 <ativelkov> let's say, I've created an image with no data (queued), and then want to set its data from some external source
20:28:02 <TravT> glance image-upload
20:28:43 <markwash__> I think this is already a supported option on glance image-update
20:29:03 <ativelkov> there is a PUT /v2/images/{id}/file - but it is not copy-from, it is direct upload from client
20:29:04 <markwash__> okay, I'll send out two messages to the ML to gauge the reaction to these changes and then come up with a spec
20:29:31 <markwash__> OH
20:29:40 <markwash__> ativelkov: man I'm really good at misreading your question
20:29:45 <markwash__> you're asking about v2
20:29:57 <ativelkov> yep
20:30:19 <markwash__> ativelkov: there's no copy-from support in v2 at this time
20:30:21 <TravT> yeah, "glance --os-image-api-version 2 image-upload --file <file>" lets you directly upload from CLI
20:30:30 <markwash__> I think we were imagining sticking with import for cases like that
20:30:43 <markwash__> where you need the glance service to call out to some other place
20:31:28 <ativelkov> got it. So, the only place where v2 can do import, is the import image task
20:31:58 <ativelkov> sorry, this looks like an offtopic anyway )
20:32:06 <markwash__> no worries
20:32:09 <markwash__> okay, next up!
20:32:14 <markwash__> #topic community images
20:32:36 <kragniz> quick refresher: community images is a new feature which allows images to be shared with other tenants
20:32:43 <markwash__> kragniz: did I see a mention of you in the recently-resurrected change request?
20:32:55 <kragniz> but only shows up in an image-list when the image is accepted by an image consumer
20:33:17 <kragniz> markwash__: you did indeed!
20:33:37 <kragniz> I'm looking at taking it on and getting it ready for kilo
20:33:44 <markwash__> \o/
20:34:00 <nikhil_k> woot!
20:34:19 <kragniz> the current implementation under review is a little off from the original blueprint
20:34:54 <kragniz> (image still needs to be explicitly shared with tenants before they appear in a listing)
20:35:18 <kragniz> it's been a while since any development on this feature has happened
20:35:21 <TravT> so is this the "shared" status?
20:35:27 <markwash__> yeah
20:35:33 <kragniz> so is there anything I should know before cleaning up this patch for K?
20:35:33 <markwash__> we had some sort of great chat about this at the mini summit
20:35:35 <markwash__> and then I forgot everything
20:36:25 <TravT> this is also coupled with membership, right?
20:36:56 <markwash__> I think that's partly the idea
20:37:18 <markwash__> so the general thought around this was that when you make a community image, folks can see it if they add a specific filter
20:37:26 <markwash__> and then they can still "accept" it to make it show up in their default listing
20:37:42 <markwash__> we also had some idea about changing how the visibility flag worked
20:37:44 <markwash__> :-(
20:37:46 <kragniz> TravT: yup
20:37:50 <markwash__> but I just can't remember
20:37:52 <ativelkov> afair, there was an idea that image has explicit value for the "visibility", which may be either private, public or shared. And there is a transition workflow for state changes, which may occur either explicitly or implicitly my assigning memberships
20:38:02 <markwash__> right
20:38:05 <kragniz> markwash__: did you have any notes on that floating around?
20:38:17 <markwash__> kragniz: I will have to review briefly to see if I can find any
20:38:27 <kragniz> markwash__: awesome, that would be great
20:38:38 <ativelkov> I think we need some refreshing spec before we move on with the implementation
20:38:42 <markwash__> yeah
20:38:45 <markwash__> ativelkov: good point
20:38:55 <markwash__> that will help jog my memory as well
20:38:56 <ativelkov> BTW, do we have a kilo folder in specs already?
20:39:00 <kragniz> ativelkov: that's why I wanted to bring it up
20:39:28 <markwash__> ativelkov: yes
20:39:50 <markwash__> kragniz: okay, so I'll try to update with any notes I find, but if you can go ahead and get a start on the spec it would be great
20:40:08 <kragniz> markwash__: sounds good
20:40:11 <kragniz> :)
20:40:18 <TravT> spec would be good.  iirc there was a lot of questions on what happens once it is shared revoking it.
20:40:38 <markwash__> fwiw here is the etherpad link for that discussion https://etherpad.openstack.org/p/glance-juno-mid-cycle-community-sharing
20:40:41 <markwash__> kragniz: ^^
20:41:07 <kragniz> markwash__: cool!
20:41:30 <markwash__> all righty then
20:41:32 <markwash__> #topic open discussion
20:42:03 <flaper87> sorry guys, I'm very late
20:42:09 <flaper87> is the client ready to be released ?
20:42:11 <lakshmiS> pycharms openstack license expiring in 6 days. Where can we get new license?
20:42:19 <flaper87> I'm planning to do so tomorrow morning
20:42:22 <flaper87> (my morning)
20:42:39 <flaper87> I think the rest of the patches and fixes can be released in a minor release
20:43:05 <kragniz> flaper87: sounds good for us
20:43:05 <flaper87> Are we planing to release a 0.15 or can I simply go with a 0.14.1 ?
20:43:17 <flaper87> AFAIK, we just added fixes and no changes to the API, right?
20:43:41 * markwash__ fetches origin and does a diff
20:44:40 <nikhil_k> lakshmiS: direct email, iiuc
20:44:54 <markwash__> you can see the changes with "git log 33dcea81b2f2ac5f643c0153c5a70cfec2008555..HEAD" btw
20:45:40 <markwash__> flaper87: looks like minor to me
20:45:45 <flaper87> yeah, I threw my self to the lazyweb
20:45:48 <flaper87> :P
20:45:50 <flaper87> myself*
20:45:53 <flaper87> sweet, ok!
20:46:05 <markwash__> lakshmiS: that's a good question
20:46:05 <flaper87> even better. 2 majors in less than 3 weeks would look kinda bad
20:46:16 <markwash__> I dunno if we still have a pycharms hookup
20:47:05 <TravT> FYI, we got 3 of our Horizon patches landed for metadefs!
20:47:06 <nikhil_k> andrew had asked them a month ago
20:47:19 <TravT> so, if you get a new devstack, you can go to images, flavors, and host aggregates and click the "update metadata" action on a row to see the available metadefs.
20:47:21 <nikhil_k> and jetbrains folks asked him to contact a week before
20:47:42 <markwash__> nikhil_k: ah cool, I had forgotten that amelton was the keeper of the keys
20:47:50 <markwash__> TravT: huzzah!
20:47:53 <kragniz> TravT: that's pretty cool
20:47:57 <TravT> Yep!  Thank you everybody for the help in getting it released!
20:48:51 <markwash__> :-)
20:49:00 <nikhil_k> TravT: congrats!
20:49:21 <TravT> Thanks!
20:49:25 <markwash__> all right, looks like we can have 10 minutes back from our normally scheduled hour
20:49:34 <markwash__> I recommend staring off into space :-)
20:49:36 <TravT> one last thing
20:49:42 * markwash__ waits
20:49:42 <nikhil_k> lol
20:50:00 <TravT> when do we need to have specs available for consideration as topics at the next summit?
20:50:39 <ativelkov> TravT: meanwhile could you please take a look at the declarative model to define type-specific artifact metadata I've pushed for review? Does it make sense? (https://review.openstack.org/#/c/119174/)
20:51:17 <TravT> ativelkov: yes, plan on getting back to that.  Although, i'm out on vacation next week.
20:51:50 <ativelkov> Any time which is convenient for you :) thanks
20:52:12 <TravT> ativelkov: i'm definitely planning to help out on that.  just been trying to wrap up current work.
20:52:39 <markwash__> TravT: I'm trying to swim through the recent emails about the summit planning etherpads to see if I can find an answer to your question
20:53:12 * TravT hopes we have some time so he doesn't have to work through vacation.
20:53:39 <markwash__> TravT: maybe somethwere in this thread? http://lists.openstack.org/pipermail/openstack-dev/2014-September/045844.html
20:54:13 <TravT> Yeah, i read that... didn't really have timelines
20:54:17 <markwash__> TravT: I think we can go ahead and start our summit etherpad
20:54:25 <TravT> but it did look like we need to create the etherpad for discussion
20:54:35 <markwash__> I'm guessing the list of topics will be selected an massaged a few weeks prior to the summit
20:54:54 <TravT> we have a few things we might put up as topics, but it will be a couple weeks
20:55:00 <markwash__> should be fine
20:55:19 <TravT> :-)
20:55:26 <TravT> thx
20:55:31 <markwash__> okay, anything else?
20:56:20 <markwash__> #endmeeting