14:00:17 <rosmaita> #startmeeting glance
14:00:18 <openstack> Meeting started Thu Dec  7 14:00:17 2017 UTC and is due to finish in 60 minutes.  The chair is rosmaita. 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:22 <openstack> The meeting name has been set to 'glance'
14:00:26 <rosmaita> #topic roll call
14:00:28 <jokke_> o/
14:00:39 <bhagyashri_s> o/
14:00:51 <abhishekk> o/
14:02:08 <kairat> o/
14:02:42 <rosmaita> hello everyone!
14:02:55 <kairat> hi
14:03:01 <rosmaita> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:03:06 <rosmaita> hi kairat , good to see you
14:03:45 <rosmaita> #topic updates
14:04:05 <rosmaita> #topic updates - Q-2 milestone
14:04:21 <rosmaita> #link https://etherpad.openstack.org/p/glance-queens-Q2
14:04:39 <arcolife> o/
14:04:42 <rosmaita> it seems like every patch has needed a rebase
14:04:46 <rosmaita> on every submission
14:05:06 <rosmaita> and the gate has been slow anyway
14:05:15 <rosmaita> so it's been taking forever to get things merged
14:05:26 <arcolife> rosmaita, abhishekk shall I rebase and submit again finally? https://review.openstack.org/#/c/523028/
14:05:29 <abhishekk> unfortunately changes were in one or two files, I should have created dependency :(
14:05:34 <arcolife> it seems the conflicting patch has been aceepted
14:05:39 <arcolife> s/accepted
14:06:06 <kairat> do we the newscrubber work with ssl after refactor?
14:06:41 <abhishekk> arcolife: not yet
14:06:45 <kairat> i am talking about https://review.openstack.org/#/c/510449/
14:07:17 <jokke_> kairat: both glance_store and oslo_db iiuc supports ssl, so yes
14:07:35 <kairat> cool
14:07:43 <gb21> \o
14:08:52 <rosmaita> so that patch has no +2s ... i was testing it out but got completely sidetracked because something is weird about the scrub time
14:09:10 <rosmaita> it's not because of wxy's change though
14:09:12 <jokke_> rosmaita: so due to the gate speed, I proposed the release from what we had merged.
14:09:35 <jokke_> that was about an hour ago
14:09:41 <rosmaita> yeah, i guess it's a moot point
14:10:10 <rosmaita> ok, we will make it a priority for this week to get the scrubber merged
14:10:35 <rosmaita> so basically, all we have into Q2 is some bugfixes
14:10:53 <jokke_> it's a milestone release anyways. obviously I would have lowed to see all the fixes being in the release, but we won't get it out this week if we wait those
14:10:54 <rosmaita> do we need a release note? because that will take hours to merge
14:11:25 <jokke_> rosmaita: IIRC we don't necessarily need renos for milestones
14:11:39 <abhishekk> right
14:11:45 <jokke_> we really need to start making it a habbit those renos being part of the patch
14:12:09 <abhishekk> good idea
14:12:15 <rosmaita> we usually do for features
14:12:25 <rosmaita> we don't want to require a release note for every bug fix
14:12:49 <abhishekk> for bug fixes if it is a api change then we demand for a release note
14:13:03 <kairat> +1
14:13:12 <kairat> api change is not a bug fix =)
14:13:13 <jokke_> well it would make the release life so much easier if there is reno with bugfix
14:13:31 <kairat> +1 to not require for each bug fix
14:13:50 <abhishekk> I mean to say APIImpact
14:13:55 <rosmaita> the release announcement has a list of the bugfixes
14:14:09 <rosmaita> let's go with no special releasenote for Q-2 and see what happens
14:14:34 <rosmaita> ok, one other thing
14:14:46 <jokke_> rosmaita: as said, the release patch is up already, so yeah I'd agree ;)
14:14:55 <rosmaita> i've been working on getting the glanceclient gate working again
14:15:13 <jokke_> ++
14:15:46 <rosmaita> hope to get that done today, there's a problem with devstack and the mysql password
14:16:13 <rosmaita> if anyone wants details, will be happy to give them after the meeting
14:16:29 <rosmaita> #topic updates - barbican
14:16:42 <rosmaita> this is an awareness thing, i don't think it affects glance
14:16:54 <rosmaita> though i am bringing it up just to make sure it does not affect glance
14:17:17 <rosmaita> barbican has provided services to issue certs, it will no longer do that
14:17:22 <rosmaita> info is here:
14:17:34 <rosmaita> #link https://review.openstack.org/#/c/462363/
14:17:40 <rosmaita> the releasenote has a summary
14:18:01 <rosmaita> it will still store and serve out certs, which is what we use it for
14:18:14 <rosmaita> (for the image signature stuff)
14:18:42 <jokke_> hmm-m that's interesting shift in the community
14:19:00 <rosmaita> so i don't think there's any impact on us, but i said i'd inform the glance community and ask at our meeting if there is any impact
14:19:14 <jokke_> suddenly we see people not totally loosing their crap when projects starts removing functionality from their APIs ...
14:19:45 * jokke_ likes that evolving the services is actually let to happen
14:20:12 <kairat> i have not seen anybody used barbician in prod
14:20:15 <kairat> tbh =)
14:20:22 <kairat> maybe it is me
14:20:46 <kairat> maybe it is because of barbician=)
14:20:48 <rosmaita> yeah, it's not widely used, i think mostly universities and labs
14:20:48 <jokke_> kairat: yes it's just you :P
14:21:19 <rosmaita> #topic updates - community goals for Rocky
14:21:20 <kairat> well, that's great then=)
14:21:34 <rosmaita> #link http://lists.openstack.org/pipermail/openstack-dev/2017-November/124976.html
14:21:58 <rosmaita> i am thoroughly sick of community goals, they have not worked out well for glance
14:22:16 <rosmaita> plus, this zuul3 migration is causing quite a bit of work
14:22:18 <jokke_> rosmaita: totally agree
14:22:35 <rosmaita> nothing against zuul3 -- it's great -- but it has a learning curve
14:22:59 <rosmaita> i think once it's set up, we'll have more control over our jobs, but the problem is getting to that point
14:23:31 <rosmaita> so i am tempted to propose a no-op community goal
14:23:47 <rosmaita> either that, or a general technical debt cleanup goal
14:24:02 <rosmaita> each project would propose to clean up a particular item
14:24:10 <rosmaita> but not all projects woudl have to clean up the same item
14:24:16 <jokke_> I kind of dislike the fact that it seems consistently break the world and the "backwards compatibility" what community expects from everyone else seems to be "Just do the work to migrate the new flow and everything will be fine"
14:24:36 <jokke_> rosmaita: Do it!
14:25:04 <jokke_> totally +1 for the no-op
14:25:44 <abhishekk> +1
14:26:36 <rosmaita> ok, then i'll find some time to do that
14:26:56 <rosmaita> the only proposal i'm aware of is to migrate everyone to storyboard
14:27:31 <rosmaita> anyway, i want everyone to be aware that the discussion is happening so that we/you can register your opinion before things get decided
14:27:36 <jokke_> rosmaita: btw if you propose the no-op you can voluteer me to Champion it :D
14:27:48 <rosmaita> i am not clear on the timeline, not sure it was said in the email i referenced above
14:27:51 <abhishekk> :D
14:27:55 <rosmaita> jokke_ : accepted
14:28:24 <rosmaita> ok, that's all the updates
14:28:38 <rosmaita> #topic fault classification
14:28:50 <rosmaita> #link http://lists.openstack.org/pipermail/openstack-dev/2017-December/125082.html
14:29:19 <rosmaita> the "fault genes" working group is asking for data to work with
14:29:33 <rosmaita> i guess this impacts me, i'm expected to respond
14:29:49 <rosmaita> they are looking for failures and mitigations
14:29:50 <jokke_> I did read the e-mail ... formatting made it really painful and at the end I still have no idea what they are trying to achieve, what they actyally want and should I care
14:30:06 <rosmaita> yeah, the formatting was horrible
14:30:07 <abhishekk> exactly
14:30:26 <abhishekk> I am still not clear what they expect
14:30:45 <kairat> so they want target function between bugs and solutions=)
14:30:59 <kairat> good luck to them=)
14:30:59 <rosmaita> i'm not either, i brought it up hoping that someone here was super-excited about self-healing and wanted to work with them
14:31:12 <rosmaita> kairat: so glad to have you back at meetings!
14:31:39 <rosmaita> ok, i'll put together some kind of response so that glance is a good openstack citizen
14:32:04 <jokke_> rosmaita: you clearly have too much time in your hands :P
14:32:05 <kairat> yes, finally got some time to work in community+)
14:32:14 <rosmaita> #topic - policies and the policy layer
14:32:31 <rosmaita> the basic issue is how to have separate policies for stage_image and upload_image and also be able to reuse image.set_data() in both workflows
14:32:39 <rosmaita> it's brought on by this patch:
14:32:47 <rosmaita> https://review.openstack.org/#/c/524060/3/glance/api/v2/image_data.py@108
14:33:11 <rosmaita> kairat pointed out that the approach in the patch goes against glance architecture principles
14:33:22 <rosmaita> i think nikhil left an agreeing comment
14:34:08 <rosmaita> now i have to mention that i did a bad thing at the end of pike
14:34:14 <jokke_> kairat: are you deeply insulted if I express myself with "Feck the v2 domain architecture which is one of the biggest painpoints in the bollox and if we get rid of that layer, even better"? ;P
14:34:32 <rosmaita> i introduced a policy specifically to control whether you could use the tasks api or not
14:34:42 <rosmaita> and the check for that is in the controller
14:35:01 <kairat> so I completely agree with you jokke_
14:35:14 <jokke_> kairat ok cool!
14:35:23 <rosmaita> because it was another of these situations where the current policies had to be used from 2 different workflows
14:35:25 <jokke_> Feck the v2 domain architecture which is one of the biggest painpoints in the bollox and if we get rid of that layer, even better
14:35:25 <kairat> in Glare i just replaced all this stuff with one layeer tbh)
14:35:37 <abhishekk> (we are facing same with ImageSizeLimitExceeded i guess)
14:35:45 <kairat> it is not only to policy
14:36:12 <kairat> is policy is different then notifications might be also
14:36:16 <jokke_> kairat: nope, but that's likely the easiest layer to get rid of if we start working towards simplifying the core
14:36:23 <kairat> and so on and so on
14:36:40 <rosmaita> yeah, once the onion starts unravelling, who knows what will happen
14:37:04 <jokke_> we all will cry, a lot, until it gets better
14:37:25 <bhagyashri_s> i would like to hear which approach should i follow to fix this
14:37:32 <rosmaita> so the key question at this point is what bhagyashri_s just brought up
14:37:34 <kairat> so regarding this patch, it would be perfect if we get rid of policy layer first
14:38:18 <rosmaita> i'm worried about bandwidth
14:38:30 <rosmaita> it's pretty late in the cycle
14:38:38 <abhishekk> agree
14:38:49 <jokke_> yeah, I would not like to demand that from anyone, specially as it's addressing quite important part of the new API there
14:38:54 <rosmaita> i wonder whether we put these policies in the controller and take on some technical debt
14:39:14 <rosmaita> this could be our first step toward removing the policy layer
14:39:39 <rosmaita> because we'll need to make sure we have good test coverage before changing all the policy stuff
14:40:02 <jokke_> rosmaita: I'm all for that. perhaps we should get someone writing untargeted spec or at least dev doc paragraph for that 'though
14:40:31 <rosmaita> nikhil had a suggestion about using a staged image proxy or something
14:40:41 <jokke_> doesn't need to be part of this PS, but just so that we're clear why we are moving away from the old design and why we have stuff all over the place
14:41:14 <rosmaita> ok, well, i'll write up something this weekend as a spec draft
14:41:38 <rosmaita> do we want to agree now that bhagyashri_s patch is ok putting the policy stuff in the controller?
14:41:52 <jokke_> rosmaita: I'm totally fine with that
14:42:08 <abhishekk> +1
14:42:16 <rosmaita> and that if the spec to move policies isn't agreed on, we will have to rework bhagyashri_s policy-in-controller stuff
14:42:55 <rosmaita> we can look at bhagyashri_s patch as an experiment for how we want to migrate the policy code
14:43:38 <rosmaita> kairat how does that sound to you?
14:43:56 <jokke_> although I'm bit concerned putting even policy control to the import, but maybe it's just deployer headache if the want to fool around with it
14:44:12 <rosmaita> i think we need to have it
14:45:10 <rosmaita> ok, at least this unblocks bhagyashri_s
14:45:25 <rosmaita> #topic backports to stable/pike
14:45:35 <rosmaita> actually, one backport is on my mind
14:45:57 <jokke_> why? we have already create image policy and I'm not convinced that anyone should be allowed to create image but not use the import to make it happen ... but as said we're total mess anyways so maybe it's just one more thing to add to deployers problems
14:45:57 <rosmaita> #link https://bugs.launchpad.net/glance/+bug/1718125
14:45:57 <openstack> Launchpad bug 1718125 in neutron "Missing some contents for install prerequisites" [Undecided,In progress] - Assigned to Eric Xie (eric-xie)
14:46:55 <rosmaita> jokke_ if you can't create an image with current policies, aren't you prohibited from making server images?
14:47:34 <jokke_> rosmaita: we can continue that on glance channel after the meeting or open discussion if we have time
14:47:45 <rosmaita> jokke_ agreed
14:48:01 <rosmaita> anyway, this bug was a doc fix which has happened in master
14:48:38 <rosmaita> problem is, people are looking at the pike docs, where it's missing
14:48:51 <rosmaita> big net split event ... anyone still here?
14:48:55 <McClymontS> I am here
14:48:57 <abhishekk> I am
14:48:57 <jokke_> yeah
14:49:32 <rosmaita> so anyway, people wanting to use pike are being good openstack citizens and filing a bug about the incorrect docs
14:49:42 <jokke_> rosmaita: if you have well contained patch we can backport, sure thing ... I'm all up for fixing the stable docs
14:49:51 <rosmaita> so i'd like to backport the doc fix and republish
14:50:04 <rosmaita> i don't know whether republication would happen automatically or not
14:50:28 <jokke_> rosmaita: we can figure that out with dhellmann or someone else who actually know how the doc builds works
14:50:32 <rosmaita> right
14:50:46 <rosmaita> so do we want to do just a docfix release of stable/pike?
14:50:56 <rosmaita> or look for other worthy backports?
14:51:20 <jokke_> I'm not sure if we need to even release for that, but lets figure it out
14:51:37 <jokke_> I think the docs might be built on post
14:51:46 <rosmaita> ok, too bad sean isn't here today
14:52:00 <jokke_> I think he might b bit busy with releases
14:52:08 <rosmaita> oh yeah ... that
14:52:24 <rosmaita> ok, i'll ask sean and doug for advice next week after the releases are out
14:52:37 <rosmaita> #topic open discussion
14:52:53 <jokke_> #success Glance Q2 is released
14:53:05 <rosmaita> wow, that was fast
14:53:07 <abhishekk> \o/
14:53:36 <jokke_> rosmaita: automation is incredible thing :D
14:53:36 <rosmaita> ok, congratulations everyone, and please celebrate by reviewing the scrubber refactor
14:53:49 <rosmaita> https://review.openstack.org/#/c/510449/
14:54:30 <rosmaita> i was playing with the scrubber, and i don't know whether it's my setup or what, but the delay time isn't working quite right
14:54:55 <rosmaita> i think i have a mismatch between mysql utc in database and maybe local time in scrubber
14:55:09 <rosmaita> but i'm not sure
14:55:18 <rosmaita> in any case, that's independent of wxy's changes
14:55:29 <rosmaita> just wondering if anyone else had noticed that
14:55:39 <abhishekk> today I haven't got time to test but I will test it before monday
14:55:43 <bhagyashri_s> o/
14:56:09 <rosmaita> abhishekk that's fine
14:56:18 <bhagyashri_s> sorry to interrupt actually my hexchat application was suddenly off
14:56:22 <rosmaita> let's aim to get the scrubber change merged by next week's meeting
14:56:27 <jokke_> rosmaita: are you sure it's independent? it does change how the time is evaluated
14:56:34 <bhagyashri_s> i lost the topic discussion
14:56:47 <jokke_> bhagyashri_s: open discussion
14:56:56 <rosmaita> jokke_ i'll have to look more closely
14:57:01 <bhagyashri_s> i would like to put some points here
14:57:11 <bhagyashri_s> Actaully I am ready with patch to add 'import_image' policy as per the kairat sugesstion to implement policy checks in policy layer as per the architecture of v2 in glance.
14:57:18 <bhagyashri_s> As the policy name is hard-coded in code so IMO we will need separate method ( for example set_import_data()) implementation like set_data() method for 'import_image' policy at each layer (domain, location, proxya and notifier) etc.
14:57:22 <abhishekk> bhagyshri_s: no need to make any changes to your patch as of now
14:57:30 <bhagyashri_s> i will check the logs as well
14:57:39 <rosmaita> bhagyashri_s thanks
14:57:44 <bhagyashri_s> And one more point that I have observed and would like to say you on the current master: no policy is applied for stage API call (in short set_data() method is not used or come in pictureat the time of stage) so how and where this newly introduce policy 'stage_image' will be applied? because image data is set using the add() method
14:58:55 <rosmaita> bhagyashri_s i think it will have to be applied at the controller
14:59:29 <bhagyashri_s> yeah on the current patch is possible
14:59:46 <rosmaita> we can continue discussion in the glance channel, we're just about out of time
14:59:55 <bhagyashri_s> so should i make changes on same patch
15:00:13 <jokke_> sure, thanks all
15:00:18 <rosmaita> thanks everyone! and please review the scrubber patch! https://review.openstack.org/#/c/510449/
15:00:22 <bhagyashri_s> sure
15:00:27 <rosmaita> #endmeeting