14:00:44 <nikhil> #startmeeting glance
14:00:45 <openstack> Meeting started Thu Jul 21 14:00:44 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:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:48 <openstack> The meeting name has been set to 'glance'
14:00:54 <nikhil> someone has messed up the etherpad
14:01:05 <rosmaita> hopefully not me
14:01:10 <nikhil> all the text on info, best practices etc are gone
14:01:14 <jokke_> o/
14:01:22 <croelandt> \o
14:01:27 <itisha> o/
14:01:27 <nikhil> all: please try to undo your changes and see if we can recover stuff
14:01:31 <rosmaita> definitely not me
14:01:36 <rosmaita> o/
14:01:53 <abhishekk> o/
14:02:04 <mfedosin> maybe we should use wiki for agenda?
14:02:05 <hemanthm> nikhil: I added the alembic one yesterday
14:02:14 <nikhil> I will try to create more reliable docs for this round
14:02:25 <nikhil> no, let's not change the etherpad
14:02:35 <bunting> you can rewind bits
14:02:43 <bunting> I just added it all back
14:02:53 <nikhil> and wiki needs lot of updating and is inaccessible for those who don't have account (new accounts suspended)
14:03:09 <kairat> o/
14:03:18 <nikhil> bunting: you using the history/timeslider?
14:03:27 <bunting> yeah, i just copied it
14:03:33 <bunting> pasted it in
14:03:33 <nikhil> thanks
14:03:42 <hemanthm> I may have missed the 24hr deadline, will move my item
14:03:43 <nikhil> good stuff
14:04:00 <nikhil> in any case, I think this is a alarm for more permanant docs
14:04:07 <rosmaita> +1
14:04:08 <nikhil> because the history is limited
14:04:16 <kairat> wow, new font)
14:04:24 <nikhil> and next time it happens we may not be lucky
14:04:31 * nikhil stops his rage
14:04:35 <nikhil> let's move on
14:04:47 <nikhil> #topic Glare Updates ( mfedosin )
14:04:55 <mfedosin> hi folks
14:05:10 <nikhil> #info agenda for today https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:05:16 <rosmaita> hi mike!
14:05:18 <mfedosin> last week we uploaded a set of patches on review
14:05:46 <mfedosin> it's working glare code that can be used in production
14:06:10 <mfedosin> based on this code we're developing artifact types for Heat, Murano and Tosca
14:06:32 <mfedosin> https://review.openstack.org/#/c/343787/
14:07:17 <mfedosin> a couple of small issues were found - one file is placed in wrong commit and jsonpatch is not validated properly
14:07:30 <mfedosin> but other things are good :)
14:07:53 <mfedosin> all core members are added in reviewers of the code
14:08:06 <mfedosin> so we're waiting your feedback
14:08:42 <nikhil> excellent
14:08:57 <mfedosin> nikhil: thanks, I know
14:09:02 <nikhil> Thanks for the updates!
14:09:24 <mfedosin> maybe there are any questions?
14:09:34 <nikhil> I hope that the team will feel free to casually disucss glare code on openstack-glance
14:09:50 <kairat> yeah
14:10:09 <kairat> we also asked about feedback about heat artifact from heat team
14:10:13 <nikhil> especially if you need more clarifications on reivews (please link such convos eavesdrop weblink to the reviews)
14:11:10 <kairat> I am thinking about a doc that explains some enhancements in glare that could be used by Glance
14:11:28 <kairat> for example, how glare treat policies
14:11:38 <kairat> what glare did with custom locations
14:11:48 <mfedosin> kairat: yeah, it's a good enhancement
14:11:57 <kairat> how we implemented micro-versioning
14:12:12 <kairat> I think a lot of these enhancements can be easily used by Glance
14:13:03 <nikhil> great
14:13:12 * nikhil waits for the document
14:13:15 <kairat> for example, microversioning framework can be used by Glance IMO without big troubles
14:13:28 <kairat> except compatibility but I am not sure
14:13:34 <kairat> So what do you think?
14:13:38 <mfedosin> policies as well
14:13:41 <kairat> nikhil, ok
14:13:49 <nikhil> we need specs for all of these :)
14:14:08 <nikhil> I think flaper87 wanted to adopt microversioning but I'm not sure if he's b/w
14:14:42 <nikhil> mircroversioning by itself may not be enough for glance, we may need to implement stuff in client and collab with osc
14:15:00 <kairat> yep
14:15:01 <nikhil> anyway, I want to stop thinking ahead
14:15:11 <kairat> server is not enough
14:15:18 <kairat> but it is starting point
14:15:51 <nikhil> But all of these are great ideas and definitely worth implementation. Let's just make sure we plan different priorities properly so that not everything is congested in one cycle.
14:17:12 <nikhil> should we move on?
14:17:27 <mfedosin> only one question
14:18:22 <nikhil> mfedosin: yeas?
14:18:22 <mfedosin> feature freeze will be next week
14:18:39 <mfedosin> 29th of July afaik
14:19:13 <nikhil> mfedosin: feature frezze is NOT next week
14:19:27 <nikhil> #info glance project specific dates : http://lists.openstack.org/pipermail/openstack-dev/2016-May/094780.html
14:19:32 <mfedosin> just spec freeze?
14:20:00 <nikhil> #action nikhil : add the dates to a permanant location (see if release team is still accepting updates)
14:20:12 <mfedosin> oh :)
14:20:20 * nikhil thinks only if that thread did not start a conversation, we'd have those dates on release page
14:20:29 <kairat> mfedosin, it is spec freeze
14:20:35 <mfedosin> so, that's great then
14:20:48 <nikhil> moving on
14:20:54 <jokke_> yeah there is good month to get the code reviewed ... no panic
14:21:15 <nikhil> #topic Nova v1, v2 updates ( nikhil )
14:21:25 <nikhil> #info use_glance_v1 defaults to false, glance v1 deprecated in nova, move to glance v2 to upgrade nova to ocata
14:21:45 <nikhil> Useful links:
14:21:47 <mfedosin> I saw there had been some issues with snapshot creation
14:21:50 <nikhil> #link https://github.com/openstack/nova/blob/11f8c1bc3ce07cb5ffe52f6dbd5d4892bfa9c4e3/nova/conf/glance.py#L51-L74
14:21:57 <nikhil> #link http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/deprecate-api-proxies.html
14:22:04 <nikhil> #link http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2016-07-20.log.html#t2016-07-20T16:07:54
14:22:15 <nikhil> a related bug in snapshot creation:
14:22:34 <nikhil> #link https://bugs.launchpad.net/python-glanceclient/+bug/1596602
14:22:34 <openstack> Launchpad bug 1596602 in python-glanceclient "Instance Snapshot failure: "Unable to set 'kernel_id' to 'None'. Reason: None is not of type u'string'"" [High,Confirmed] - Assigned to Mike Fedosin (mfedosin)
14:23:20 <nikhil> #startvote Should we (glance team) start v1 deprecation in Newton? (yes, no, will-get-back)
14:23:21 <openstack> Begin voting on: Should we (glance team) start v1 deprecation in Newton? Valid vote options are , yes, no, will-get-back, .
14:23:23 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
14:23:32 <nikhil> #vote yes
14:23:33 <jokke_> #vote yes
14:23:47 <jokke_> not start ... we should deprecate it in Newton as agreed
14:24:01 <nikhil> jokke_: yes, thanks for clarifying
14:24:17 <nikhil> by start, I only mean that we start the deprecation period
14:24:30 <nikhil> which at this point seems to be 2 cycles
14:24:31 <jokke_> https://review.openstack.org/#/c/328390/
14:24:50 <mfedosin> #vote yes
14:24:55 <rosmaita> #vote yes
14:25:00 <bunting> #vote yes
14:25:16 <kairat> #vote yes
14:25:26 <rosmaita> but i think the deprecation period also depends on replacement functionality being available, e.g., copy-from
14:25:27 <kairat> If we deprecate this
14:25:44 <kairat> we need to implement image refactor in two cycles
14:25:51 <kairat> ++ to rosmaita
14:25:55 <nikhil> rosmaita: correct, and we need to prioritize those features accordingly
14:26:17 <kairat> what about adding this to deprecation description?
14:26:49 <jokke_> I don't think the image refactor has too much to do with the deprecation of v1 (specially now when our major consumers are moved to use the current v2 API)
14:26:59 <nikhil> we need a full spec
14:27:04 <nikhil> we can discuss details there
14:27:09 <kairat> ok
14:27:18 <kairat> at least horizon has troubles with migration
14:27:27 <kairat> AFAIK
14:27:29 <mfedosin> and Heat
14:27:35 <nikhil> #action nikhil: start a full spec collaboration on glance v1 deprecation
14:27:36 <kairat> ah, yes
14:28:08 <nikhil> yeah, I think their issues are not as complex as nova
14:28:20 <jokke_> yes both of them do rely on copy-from but there is workarounds for copy-from
14:28:29 <nikhil> so, they can adopt parity features as soon as they are available
14:28:43 <jokke_> nova and cider were the biggest pain points and specially Nova
14:29:13 <kairat> so it would be good for them to use our approach instead re-implementing it in other projects=)
14:29:15 <nikhil> like I said before all the uses case behind 'copy-from' are not covered by the workaround
14:29:17 <jokke_> s/cider/cinder/
14:29:31 * rosmaita likes cider
14:29:36 <kairat> heh
14:29:54 * nikhil is frustrated why people aren't able to digest the issues workaround creates in glance
14:30:04 <hemanthm> #vote yes
14:30:19 <nikhil> ok, I'm moving on for now
14:30:24 <nikhil> #endvote
14:30:25 <openstack> Voted on "Should we (glance team) start v1 deprecation in Newton?" Results are
14:30:27 <openstack> yes (7): bunting, nikhil, hemanthm, mfedosin, kairat, jokke_, rosmaita
14:30:42 <nikhil> #topic Releases ( nikhil )
14:30:53 <nikhil> two releases this week
14:30:58 <nikhil> #info glanceclient 2.2.0 http://lists.openstack.org/pipermail/openstack-announce/2016-July/001363.html
14:31:06 <nikhil> #info glance_store 0.14.0 http://lists.openstack.org/pipermail/openstack-dev/2016-July/099660.html
14:31:42 <nikhil> we may need to request some lib release for the docs gate job that is broken
14:31:45 <kairat> cool!
14:32:09 <nikhil> example for docs gate failure: http://logs.openstack.org/23/337323/3/gate/gate-glance-docs/c7bc845/
14:32:30 <nikhil> I did not have b/w to dig further
14:32:45 <nikhil> so, this is email I sent to docs list http://lists.openstack.org/pipermail/openstack-docs/2016-July/008899.html
14:33:02 <nikhil> moving on
14:33:08 <nikhil> rosmaita: is the next topic yours?
14:33:23 <kairat> looks like somebody use + with translation messages
14:33:31 <kairat> or with lazy strings
14:33:37 <rosmaita> i put it on, but it's really bunting and kairat
14:33:37 <kairat> need to dig into that
14:33:50 <nikhil> looks like some cinder endpoint translation
14:33:51 <bunting> Ah its about my patch
14:34:07 <nikhil> thanks rosmaita
14:34:22 <kairat> ah, that's about policies
14:34:27 <rosmaita> yes
14:34:31 <nikhil> #info all: please type your/interest/proposer irc nick after your topic in meeting agenda
14:34:45 <nikhil> #topic Glance has been introducing policies to address specific use cases; Glare is using more general policies with specific use cases met by carefully constructed rules ( kairat , bunting )
14:35:03 * nikhil hands the mic to bunting
14:35:07 <kairat> So I didn't add that topic but will comment anyway =)
14:35:16 <nikhil> #link https://review.openstack.org/#/c/256381/
14:35:33 <bunting> This is about my patch to introduce the new policy delete_deactivated_image, however kairat says this could possibly be done with a complex rule
14:36:02 <bunting> There is quite a bit of disucssion that took place on the bug
14:36:15 <kairat> that could be done with policies AFAIK
14:36:40 <nikhil> I like what kairat proposed on commenton PS13 (jul 18)
14:36:52 <kairat> so I am wondering why we need to introduce new policy instead of use existing policy functionality
14:37:14 <nikhil> (but I haven't evaluated on why so and the consequences)
14:37:17 <bunting> kairat: I don't really understand how we would be able to add this in our existing policies
14:37:30 <kairat> you don't need to
14:37:41 <bunting> since delete_image does not let a user delete another persons image
14:37:44 <kairat> you can just provide instructions how to do that
14:38:13 <bunting> which this patch wants to open up
14:38:21 <bunting> (as long as its deactivated)
14:38:28 <kairat> so is it possible to delete with separate policy?
14:39:08 <bunting> That's what the patch aims to do, allow a user to delete another users image if its deactivaed
14:39:18 <jokke_> I like that rule approach as well if that works
14:39:27 <bunting> The example given was a security group that does not have to be given admin
14:39:49 <rosmaita> my concern is how complex the rules will be ... i think we will have to provide some kind of support for operators, because it will be easy to write a rule that isn't quite correct
14:40:08 <kairat> bunting, sorry, it is not clear for me why do we need to allow another users to delete de-activated images>
14:40:50 <rosmaita> kairat: it's a special image-cleanup crew, who aren't admins, but have the responsibility for investigating a "bad" image
14:40:53 <kairat> will the tenant be different?
14:40:55 <nikhil> rosmaita: correct, we need some solid example on how to write rules
14:41:05 <nikhil> examples*
14:41:06 <rosmaita> the use case is that the operator doesn't want the owner to delete the "evidence"
14:41:16 <kairat> hm, so you can do that as well with policies
14:41:31 <kairat> I will explain that in review
14:41:37 <rosmaita> kairat: i think you are right, it's the complexity that bothers me
14:41:43 <jokke_> rosmaita: yes, that's the use case I understood as well, now it seems to be turned around
14:42:13 * jokke_ goes back and looks the spec
14:43:11 <nikhil> rosmaita: I think I am missing something
14:43:13 <bunting> Ah, i see, we built upon that idea, to produce the next spec
14:43:18 <bunting> #link https://review.openstack.org/#/c/309346/
14:43:24 <jokke_> so the lite-spec discusses about permitting user deleting the image it owns but is deactivated
14:43:33 <bunting> I merged them in my head
14:43:51 <rosmaita> jokke_: current situation: owner can delete a deactivated image
14:43:59 <jokke_> rosmaita: yes
14:44:05 <rosmaita> bunting's patch: introduce a policy to govern that
14:44:08 <kairat> bunting, that's also can be covered with policies AFAIU
14:44:20 <jokke_> rosmaita: and the lite-spec that the change is referring to addresses that specific case
14:44:44 <nikhil> rosmaita: kairat : can we talk tradeoffs? (rather than what we can and cannot do)
14:44:47 <rosmaita> yeah, the lite-spec allows you to restrict who can delete a deactivated image if you like
14:45:09 <rosmaita> well, the tradeoff is: policy-per-action: easy for ops to configure
14:45:13 <kairat> nikhil, IMO it is better to provide a guide and not support them
14:45:14 <rosmaita> downside is pain for devs
14:45:57 <nikhil> rosmaita: kairat : just that the policy remains upstream for us to consider another use case while developing?
14:45:58 <kairat> we can also provide some default rules by default that can be used by ops for convinience
14:46:15 <jokke_> I'm any day willing to trade dev pain to user ease
14:46:31 <rosmaita> i was thinking some kind of "policy cookbook"
14:46:48 <rosmaita> but we would have to have tests to go with the policies to guarantee them
14:47:08 <jokke_> rosmaita: ++
14:47:09 <nikhil> I think jokke_ meant 'for user ease' (based on knowing his intentions from prior conversations)
14:47:10 <rosmaita> and maybe we should wait for the policy yaml stuff, not sure when that is happening in oslo
14:47:33 <kairat> additionally, I would like to have default policies in code before introducing new policies
14:47:41 <rosmaita> kairat: ++
14:47:45 <jokke_> worst case scenario is that we offer policy rule to address usecase X and 3 months later we change the code invalidating that rule but don't catch it
14:47:55 <rosmaita> we need to do something like: https://blueprints.launchpad.net/nova/+spec/policy-in-code
14:47:58 <jokke_> nikhil: indeed
14:48:07 <kairat> +100500
14:48:11 <kairat> to rosmaita =)
14:48:25 <kairat> Glare did that without big troubles
14:48:37 <mfedosin> also kairat implemented it in glare
14:48:39 <nikhil> how bad is the need for this change?
14:48:49 <mfedosin> #link https://review.openstack.org/#/c/292327/48/glance/common/glare/policy.py
14:48:50 <bunting> But does that only change the default, which is slightly different problem?
14:49:00 <mfedosin> we can use it as example
14:49:17 <bunting> since a cookbook would have multiple
14:49:59 <nikhil> changing policy behavior is literally changing core of glance
14:50:25 * nikhil thinks that should be carefully vetted rather than copied from other places
14:50:36 <kairat> with policy-in-code we do not change anything
14:50:41 <jokke_> _if_ we agree on need to do some heavy refactoring on our policy code before facilitating, I'd propose to investigate the use of the rules to work around instead of adding stuff to our policies we need to refactor (and potentially break doing so)
14:50:42 <rosmaita> i think that's why kairat brought it up ... we will have to support all the old policies, so we should be careful about adding new onew
14:50:53 <nikhil> == jokke_
14:51:24 <nikhil> rosmaita: I am still dubious on the 'requirement' piece
14:51:37 <rosmaita> nikhil: how do you mean?
14:51:50 <nikhil> we are proposing heavy changes when glance is already bogged down with even more important and pressing ones
14:51:54 <kairat> additionally, users now have possibility to control behavior for de-activated images
14:52:19 <kairat> so do we need to introduce one more approach for that for convenience only now
14:52:58 <kairat> I mean if somebody would need that we can provide a doc as alternative
14:53:19 <nikhil> in any case, I think the whys (use cases) that trigger this level of change need to be written down
14:53:38 <kairat> nikhil, yep, agree
14:53:54 <nikhil> I like to think from source and I am a bit confused on the value addition
14:54:24 <nikhil> source == requirement giving birth to this change
14:54:31 <nikhil> anyway, let's continue in open discussion
14:54:35 <nikhil> #topic open discussion
14:54:45 <kairat> alembic?
14:54:48 <kairat> hemanthm, ^
14:54:52 <nikhil> hemanthm: you can start today and let's see if we can continue later
14:54:56 <hemanthm> yep
14:55:00 <hemanthm> In the last meeting, we discussed adopting expand/contract style for glance migrations.
14:55:04 <hemanthm> Looking further it appears that we may have to move to alembic from sqlalchemy-migrate.
14:55:07 <hemanthm> And, here's why.
14:55:13 <hemanthm> Splitting migrations into expand and contract essentially results in two parallel migrations streams.
14:55:17 <jokke_> the midcycle Glare session is up and available https://youtu.be/FgbgiaAFGxE
14:55:22 <hemanthm> We currently keep just one migration stream that's maintained with a numeric prefix to the migration file.
14:55:28 <hemanthm> Once we split the migrations, we need to maintain two such streams, which isn't possible with sqlalchemy-migrate.
14:55:31 <hemanthm> Or let's just say sqlalchemy isn't designed for it.
14:55:31 <kairat> jokke_, cool!
14:55:45 <hemanthm> *sqlalchemy-migrate I mean
14:55:50 <hemanthm> So, I was wondering if anyone of you here has experience working with alembic and can
14:55:53 <hemanthm> #1 confirm that my assessment is correct
14:55:56 <hemanthm> #2 comment on alembic in general and it's suitability for Glance
14:55:58 <nikhil> jokke_: I will add that to the midcycle page (if you dont' mind)
14:56:15 <jokke_> nikhil: go for it
14:56:33 <jokke_> nikhil: it's up there so people can watch it/refer to it
14:57:22 <jokke_> hemanthm: would that be introducing alembic as extra for migrations or replacing sqlalchemy?
14:57:30 <hemanthm> jokke_: replacing
14:57:56 <nikhil> jokke_: do you have the recording for specs discussion too?
14:57:58 <hemanthm> spoke to Mike Bayer as well, he thinks alembic is the way forward (just FYI)
14:58:15 <kairat> Unfortunately, I didn't have time to dig into alembic a lot
14:58:17 <hemanthm> Neutron already uses alembic
14:58:22 <jokke_> nikhil: hopefully tonight ... needs bit more work still
14:58:26 <mfedosin> hemanthm: I vote for alembic
14:58:28 <kairat> but from what I heard a lot of projects use it
14:58:37 <nikhil> well, I am skeptical on taking word of a single person
14:58:41 <jokke_> nikhil: will send both links to the ML when they are up
14:58:46 <mfedosin> kairat: yes, and they like it
14:58:52 <nikhil> hemanthm: I think this calls for a openstack-dev [all] discussion
14:58:57 <nikhil> (on ML)
14:59:03 <hemanthm> nikhil: that's just FYI
14:59:08 <hemanthm> not saying we should do it on his word
14:59:09 <nikhil> hemanthm: cool
14:59:27 <jokke_> Personally I think, if we need to move away from sqlalchemy, that's definitely out of the table for Newton
14:59:28 <nikhil> 30 seconds to go
14:59:40 <nikhil> == jokke_
14:59:44 <hemanthm> jokke_: +1 that's my concern too
14:59:51 <jokke_> We have lots of things that are not done in time already
15:00:00 <hemanthm> although I put up a change and we can take a call
15:00:14 <kairat> I heard from guys who tried to build glance on containers that they had troubles with sqlalchemy-migrate
15:00:22 <kairat> so I am for alembic too
15:00:25 <jokke_> hemanthm: happy to -2 it ;)
15:00:27 <nikhil> we're out of time
15:00:31 <jokke_> for newton
15:00:36 <nikhil> let's continue next week ( hemanthm )
15:00:37 <hemanthm> jokke_: sure, I'm used to it now :P
15:00:40 <jokke_> goodie
15:00:42 <nikhil> thanks all for joining!
15:00:44 <jokke_> thanks all!
15:00:45 <nikhil> #endmeeting