14:02:22 <nikhil_k> #startmeeting Glance
14:02:23 <openstack> Meeting started Thu Jan 15 14:02:22 2015 UTC and is due to finish in 60 minutes.  The chair is nikhil_k. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:26 <openstack> The meeting name has been set to 'glance'
14:02:43 <nikhil_k> we can continue the roll call for a bit
14:02:47 <kragniz> o/
14:02:50 <pkoniszewski> o/
14:02:58 <mfedosin> o/
14:03:33 <nikhil_k> ok
14:03:35 <sigmavirus24> o/
14:04:15 <nikhil_k> #info https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:04:28 <nikhil_k> #topic Updates
14:04:49 <nikhil_k> #info +1 to the enabling of logging
14:05:42 <nikhil_k> #action cindy to request the infra team for its impl
14:05:43 * kragniz hides from jokke_
14:06:14 <nikhil_k> CLI sorting standard for OpenStack projects
14:06:21 <nikhil_k> https://review.openstack.org/#/c/145544/
14:06:42 <nikhil_k> That change looks good overall
14:06:43 <mfedosin> i've already said my opinion :)
14:06:45 * sigmavirus24 thinks he's read this already
14:06:58 <mfedosin> looks good
14:07:17 <nikhil_k> and we've a corres. patch from mfedosin
14:07:33 <sigmavirus24> Ah yeah. This is something the APIWG is discussing on the API side too
14:07:39 <nikhil_k> Let's start working on the server side changes
14:07:39 <mfedosin> i'll add multiple sort dirs to glance server and change the client's syntax
14:07:45 <jokke_> I looked it through ... I prefer the nova syntax there, but tbh it does not look consistent with the rest of the options
14:08:06 <jokke_> I do like short and simple cli options, but all the rest are really verbose in our clients
14:08:29 <mfedosin> i thought i would do it today and tomorrow but artifacts take a lot of time
14:08:41 <sigmavirus24> mfedosin: anyway I can help?
14:09:11 <mfedosin> sigmavirus24, review it please, when it'll done
14:09:26 <nikhil_k> ok, cool
14:09:34 <nikhil_k> seems like the train is on right track
14:09:42 <mfedosin> I'll do it at the weekend
14:09:42 <nikhil_k> Vancouver Design Summit format changes
14:09:59 <sigmavirus24> mfedosin: I'm not sure you know what the weekend is actually for ;)
14:10:03 <nikhil_k> you may personally let me know your thoughts as well
14:10:29 <jokke_> +all what I got ... I think that format change is really good direction
14:10:55 <mfedosin> sigmavirus24, my girlfriend away for the weekend, so...
14:11:08 <nikhil_k> #topic Reviews/Bugs/Releases
14:11:44 <nikhil_k> bot doesn't seem to be working
14:11:57 <pennerc> o/
14:11:59 <nikhil_k> https://review.openstack.org/#/c/146651/
14:12:19 <nikhil_k> sigmavirus24: please take over
14:12:33 <sigmavirus24> That's mine. I have ideas to add tests that I'll get to today or tomorrow, but I wanted to address the other proxy objects in the policy module
14:12:51 <sigmavirus24> For each of them we pass an empty dictionary as a target which disables everything but the RoleCheck essentially
14:13:27 <sigmavirus24> So you can't restrict an action based on tenant/tenant_id etc. I was wondering if people had ideas for *Target objects for the rest of the objects in glance.api.policy (ImageRepoTarget, MemberTarget, etc.)
14:13:27 <mclaren> sigmavirus24: other projects handle individual tenant ids if sent in the dictionary?
14:13:50 <sigmavirus24> mclaren: I haven't checked every project but I'm pretty sure Keystone does
14:13:56 <mclaren> ok, thx
14:14:31 <sigmavirus24> The target, to be clear, is just a representation of the object we're trying to interact with. The context holds the authenticated user's information and other things
14:14:34 <jokke_> sigmavirus24: does that have any effect on the role checks?
14:14:38 <sigmavirus24> jokke_: no
14:15:22 <nikhil_k> sigmavirus24: we prolly should discuss this about metadefs with someone actually using it
14:15:34 <jokke_> I think the next big thing is, how much we take performance hit by that
14:15:39 <nikhil_k> wayne__: ^ ?
14:15:53 <wayne__> yes
14:16:19 <nikhil_k> if you compare it with the join of image-properties table, the performance hit would minimal; no?
14:16:23 <sigmavirus24> jokke_: the enforcer already supports user-defined rules and checks and will follow them down regardless. There shouldn't be a significant performance hit (if any) by passing a target
14:17:06 <mclaren> sigmavirus24: it's a really minor thing but a link to the officially supported policy format/options might be useful as a reference for folks
14:17:24 <jokke_> sigmavirus24: so the target is not a huge lump of data (sorry, this is part of the code I'm really not familiar with)
14:17:37 <sigmavirus24> mclaren: okay. It's an oslo-inc project at the moment so it mainly exists in the module doc-string
14:18:08 <sigmavirus24> jokke_: the target for the ImageTarget is just a wrapper/proxy around an models.Image instance so you can do target['owner'] => tenant_id
14:18:23 <jokke_> sigmavirus24: ah ok ... thnx
14:18:27 <sigmavirus24> jokke_: no need to apologize :)
14:18:34 <sigmavirus24> mclaren: I'll get a link though right now
14:19:04 <sigmavirus24> #link https://github.com/openstack/glance/blob/master/glance/openstack/common/policy.py#L16..L76
14:19:26 <jokke_> we just get so much nagging of glance being the performance bottleneck that I would prefer us not at least increasing the delays :D
14:19:35 <sigmavirus24> ayoung and morganfainberg are pulling it out of the incubator though into oslo.policy this cycle but we probably shouldn't transition to it until L
14:19:48 <sigmavirus24> jokke_: that's understandable
14:19:48 <jokke_> ++
14:20:32 <sigmavirus24> And to be transparent, I only found this bug because os-ansible-deployment was trying to set different defaults for Rackspace Private Cloud customers and we found no matter what we did, it 403'd (because the targets were empty)
14:20:39 <nikhil_k> I'm a little worried if operators keep this as expected behavior and have things running
14:20:46 <mclaren> sigmavirus24: thx!
14:21:11 <sigmavirus24> nikhil_k: the bug was originally reported in 2012, so people who try may just give up while others never change policy.json
14:21:26 <sigmavirus24> I suspect some operators expect the defaults in policy.json to be secure instead of relaxed
14:21:47 <nikhil_k> sigmavirus24: agree to make them more _granular_
14:22:13 <sigmavirus24> Anyway, I just wanted people's eyes and thoughts. I'm not familiar with the other objects but it should be simple to write proxy objects like ImageTarget (or one generic Target object) for the rest of the "targets"
14:22:15 <sigmavirus24> We can move on
14:22:38 <nikhil_k> sigmavirus24: may be a ML discussion on this ?
14:22:41 <sigmavirus24> Also, let me know if I should write the ML about this for further input
14:22:41 <sigmavirus24> hah
14:23:07 <nikhil_k> we can start working on a spec too, for keeping the upgrade to K smooth
14:23:19 <sigmavirus24> Sounds fair
14:23:56 <nikhil_k> https://review.openstack.org/#/q/topic:bp/drop-namespace-packages+owner:kragniz%2540gmail.com,n,z
14:24:08 <kragniz> this is a fairly trivial update to the oslo library's namespaces
14:24:30 <kragniz> but it would be nice if they could be merged swiftly to avoid any conflicts arising
14:25:34 <kragniz> moving out of the oslo namespace avoids the bugs with picking up the globally installed version of the libraries, rather than the ones in the local venv
14:26:06 <mclaren> kragniz: I can try to review (remind me if I forget)
14:26:21 <kragniz> mclaren: sure!
14:26:49 <nikhil_k> ok, next?
14:27:02 <kragniz> nikhil_k: yup, that all for that
14:27:02 <nikhil_k> sigmavirus24: do we need to discuss the defaults here?
14:27:22 <nikhil_k> guess no?
14:27:26 <sigmavirus24> no sorry. that won't work anyway until that target issue is resolved
14:27:48 <nikhil_k> thanks!
14:28:01 <nikhil_k> #topic Glance's developer docs
14:28:29 <sigmavirus24> oh yeah that's me too
14:29:08 <nikhil_k> #info Nova's DevRef: http://docs.openstack.org/developer/nova/devref/development.environment.html
14:29:09 <sigmavirus24> So while we were debugging an issue with sqlalchemy-migrate we found that we don't tell developers what they need installed (other than Python dependencies) to get a test/dev setup running
14:29:53 <sigmavirus24> Nova has DevRef (Developer Reference) and we discussed potentially adding something similar. For example, our tests expect "curl" to be installed on the system but if you don't have that, your tests will fail locally
14:30:10 <kragniz> this is a great idea
14:30:27 <sigmavirus24> That particular example is what led to the discussion. I can get a first draft up based on Nova's DevRef if we all think it's a beneficial document
14:30:42 <nikhil_k> mfedosin: does your work on the doc cover some of this?
14:30:52 <jokke_> Actually I think this would be brilliant to bring to ML
14:30:53 <mfedosin> yes
14:30:57 <kragniz> if we just start with something simple and exand it later, it would be good
14:31:12 <mfedosin> we will got 4 elements there
14:31:27 <mfedosin> architecture, components, domain and db
14:31:29 <rosmaita> how different would it be from the nova doc?
14:31:31 <jokke_> I think it would be way more beneficial if we get cross OS doc (even with project specific sections) rather than every project having their own
14:31:42 <rosmaita> jokke_: +1
14:31:51 <mclaren> yeah, maybe just track the delta for each project
14:31:57 <kragniz> jokke_: there is value in "run these commands to start hacking on glance", though
14:31:58 <mfedosin> rosmaita, some elements will be equal
14:32:27 <rosmaita> do you think a "delta" doc would be sufficient, or would it be confusing?
14:32:42 <jokke_> kragniz: thus the project specific sections to that global doc
14:32:43 <nikhil_k> mfedosin: just need to add "tests" element to it
14:32:43 <sigmavirus24> rosmaita: for totally new openstackers, probably more confusing than helpful
14:32:50 <jokke_> if all agree
14:33:03 <jokke_> that's what I thought as well ...
14:33:07 <mfedosin> nikhil_k, okay
14:33:09 <sigmavirus24> jokke_: where should the global doc live though?
14:33:10 <nikhil_k> rosmaita: hard to contribute and keep that in sync globally
14:33:14 <mclaren> not sure. (I was thinking sometimes these kind of docs can become stale over time). Docs in any form sound great!
14:33:35 <sigmavirus24> I can start a discussion on the ML if we want
14:33:41 <rosmaita> sigmavirus24: +1
14:33:44 <nikhil_k> sure
14:33:44 <kragniz> sigmavirus24: +1
14:33:48 <sigmavirus24> See how people feel about making it a global thing with project deltas
14:34:00 <mfedosin> i suppose this doc will be about inner glance, instaed of nova where some common things are described
14:34:32 <jokke_> sigmavirus24: docs.openstack.org - Contribute to OpenStack
14:35:17 <nikhil_k> sigmavirus24: chat after the meeting on this topic ?
14:35:34 <sigmavirus24> nikhil_k: sure
14:35:43 <nikhil_k> #topic Generating config files with oslo-config-generator
14:35:49 <nikhil_k> kragniz: go go
14:36:03 <kragniz> so currently, we're manually syncing the config options in code and in the sample config files
14:36:25 <kragniz> we have the capability to generate these files automatically
14:36:31 <kragniz> (see tox -e genconfig)
14:36:53 <kragniz> so I think we should drop the config files from master and just generate them
14:37:12 <kragniz> this is what nova, cinder, ceilometer and others currently do
14:37:13 <sigmavirus24> I ran this to generate the glance-manage.conf file and it re-generated the others. The delta was rather large if my memory is correct
14:37:14 <mclaren> sounds like a good idea. I guess a lot of projects are already doing that?
14:37:31 <kragniz> sigmavirus24: the deta is due to formatting changes
14:37:35 <kragniz> iirc
14:37:42 <jokke_> kragniz: -1 ... if you look through the meeting logs over last year this has been discussed quite a few times already
14:38:01 * kragniz hasn't seen those logs
14:38:12 <sigmavirus24> I'm +1 on the idea but the first pass should be done carefully (I'm rather paranoid)
14:38:31 <kragniz> jokke_: what are your reasons, other than that's what happened last time it was discussed?
14:38:46 <nikhil_k> also, it would nice to chck the bahcior with new adidtions and deletions
14:38:47 <kragniz> sigmavirus24: I agree
14:38:50 <jokke_> kragniz: the reasoning having the configs in the master is to be able to refer to the config files at github and so far we haven't been able to figure out way to generate them to the repo automatically
14:38:59 <nikhil_k> behavior*
14:39:21 <sigmavirus24> jokke_: I'm not sure I follow
14:39:40 <jokke_> kragniz: the auto update has been on discussions quite a lot, we just havent found a way to do it
14:39:57 <kragniz> jokke_: but those values in the config files are duplicated from where the oslo.config option is declared
14:40:22 <kragniz> jokke_: and keeping these files up to date is a lot of contributor effort
14:40:25 <jokke_> sigmavirus24: we'd like to have access to the example configs without the need to clone the repo and generating them every time you need to refer to them for new folks etc.
14:40:49 <sigmavirus24> jokke_: kragniz is talking about generating the ones that exist in-tree and committing them I think
14:40:58 <mclaren> do other projects have non-generated reference config files?
14:41:04 <kragniz> and it's not happening in some places
14:41:09 <kragniz> glance-cache.conf hasn't been updated with the glance_store options, for example
14:41:26 <sigmavirus24> mclaren: they have https://github.com/openstack/keystone/tree/master/etc .conf.example configs
14:41:28 * flaper87 is late to the party
14:41:48 <mclaren> ok, thx. Wonder what their magic is?
14:42:13 * jokke_ thought that the example configs we have are actually the generated ones ... the commit was just supposed to be manual process
14:42:39 * flaper87 acts as if he knows what we are discussing
14:42:45 <kragniz> https://github.com/openstack/nova/blob/master/etc/nova/README-nova.conf.txt
14:43:34 <sigmavirus24> jokke_: the example configs we have aren't auto-generated and if you do generate them, I think some of the defaults may even be different (or values aren't commented out)
14:44:00 <sigmavirus24> But yeah, they're pretty much equivalent at the moment. The ordering may be the only delta (I trust kragniz to be right about this)
14:44:03 <flaper87> sigmavirus24: mmh, then we need to fix auto-generation
14:44:08 <flaper87> I mean, it should work
14:44:12 <flaper87> (TM)
14:44:31 <sigmavirus24> flaper87: "Just Work" is a trademark the OpenStack Foundation hasn't been allowed to license yet ;)
14:44:37 <kragniz> flaper87: you keep config files out of tree in zaqar, right?
14:44:43 <jokke_> yup ... zhiyan has put lots of effort to get the generation working ... thus I thought that the confs were actually iteration of the output
14:44:55 <flaper87> kragniz: correct
14:45:01 <flaper87> you just tox -egenconfig
14:45:23 <flaper87> one of the points behind having auto-gen is not having samples
14:45:24 <flaper87> :)
14:45:29 <nikhil_k> flaper87: would the documentation and description be covered so thoroughly?
14:45:35 <flaper87> because lets face it, we keep failing at keeping them updated
14:45:50 <flaper87> nikhil_k: as in explaining how to generate them?
14:45:51 <flaper87> yes
14:45:57 <mclaren> anyone know of a project using auto-gen that also has samples?
14:45:57 <nikhil_k> :D
14:46:02 <sigmavirus24> nikhil_k: the docs.openstack.org/{{project}}/ docs have to be updated manually though no matter what
14:46:11 <flaper87> https://github.com/openstack/zaqar#running-a-local-zaqar-server-with-mongodb
14:46:18 <flaper87> we even put it in the README
14:46:21 <sigmavirus24> Cinder does mclaren https://github.com/openstack/cinder/tree/master/etc/cinder
14:46:22 <kragniz> nikhil_k: do you mean descriptions for each option?
14:46:37 <flaper87> mclaren: nope
14:46:45 <jokke_> :)
14:46:48 <nikhil_k> flaper87: I meant the comments on the configs
14:46:51 <nikhil_k> kragniz: yeah
14:46:58 <flaper87> nikhil_k: ah yea, they are kept
14:47:07 <flaper87> it's a matter of keeping the help text updated
14:47:10 <flaper87> :D
14:47:18 <jokke_> iirc cinder reasoning for that was the same why we decided to keep em, to have easy access to example configs
14:47:29 <kragniz> nikhil_k: yes, since it grabs whatever text you use when you declare the oslo.config option
14:47:34 <nikhil_k> flaper87: heh, so that will proly never happen :P
14:47:58 <flaper87> mmh, well, it's part of reviewers task to enforce useful help texts
14:47:58 <sigmavirus24> jokke_: actually, I was half right: cinder.conf isn't kept https://github.com/openstack/cinder/blob/master/etc/cinder/README-cinder.conf.sample
14:47:59 <nikhil_k> kragniz: it's not that great compared to what's mentioned in the sameple
14:48:05 <nikhil_k> though it can be corrected
14:48:06 <kragniz> jokke_: cinder removed their configs from tree
14:48:09 <sigmavirus24> everything else is probably really not much more configurable
14:48:10 <flaper87> as for the existing ones, it'd be a good exercise to update our code base
14:48:22 <nikhil_k> flaper87: yeah, I understand
14:48:30 <kragniz> jokke_: https://github.com/openstack/cinder/blob/master/etc/cinder/README-cinder.conf.sample
14:49:09 <flaper87> if we want to keep them, then we better add a test that the sample is updated
14:49:17 <flaper87> that verifies*
14:49:22 <kragniz> flaper87: +1
14:49:28 <jokke_> oh gr8 :(
14:49:36 <flaper87> Having samples means that people will use them as reference
14:49:45 <jokke_> flaper87: +2
14:49:51 <flaper87> I've had people pointing me to an option that doesn't exist anymore
14:50:10 <flaper87> and I was like: "So well, how do I put it in a nice way... mmhh... the sample is outdate... /me RUN"
14:50:19 <mclaren> a test sounds like it might work. I think we already have some tests for options
14:50:24 <nikhil_k> sounds like an agreement (somewhat)
14:50:28 <flaper87> (and that *just* after cutting the release)
14:50:48 <flaper87> mclaren: afair, cinder has (had?) something to do exactly this
14:50:58 <flaper87> we might want to check what they do(did?)
14:51:10 <flaper87> (may?)
14:51:10 <nikhil_k> can we move on to the next one?
14:51:15 * flaper87 will never get those 2 right
14:51:24 * flaper87 crashed this one so... I guess?
14:51:25 <flaper87> :P
14:51:28 <kragniz> whatever we do, I don't think we should be manually updating the configs
14:51:32 <kragniz> nikhil_k: sure
14:51:37 <nikhil_k> #topic Glance upgradeability
14:51:57 <pkoniszewski> that's me
14:51:57 <nikhil_k> pkoniszewski: that's you ^
14:52:39 <mclaren> flaper87: cinder...not sure tbh
14:52:49 <pkoniszewski> nova is working on smooth updates between versions of openstack, is there anything being done in glance or is there any plan to make support for upgrades in glance/
14:52:51 <pkoniszewski> ?
14:53:17 <pkoniszewski> especially versioned objects, any plan for K or L release?
14:53:26 <nikhil_k> pkoniszewski: nothing for K
14:53:53 <nikhil_k> we can plan for L after nova has tried and tested it, I sup?
14:54:04 <pkoniszewski> that sounds good
14:54:34 <kragniz> nikhil_k: let nova be the guinea pig :P
14:54:49 <flaper87> a good thing to do in advance would be working out a spec explaining how you see this being implemented in glance
14:54:56 <pkoniszewski> sure
14:54:59 <pkoniszewski> I plan to
14:55:01 <flaper87> I'm not sure how many of us are familiar with what nova is doing
14:55:02 <flaper87> :(
14:55:28 <jokke_> flaper87: I thought you know nova inside out by now :P
14:55:42 <pkoniszewski> well I'd like to write blueprint with explanation, but need some time for that
14:55:59 <flaper87> jokke_: oh man, you have no idea. I wish I didn't...
14:56:00 <flaper87> :P
14:56:15 <nikhil_k> pkoniszewski: Thanks for bringing that up, I think this would be a great change.
14:56:16 <kragniz> flaper87: I think it involves equal doses of magic and semver
14:56:35 <nikhil_k> #topic Open Discussion
14:57:01 <mclaren> flaper87: cinder have tools/config/check_uptodate.sh so maybe some prior art
14:57:04 <nikhil_k> Do we want to keep meeting next week before the mid cycle meetup?
14:57:44 <nikhil_k> If not, would like to cancle Jan 22 and Jan 29 meetings
14:57:46 <kragniz> mclaren: that looks useful
14:57:53 <flaper87> mclaren: yeah, that. They used to call that script in the gate
14:58:10 <sigmavirus24> nikhil_k: is there a good reason to not keep next week's meeting?
14:58:12 <jokke_> nikhil_k: would be great to have them
14:58:46 <jokke_> nikhil_k: specially recap after the meetup
14:58:46 <flaper87> lets keep meeting
14:58:52 * flaper87 won't be at the mid cycle meetup
14:59:00 <pkoniszewski> yep, lets keep the next week meeting
14:59:02 <nikhil_k> I thought people don't like meetings, guess not true
14:59:03 <pennerc> I agree.
14:59:03 <kragniz> I'd rather keep them
14:59:32 <sigmavirus24> nikhil_k: just because I don't like them doesn't mean they're not valuable ;)
14:59:40 <nikhil_k> ok cool
14:59:46 <nikhil_k> anything else?
14:59:47 * jokke_ agrees with sigmavirus24
15:00:04 <sigmavirus24> ^5 jokke_
15:00:19 <nikhil_k> Thanks all!
15:00:21 <nikhil_k> #endmeeting