14:00:18 <nikhil> #startmeeting glance
14:00:18 <openstack> Meeting started Thu May 12 14:00:18 2016 UTC and is due to finish in 60 minutes.  The chair is nikhil. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:21 <openstack> The meeting name has been set to 'glance'
14:00:25 <nikhil> #topic roll call
14:00:37 <wxy> o/
14:00:40 <dshakhray> o/
14:00:49 <sigmavirus24> o/
14:00:50 <hemanthm> o/
14:00:52 <mfedosin> o/
14:00:56 <rosmaita> o/
14:01:08 <bunting> o/
14:01:11 <tsymanczyk> o\
14:01:13 <tsymanczyk> \o
14:01:19 <abhishekk> o/
14:01:23 <nikhil> welcome everyone
14:01:25 <nikhil> let's get started
14:01:27 <nikhil> #topic agenda
14:01:28 <flaper87> o/
14:01:44 <nikhil> we've a few items today, thanks to mfedosin and flaper87
14:01:49 <flaper87> :D
14:02:01 <nikhil> I do want to discuss newton specific dates before that
14:02:11 <nikhil> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:02:24 <flaper87> go ahead, I don't think I'll need much time for my items
14:02:26 <nikhil> first things first:
14:02:28 <flaper87> most of them are heads ups
14:02:30 * flaper87 stfu
14:02:37 <nikhil> flaper87: cool, ty
14:02:38 <nikhil> #topic Updates
14:02:52 <nikhil> #info Glare ( mfedosin )
14:03:07 <mfedosin> okay
14:03:09 <mfedosin> I'm back from vacation
14:03:36 <flaper87> mfedosin: welcome back
14:03:46 <mfedosin> no special activity for Glare was done in last 2 weeks
14:04:03 <mfedosin> kairat and dshakhray fixed several bugs we had
14:04:12 <mfedosin> and I updated the spec
14:04:15 <nikhil> hope you enjoyed
14:04:35 <mfedosin> #link https://review.openstack.org/#/c/283136/
14:04:37 <nikhil> ok (on the no-activity update)
14:05:11 <mfedosin> plans to continue the development and implement new features
14:05:28 <nikhil> mfedosin: ok, it would be nice to discuss the action plan for Glare in the monday's meeting. Also, possible start small discussions on the spec.
14:05:29 <mfedosin> I got nice feedback on the summit
14:05:53 <mfedosin> nikhil: yeah
14:06:03 <nikhil> great
14:06:21 <nikhil> anything else on this today?
14:06:26 <mfedosin> nope
14:06:33 <nikhil> ty
14:06:49 <nikhil> #info Nova v1, v2 ( mfedosin , flaper87 , nikhil )
14:07:16 <nikhil> So, the spec needs updating, and addressing comments:
14:07:19 <nikhil> #link https://review.openstack.org/#/c/301741/
14:07:48 <mfedosin> kk
14:07:52 <flaper87> I'm working on getting the gate ready
14:07:53 * flaper87 gets link
14:08:04 <nikhil> Look at the summary recap from Matt:
14:08:06 <nikhil> #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/094380.html
14:08:10 <flaper87> #link https://review.openstack.org/#/c/315190/
14:08:28 <flaper87> That should allow us to use either version of the API in the gate
14:08:38 <flaper87> Nova gets the version from the `/versions` endpoint
14:08:38 <mfedosin> number of comments soon will exceed the number of lines there
14:08:47 <flaper87> mfedosin: LOL
14:08:55 <nikhil> Thanks flaper87
14:09:00 <nikhil> mfedosin: you bet
14:09:11 <nikhil> flaper87 is working on disabling the v1 by default to that the gate can run on simply v2
14:09:46 <nikhil> flaper87: no, the plan is for nova to have a top level config that will allow them to run either v1 or v2
14:09:54 <flaper87> I think we'll end up with 1 new v1-only job that we'll get rid of in the future.
14:10:01 <flaper87> nikhil: yeah, I meant to say it does check `/versions` now
14:10:08 <nikhil> #info the version discovery support has been cancelled
14:10:09 <flaper87> IIRC
14:10:16 <nikhil> flaper87: ok, cool
14:10:30 <flaper87> whenever that config is added, we'll update devstack
14:10:59 <mfedosin> also we have to add removing version discoverability in working items for the spec
14:11:08 <nikhil> mfedosin: so when this gate is enabled to run just v2, we will know what all drivers/pieces of code fail with v2
14:11:32 <flaper87> yup, I'll add it as a non-voting gate
14:11:36 <nikhil> we need to come to an eventual green gate for v2 when the config in nova will be removed and it will be safe to deprecate glance v1
14:11:54 <nikhil> mfedosin: yes
14:11:58 <flaper87> we'll switch to using v2 as default in the other gates as soon as we're confident enough it won't break
14:12:05 * flaper87 stops spamming
14:12:17 <nikhil> flaper87: thanks, that's useful too.
14:12:29 <mfedosin> flaper87: thanks Flavio
14:12:38 <nikhil> let's keep a weekly sync on #openstack-glance for nova work too.
14:12:54 <nikhil> moving on if we're done here
14:13:16 <nikhil> #topic Cross Prj
14:13:34 <nikhil> the CP meetings have become ad-hoc only
14:13:47 <nikhil> #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/094443.html
14:14:24 <nikhil> if anyone wishes to start a CP effort, they will need to act accordingly
14:14:37 <nikhil> #topic Announcements
14:15:28 <nikhil> I sent out the Newton priorities, processes, etc. email
14:15:32 <nikhil> #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/094780.html
14:15:48 <nikhil> Wanted to ensure everyone was particularly aware about the dates.
14:16:13 * flaper87 hasn't read that email yet
14:16:18 <nikhil> We are being very strict on accepting any more specs this cycle, the justification comes in the reviewer bandwidth section.
14:16:20 <flaper87> I'll catch up and reply to the thread
14:16:55 <nikhil> All the necessary commits to glance-specs, glance docs, releases will be done.
14:17:41 <nikhil> Feel free to reach out to me with any questions/concerns or ML works.
14:17:51 <flaper87> Last cycle, we tried to focus reviews on specific parts of glance depending on the milestones
14:18:00 <flaper87> I think we should do the same this time around
14:18:07 <flaper87> it helped with the shortage of reviewers
14:18:27 <flaper87> For example, we focused a lot on specs rather than doing code reviews at the beginning
14:18:34 <flaper87> then we started switching progressively to code
14:18:39 <flaper87> mostly specs
14:18:45 <flaper87> and then progressively to bugs
14:18:49 <nikhil> ++ to focus on specs
14:18:51 <flaper87> and then FF, RCs, etc
14:18:57 * sigmavirus24 wasn't around last cycle but this sounds like a solid idea
14:19:11 <nikhil> the the dates have been designed for that purpose too.
14:19:19 <flaper87> I didn't made that public but I basically silently transitioned everyone towards the reviews we needed
14:19:23 * rosmaita is glad sigmavirus24 is around for this cycle
14:19:23 <flaper87> SorryNotSorry :P
14:19:45 <mfedosin> sigmavirus24: we missed you
14:19:47 * flaper87 is not sure if people noticed that
14:19:50 <flaper87> sigmavirus24: <3
14:19:56 <nikhil> I do not want to enforce business from not getting important bugs fixed early in the cycle but the focus needs to be on the specs.
14:20:41 <sigmavirus24> rosmaita: that's not guaranteed but I'm going to try to swindle some review time
14:20:49 <nikhil> the assignment of the cores on the spec is another important factor for understanding if a spec can move in relatively decent pace or we need to think of alternate mechanisms.
14:21:24 <nikhil> Let's all follow the process completely and see if it works, I will gather feedback in a couple of weeks.
14:21:46 <nikhil> An individual already reachout out to me to see if lite-specs will require cores associated.
14:21:54 <nikhil> reached*
14:22:25 <nikhil> I think this will help keep focus and good pace. Also, it's easier to work with distributed and flexibly structured team.
14:23:02 <nikhil> Anyway, the practicality of all this will be known within a few days of adoption.
14:23:13 <nikhil> Thanks all for the great input.
14:23:15 <nikhil> moving on
14:23:23 <nikhil> #topic Glance v2 transaction layer (dshakhray, mfedosin)
14:23:56 <mfedosin> dshakhray: can you find the links?
14:24:03 <dshakhray> https://review.openstack.org/#/c/272118/
14:24:14 <dshakhray> spec https://review.openstack.org/#/c/315483/
14:24:21 <mfedosin> so, in short we have an old issue in glance v2
14:24:41 <mfedosin> when we update an image we rewrite all data in db
14:25:04 <mfedosin> it leads to 1. race conditions, 2. increased burden on db
14:25:30 <mfedosin> it's not seen when load is low
14:26:15 <mfedosin> but on high-load deployments we saw these issues
14:26:29 <mfedosin> so, Darja's work is about to fix it
14:27:24 <nikhil> ok, so we just need reviews?
14:27:48 <mfedosin> the idea is to add transaction layer in domain model that will compare image after and before db layer
14:27:49 <flaper87> !ping
14:27:49 <openstack> pong
14:27:55 <flaper87> crap, I got disconnected
14:27:57 <flaper87> sorry about that
14:27:58 <mfedosin> and save only modified attributes
14:28:01 <flaper87> :/
14:28:13 <mfedosin> yeah, we need reviews
14:28:24 <mfedosin> test coverage is really good there
14:28:30 <nikhil> mfedosin: correct, I had done a brief review on this.
14:29:30 <nikhil> ok, I guess we need to review the spec first.
14:29:36 <jokke_> o/
14:29:42 <mfedosin> performance testing results will be done soon
14:29:43 <jokke_> sorry, late
14:29:59 <dshakhray> I spent performance testing with a small number of requests
14:30:07 <dshakhray> result http://pixs.ru/showimage/yotxru2png_8513882_21907859.png
14:30:14 <dshakhray> blue line - old code
14:30:21 <dshakhray> red line - with transaction layer
14:30:48 <nikhil> dshakhray: english please :)
14:30:57 <mfedosin> dshakhray: cool :)
14:31:05 <nikhil> I got the numbers but not what they represent.
14:31:06 <mfedosin> nikhil: I understand her ;)
14:31:43 <dshakhray> sorry for my english : (
14:31:52 <flaper87> dshakhray: he meant on the graph
14:31:53 <mfedosin> we'll talk later about performance testing :)
14:31:53 <nikhil> #action glance-cores: review spec  https://review.openstack.org/#/c/315483/
14:31:54 <flaper87> :)
14:32:09 <flaper87> your english is great
14:32:21 <nikhil> dshakhray: indeed, it's good.
14:32:40 <nikhil> dshakhray: please refer a graph that will help us collaboratively provide input.
14:33:03 <nikhil> anything else on this topic?
14:33:27 <mfedosin> we can continue this discussion in the spec comments
14:33:33 <nikhil> thanks
14:33:35 <nikhil> moving on
14:33:49 <nikhil> #topic Glance Registry deprecation (flaper87)
14:34:02 <nikhil> #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/094773.html
14:34:12 <flaper87> So, this was discussed at the summit to some extent but it needs more "talking"
14:34:29 <flaper87> I've sent out that email to kick off the discussion and, hopefully, get feedback from OPs
14:34:34 <flaper87> (and anyone, really)
14:34:51 <flaper87> SOOOOO, if you have anything to say on this, please do
14:35:16 <nikhil> flaper87: for some reason (either this has not reached my inbox or got filtered to an unknown place)
14:35:18 <flaper87> The feedback so far has been that it might not be actually needed. Except from 1 person (IIRC) that mentioned it's important for them
14:35:33 <flaper87> nikhil: I cross-posted it in dev and ops
14:35:35 <flaper87> mmh
14:35:45 <flaper87> perhaps you have it in one of those folders ?
14:35:59 <nikhil> flaper87: ok thanks.
14:36:06 <flaper87> that's it
14:36:12 <nikhil> I will try to find it and respond.
14:36:18 <flaper87> I don't mean to use the meeting to discuss that at this point
14:36:28 <flaper87> I'll bring this topic up again when we have more "data"
14:36:55 <nikhil> Yes, we also need to research on rolling upgrades that is related to this.
14:37:06 <nikhil> moving on
14:37:09 <mfedosin> can they describe how they use registry?
14:37:23 <flaper87> mfedosin: hope to get that info in this thread
14:37:39 <flaper87> nikhil: I need to double check the relation between the registry deprecation and rolling upgrades
14:37:42 <flaper87> I'll sync with rosmaita
14:37:54 <rosmaita> flaper87: we should reach out to that guy from australia, he always shows up at the glance ops sessions
14:37:56 <flaper87> It's not clear to me why this depends on rolling upgrades anymore
14:38:09 <flaper87> rosmaita: I don't know his name/company :(
14:38:19 <flaper87> Was e from AU or NZ ?
14:38:21 <nikhil> yes, sync with rolling upgrades researchers
14:38:26 <jokke_> flaper87: I think it's almost other way around ... rolling upgrades depends on this ;)
14:38:27 <nikhil> mfedosin: flaper87 : https://review.openstack.org/#/c/268865/
14:38:40 <flaper87> jokke_: still, no idea why
14:38:41 <nikhil> look at the bug associated to know how they use it
14:38:49 <nikhil> the bug is actually a lite-spec
14:39:01 <rosmaita> flaper87: i think i can track him down
14:39:10 <flaper87> rosmaita: please, thanks :)
14:39:13 <flaper87> point him to the thread
14:39:21 <flaper87> ok, that's all from me on this topic at this point
14:39:24 <nikhil> flaper87 rosmaita: Jake Yip (look at the link)
14:39:39 <flaper87> nikhil: thanks
14:39:53 <nikhil> #topic Deprecate `show_multiple_locations`
14:40:03 <nikhil> https://review.openstack.org/#/c/313936/
14:40:14 <nikhil> #link https://review.openstack.org/#/c/313936/
14:40:24 <nikhil> flaper87: that's you again, I think
14:40:25 <flaper87> I published this draft to kick of a public discussion on this topic
14:40:41 <flaper87> I believe we should get rid of that option and manage locations using policies
14:40:50 <mfedosin> it was kairat dream :)
14:40:54 <flaper87> Stuart is on the side that having a way to turn this off is good
14:41:10 <flaper87> so, before I go and start fixing all the gate issues related to this, I wanted to get people's thoughts
14:41:18 <nikhil> well, I linked it to the Nova spec.
14:41:22 <jokke_> flaper87: so what's the benefit of moving that from one config file to multiple options on the other?
14:41:24 <flaper87> It'd be cool to get +1/-1 on the idea
14:41:37 <flaper87> jokke_: you already have all of that ;)
14:41:41 <nikhil> there are some outstanding questions on the Nova side that we need to see the effect on.
14:41:49 <flaper87> you need to have all the policies and that config option
14:42:15 <nikhil> flaper87: man, I would probably introduce a few more config options just to make it hard to use it
14:42:25 <flaper87> nikhil: lol
14:42:38 <flaper87> That's a different discussion that I'd also be happy to have
14:42:49 <jokke_> nikhil: that would fit perfectly to the current trend of glance
14:43:02 <flaper87> When this option was added, we didn't have the granularity in the policy.json file
14:43:10 <flaper87> it was then added and the option was kept
14:43:32 <flaper87> I think removing the policies around this would be a step backwards, hence the proposal to remove the other option
14:43:54 <sigmavirus24> there's lots of python enforcing admin-only-ness of things that are also in the policy.json file
14:44:01 <nikhil> I would make the policies as admin by default and yet keep the config option
14:44:11 <flaper87> I wish we had another known role for services so that I could make this non-admin only
14:44:17 <sigmavirus24> nikhil: I think the option should be deprecated though
14:44:22 <rosmaita> flaper87: i am in favor of killing option and using policy instead
14:44:46 <nikhil> sigmavirus24: having policy control is not very descriptive
14:44:59 <nikhil> for example: with hemanthm 's changes we can define it to be an advanced option
14:45:03 <flaper87> I just don't see the point of having it if we're already enforcing it elsewhere and returning better HTTP codes on that path
14:45:09 <nikhil> and that way, people know to not use it
14:45:22 <nikhil> there's no technical reason to keep it
14:45:30 <flaper87> nikhil: are you suggesting switching it to True by default and the policies to admin ?
14:45:32 <jokke_> flaper87: so only problem I have with that is the read side
14:45:32 <nikhil> but there's operational one
14:45:51 <nikhil> flaper87: no, both off by default (False and admin)
14:45:56 <jokke_> of we currently have policy preventing something, we return apropriate code and tell the user that  it was prevented
14:46:05 <flaper87> FWIW, I think setting options in a config file is not a problem anymore for OPs.
14:46:11 * flaper87 waits for OPs to kill him
14:46:17 <nikhil> flaper87: "only trusted deployments with admins are encouraged to use that config option"
14:46:40 <nikhil> "with advanced admins"
14:46:40 <flaper87> nikhil: but again, we have 4 options to do the same
14:46:45 <flaper87> 1 global and 3 granular options
14:46:59 <nikhil> yes, and that is exactly what I feel we need to make people not use it
14:47:03 <flaper87> I don't see the point of the config option except for having 1 key to turn on/off this thing
14:47:19 <jokke_> of we move the locations under policies we really can't do that and tell the user that they can't have details of their image because policy prevents them seeing locations and on the other hand if we just hide it we are inconsistent with the rest of the policies
14:47:24 <nikhil> otherwise, it's a simple policy change for whoever wants read, write or delete.
14:48:11 <flaper87> I think adding more config options is the wrong way to communicate something shouldn't be used. Really.
14:48:12 <jokke_> s/of/if/
14:48:15 <flaper87> or at least in this case
14:48:20 <jokke_> flaper87: ++
14:48:21 <mfedosin> btw, if we have several locations and show_direct_url is enabled, then glance shows only the first one?
14:48:28 <nikhil> flaper87: the point isn't clear yet. I want the categorization effort to hide this config option very similar to the social networks hide your privacy settings.
14:48:44 <flaper87> I want this config option gone
14:48:47 <jokke_> if we take that stand, we're sending pretty clear message that Glance shouldn't be used :P
14:48:48 <flaper87> like, BOOOM
14:48:51 <rosmaita> mfedosin: yes, there is some kind of weird interaction between multiple loc and direct url
14:49:04 <rosmaita> unfortunately, i can't remember what it is!
14:49:05 <nikhil> mfedosin: yes (as per the default location strategy)
14:49:16 <mfedosin> maybe we should deprecate this one as well?
14:49:31 <mfedosin> because it may confuse users
14:49:44 <flaper87> So, let's do this. Let's give ppl some time to think this through and vote next week
14:49:46 <flaper87> thoughts?
14:49:51 <flaper87> please, comment on the review
14:50:04 <nikhil> Thanks!
14:50:04 <mfedosin> I vote for deprecation
14:50:11 <flaper87> mfedosin: <3
14:50:11 <tsymanczyk> deprecation
14:50:17 <nikhil> I vote for deprecation of multiple-locations.
14:50:26 <mfedosin> (feels like I vote for Trump)
14:50:32 <flaper87> mfedosin: tsymanczyk put all that on the review, please
14:50:41 <flaper87> mfedosin: not the trump part
14:50:44 <flaper87> :P
14:50:48 <nikhil> moving on
14:50:52 <jokke_> mfedosin: but That IS good thing :P
14:50:56 <nikhil> #topic Deprecate `/file` endpoint
14:51:09 <jokke_> easy, No can do
14:51:09 <rosmaita> mfedosin: make glance great again!
14:51:10 <nikhil> #link https://review.openstack.org/#/c/313947/
14:51:20 * sigmavirus24 slaps rosmaita's wrist with a ruler
14:51:23 <flaper87> ok, as promissed, I amended the original spec to reflect we're not remiving the `/file` endpoint
14:51:24 <sigmavirus24> stop that rosmaita
14:51:35 <mfedosin> I vote against this time
14:51:37 <flaper87> There's a comment from jokke_ on why we shouldn't make it admin only
14:51:47 <flaper87> removing, even.
14:52:09 <flaper87> Wait, the title of the IRC topic is misleading
14:52:11 <flaper87> go and read the spec
14:52:13 <flaper87> :P
14:52:27 <nikhil> so, I will need to consider this carefully.
14:52:28 <flaper87> The spec actually says: Don't deprecate
14:52:46 <jokke_> nikhil: no you don't we just can't do it
14:52:48 <nikhil> For Nova we need this enabled by default in devstack/gate.
14:53:09 <flaper87> Now, I'm on the side this should be admin only for the lack of a better role to have there
14:53:21 <nikhil> jokke_: correct, I need to think for all the reasons why not so that we don't discuss this again :)
14:53:25 <flaper87> The reasons I don't think we should have this open are the same reasons we've expressed in the import spec
14:53:26 <jokke_> nova and Cinder are relying on it and good luck convincing them to change that now after all this v2 hassle
14:53:37 <flaper87> We want to move away from this endpoint as a public endpoint
14:53:44 <flaper87> users *must* use the new workflow
14:53:54 <nikhil> No, it has been agreed that Nova will use this endpoint
14:53:58 <flaper87> whereas internal services can use the old one
14:54:12 <jokke_> flaper87: unfortunately we do not have ways to do that reasonably either
14:54:14 <nikhil> Now, flaper87 needs to chat with the Service Catalog TNG folks to determine if this is even a possiblity
14:54:24 <flaper87> nikhil: what?
14:54:35 * flaper87 just realized he needs to talk to the Service Catalog TNG team
14:54:38 <flaper87> :P
14:54:43 <nikhil> flaper87: the summit discussion did not clarify if we will differentiate between public and private glance installations.
14:54:44 <flaper87> jokke_: right, #sadpanda
14:55:03 <nikhil> and people are generally against that idea
14:55:08 <jokke_> only way to do this is to deploy specific public nodes and prevent using /file in policy
14:55:18 <nikhil> (because it doesn't make sense for small scale clouds)
14:55:21 * rosmaita is confused and scared by the Service Catalog TNG
14:55:29 <flaper87> well, you can't tell people how to deploy their stuff. Glance not differentiating public/private doesn't mean others won't
14:55:46 <nikhil> rosmaita: yep, me too.
14:55:46 <flaper87> jokke_: that's the way people are deploying glance today, AFAIK
14:55:55 <jokke_> flaper87: correct
14:55:57 <flaper87> jokke_: which is why I went ahead and proposed making it admin only
14:56:05 <flaper87> since you can open it internally
14:56:05 <nikhil> yes, but we need to start thinking of what comes out of a devstack pull.
14:56:26 <flaper87> sorry, too many different convos in parallel
14:56:27 <nikhil> sorry, we're running out of time
14:56:30 <nikhil> need to discuss this later
14:56:31 <jokke_> flaper87: and small deployments hates it because they need the resources to run those nodes even they don't need the capacity for it
14:56:40 <flaper87> Again, folks, please, comment on the spec
14:56:44 <flaper87> This is an important change
14:56:48 <nikhil> #topic Refactor glance_store public API
14:56:59 <nikhil> #link https://review.openstack.org/#/c/315025/
14:57:06 <nikhil> flaper87: you have 1 min
14:57:13 <nikhil> :)
14:57:13 <flaper87> Again, as promissed, I got my stuff done! :)
14:57:15 <flaper87> go and review the spec
14:57:17 <flaper87> period
14:57:23 <flaper87> actually, +2A and we're good
14:57:26 <flaper87> I'll buy beers for everyone
14:57:28 <jokke_> ;)
14:57:43 * flaper87 is on top of his s@$#@$@  today
14:58:04 * flaper87 is done
14:58:08 <nikhil> I almost feel we need to have spec related syncs
14:58:08 <flaper87> thanks for listening
14:58:19 <nikhil> anyway, thanks flaper87
14:58:23 <nikhil> #topic open discussion
14:58:27 <nikhil> 90 seconds
14:58:29 <flaper87> nikhil: no, please, no other meetings/syncs :D
14:58:46 <mfedosin> flaper87: I like this spec
14:58:51 <flaper87> mfedosin: w000h000
14:58:52 <mfedosin> and will review it
14:58:53 <nikhil> flaper87: yeah, there's no plan. But I will ping people ad-hoc for syncs.
14:58:55 <hemanthm> need help with improving the help text
14:58:56 <flaper87> mfedosin: thanks
14:59:02 <tsymanczyk> ad hoc syncs at least, yes please.
14:59:16 <nikhil> so, from next week onward
14:59:16 <tsymanczyk> sometimes i worry that i'm off in the weeds. cannot be the only one.
14:59:18 <hemanthm> here are the options https://etherpad.openstack.org/p/improving-glance-config-opts (please feel free to pick up a few of them you are comfortable with)
14:59:39 <nikhil> we will limit the agenda to 4 items + open discussion (and updates)
15:00:17 <nikhil> you need to post the agenda by Wednesday 2100 UTC to get it approved for the Thurs meeting
15:00:27 <nikhil> Thanks all!
15:00:34 <nikhil> #endmeeting