14:00:04 <abhishekk> #startmeeting glance
14:00:05 <openstack> Meeting started Thu Dec 19 14:00:04 2019 UTC and is due to finish in 60 minutes.  The chair is abhishekk. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:07 <abhishekk> #topic roll call
14:00:09 <openstack> The meeting name has been set to 'glance'
14:00:12 <jokke_> o/
14:00:15 <abhishekk> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:00:18 <abhishekk> o/
14:00:21 <yebinama> o/
14:00:24 * tosky lurking
14:00:34 <abhishekk> jokke_, could you pleasee co chair this meeting with me?
14:00:53 <rosmaita> o/
14:01:07 <abhishekk> I don't have electricity since morning and my laptop may dry any moment
14:01:14 <jokke_> abhishekk: kk
14:01:24 <abhishekk> #chair jokke_
14:01:25 <openstack> Current chairs: abhishekk jokke_
14:01:39 <abhishekk> jokke_, thank you
14:01:54 <jokke_> np
14:02:04 <abhishekk> #topic Updates
14:02:28 <abhishekk> As discussed in last week, we will not have meeting next week on 26 December
14:02:55 <abhishekk> Ussuri milestone patch is up and updated, kindly review
14:03:10 <abhishekk> #link https://review.opendev.org/#/c/696017/
14:03:25 <abhishekk> #topic release/periodic jobs update
14:03:34 <abhishekk> periodic job is all green
14:04:08 <abhishekk> we are going to release M-1 for glance tomorrow
14:04:08 <jokke_> so based on the agenda I assume we did not release U1 milestone
14:04:31 <abhishekk> have couple of suggestions/questions around the same
14:04:36 <jokke_> releasing Friday is now a thing? :o
14:05:05 <abhishekk> should we include policy in code patch in M1?
14:05:47 <abhishekk> jokke_, no that is not the case
14:06:01 <abhishekk> #link https://review.opendev.org/693129
14:06:32 <abhishekk> I should have asked this earlier but I was busy and it slept out of my min
14:06:39 <abhishekk> s/min/mind
14:07:15 <abhishekk> apart from this, is there need to include empty alembic scripts?
14:08:34 <abhishekk> any suggestions or I got disconnected from here :O
14:09:16 <abhishekk> jokke_, rosmaita ?
14:09:39 <jokke_> just thinking, I can't remember if they were needed for the version bump or not
14:10:15 <rosmaita> i don't remember, but some tests will fail if some constants aren't updated
14:10:15 <abhishekk> jokke_, I don't think so
14:10:43 <rosmaita> we have some tests in tests/gate i think that will indicate what needs to be kept in sync
14:10:58 <abhishekk> rosmaita, I guess we have some release where we didn't have any script for that entire cycle
14:11:06 <jokke_> yeah, that's the part I can't remember if those constants needed the empty migrations or not
14:11:31 <jokke_> or if it broke trying to get the migrations (even empty) in before tagging the first on the series
14:11:50 <jokke_> I think it was the later, we need tag first before we can merge any migrations
14:12:12 <abhishekk> safe side we should add empty migration scripts
14:12:52 <jokke_> you can try, but I think it will fail the gate before tag
14:13:09 <abhishekk> ok, lets tag first then
14:13:39 <abhishekk> should we include policy in code patch as it is in good shape and resolved all the concerns?
14:13:44 <jokke_> I think we need empty migrations only if we're merging partials
14:13:57 <rosmaita> i think that is correct
14:14:25 <abhishekk> ok
14:15:04 <abhishekk> So I need to regenerate config files, and then tag the release
14:16:28 <jokke_> yeah, so if we want to include the policy, we should merge all the policy changes and include the example file with the example configs
14:17:01 <abhishekk> IMO we should get that in
14:17:37 <abhishekk> there will be now example policy file I guess
14:18:03 <jokke_> there is generator config in the policy change
14:18:30 <jokke_> then there is:
14:18:33 <jokke_> #link https://review.opendev.org/#/c/698793/
14:18:54 <abhishekk> (my laptop is dying quickly, will sustain next 10-12 minutes)
14:18:56 <jokke_> and
14:19:00 <jokke_> #link https://review.opendev.org/#/c/694387/
14:19:01 <rosmaita> i just -1d https://review.opendev.org/#/c/693129
14:19:58 <jokke_> abhishekk: ok, go ahead ... we can try to keep speed up to cover as much as possible while you're still online
14:20:13 <abhishekk> Ok, lets leave it for M2 then we will release with current status
14:20:32 <abhishekk> Will submit config regenerator patch if possible today
14:20:41 <abhishekk> and also tag the release as well
14:20:55 <abhishekk> Moving ahead,
14:21:14 <abhishekk> #topic Multiple store import plugins
14:21:24 <abhishekk> multiple import specs
14:21:31 <abhishekk> #link https://review.opendev.org/669201
14:21:48 <abhishekk> yebinama, sorry in last minute I have added one suggestion there
14:22:03 <abhishekk> do you have any questions around the same?
14:22:03 <yebinama> Yep, I've seen it :)
14:22:15 <yebinama> No, this one should be quite easy
14:22:46 <yebinama> I'm more "worried" by rosmaita's review
14:22:59 <abhishekk> he is here
14:23:01 <abhishekk> :d
14:23:28 <yebinama> He proposed to change allow_failure
14:24:20 <abhishekk> yes I saw that
14:24:25 <yebinama> to all_stores_must_succeed
14:24:46 <yebinama> Are everyone ok with that?
14:24:56 <yebinama> I think it'as a good idea
14:24:59 <abhishekk> if you rename it then you need to reverse all your current logic
14:25:05 <rosmaita> \o/
14:25:07 <abhishekk> I am ok with it
14:25:30 <yebinama> Yes that's why I prefer to be sure everyone agrees before doing it
14:25:46 <rosmaita> it's good to check, becasue we will have to live with it for a long time
14:25:56 <abhishekk> +1
14:26:19 <abhishekk> it is meaningful as well
14:26:37 <jokke_> Is that clear enough, or will we need longer novel next when we figure out corner case for it?
14:27:07 <rosmaita> you'd think jokke_ was being charged by the character
14:27:17 <jokke_> I think there is 2 things here: 1) How the API operates and 2) how it's documented
14:28:06 <rosmaita> well, the problem is that allow_failure isn't attached to the "stores" element in the json
14:28:41 <jokke_> and then we can bikeshed how much we want about the color of the option, it win't change the fact that world will find dumb enough user for us who manages to misunderstand it :P
14:28:46 <rosmaita> so if you want to do "stores": {[s1, s2], "allow_failure": true} then i am ok
14:30:57 <rosmaita> i think this is where i bring up sean's example of we're not talking about the color of the bikeshed, just whether we build it next to the house or in the middle of the driveway
14:31:19 <abhishekk> I think we should rename it instead of adding one more layer of dict in the body
14:31:59 <yebinama> Or maybe we can just ensure to have a clear documentation?
14:32:23 <abhishekk> It is a good suggestion and as the work is still in progress we should do it now
14:32:39 <rosmaita> nobody reads the documentation :)
14:33:06 <abhishekk> :D still we need to have clear documentation as well
14:33:30 <rosmaita> agreed
14:33:33 <abhishekk> (last 5 minutes)
14:33:38 <jokke_> yebinama: what rosmaita said as well. So It really doesn't matter. We could call it F=True and no-one would pay any attention to it anyways :P
14:34:04 <yebinama> So why bother with it? :p
14:34:05 <rosmaita> the json is supposed to be self-documenting
14:34:13 <rosmaita> allow_failure is too vague
14:34:23 <yebinama> Maybe we can go with allow_upload_failures?
14:34:39 <yebinama> To not change the logic
14:34:52 <rosmaita> except it's not upload, it's import
14:34:52 <jokke_> lets take this offline and keep going as long as we have abhishekk with us
14:35:08 <jokke_> rosmaita: well it's upload failure during import :P
14:35:18 <rosmaita> i guess the thing i really want to know is how the extra properties will be handled
14:35:41 <yebinama> yes It's the other thing I wanted to discuss
14:35:43 <abhishekk> rosmaita, I guess you are ok with copy existing image specs
14:36:10 <rosmaita> yes, just this same issue about the exrta properties
14:36:11 <abhishekk> you guys can continue discussion, I will go through logs later
14:36:23 <rosmaita> happy holidays, abhishekk!
14:36:24 <abhishekk> just one minute remaining
14:36:43 <abhishekk> rosmaita, thanks
14:37:03 <jokke_> rosmaita: so when I proposed those properties, it was never meant to be to use on any level of control (thus I said we should just use the normal properties to indicate the status)
14:37:03 <abhishekk> jokke_, yebinama thank you
14:37:21 <yebinama> thanks abhishekk, bye
14:37:37 <abhishekk> I will propose config generator patch if electricity is restored
14:37:45 <smcginnis> Good luck!
14:37:56 <jokke_> rosmaita: whole point was to have some messaging going to the user what's happening that the user can easily clear themselves
14:38:02 <yebinama> Aren't notifications enough?
14:38:15 <rosmaita> notifications aren't necessarily exposed to end users
14:38:19 <jokke_> yebinama: no-one has any mechanism to follow up notifications
14:38:37 <yebinama> I have one :p
14:38:55 <jokke_> I don't think any deployers lets users to tap into even notification queues of their rabbit
14:39:17 <yebinama> Going through the code, I found that there is a status for each location of the image
14:39:30 <yebinama> But It is only set to "active"
14:39:35 <jokke_> yebinama: so you guys let your normal users to consume notifications? nice
14:39:40 <rosmaita> jokke_: that's fine, i just wanted to make sure that we aren't relying on the content of the properties, since  auser can monkey with it
14:40:05 <rosmaita> also, whether we are going to leave them there or delete them or what
14:40:05 <yebinama> jokke: we send it to another public rabbit where users can subscribe
14:40:25 <jokke_> rosmaita: yeah, absolutely not, just something the user can monitor and either clear themselves or wil be reset when next task runs agains that image
14:40:30 <jokke_> yebinama: oh, cool
14:40:54 <yebinama> Could we use the status of the locations?
14:40:58 <jokke_> rosmaita: I think it was in the spec, that they are to be cleared if new task is ran
14:41:18 <yebinama> jokke_: exact
14:41:19 <jokke_> yebinama: again, users should not have access to the locations ... bad for security
14:41:19 <rosmaita> yes, but cleared meaning "set to None" or deleted
14:42:05 <jokke_> yebinama: we have big hairy OSSN about that :P
14:43:41 <jokke_> rosmaita: so my take is, we clear&reuse if needed, we allow user to clear (or do what they want with them) and other than that we just leave them. As how would we determine when it's right time to clear them automatically
14:43:57 <jokke_> rosmaita: so rather just leave and let user to clear if they wish
14:44:15 <rosmaita> well, the stores_to_be_processed is no longer needed when its empty
14:44:18 <jokke_> rosmaita: and once all has succeeded, they will be cleared
14:44:22 <rosmaita> same deal with empty failures
14:44:26 <jokke_> yes, exactly
14:45:08 <yebinama> properties have to be string?
14:45:17 <rosmaita> yes, these do
14:45:17 <jokke_> so if the queue indicator and he failure indicator exists everything wen't great, if failure exists after queue does, we're done with some issues
14:45:45 <yebinama> rosmaita: ok. So we have to create a string with comma delimiter
14:45:49 <jokke_> if those two doesn't exist I was supposed to say
14:46:23 <rosmaita> well, like i said on the spec, i kind of like this idea ... the other option would be a "message" element on the image, we had talked about that a while back, but i think this may be better
14:47:43 <jokke_> rosmaita: I got quite fond of this after thinking of it. self explanary, easy to manage and user clearable.
14:48:02 <rosmaita> right, and doesn't pollute the images table
14:48:19 <jokke_> And indeed would give that little indication to the user we have been talking for about as long as those async ops have existed
14:48:44 <rosmaita> right, so the issue is how to handle these in teh image schema
14:48:59 <rosmaita> or not at all
14:49:38 <jokke_> I think easiest not at all, like with any other custom property
14:50:02 <rosmaita> ok
14:50:20 <jokke_> let user to clear them and show them if needed ... I think we don't have schema option for RD anyways
14:50:26 <jokke_> which would have been the optimal
14:51:32 <jokke_> ok, then there's the extension for this spec which is abhishekk's copy job spec
14:51:35 <jokke_> #link https://review.opendev.org/694724
14:51:39 <rosmaita> ok, cool, you've answered my questions.  key thing was, are these normal custom properties? answer is yes, and are we using them for control? answer is no
14:51:50 <jokke_> rosmaita: correct
14:52:19 <rosmaita> great, i left a comment on the copy spec, would like him to mention using these properties again
14:53:01 <rosmaita> because at least with import, there's an image status transition that indicates something happened
14:53:08 <rosmaita> with the copy, there won't be
14:53:15 <jokke_> sure technically and operationally he doesn't have choice so I didn't get tangled to that, but doesn't hurt there either
14:53:58 <jokke_> rosmaita: yeah, that's where the queue property specially will be big thing to actually know the task started at least
14:54:17 <rosmaita> exactly
14:55:06 <rosmaita> anyway, i like using the custom properties -- i would have gone with a "message" which would have been more complicated and not any better
14:55:23 <rosmaita> so kudos to whoever thought of that
14:55:48 <jokke_> rosmaita: and you're ok with it being import method rather than needing to mingle full dedicated entry point for it and all the filtering needed?
14:56:05 <rosmaita> well ...
14:56:15 <jokke_> cheers, yeah that was my lil brain getting that blink of light for a change :D
14:56:32 <jokke_> btw we have 4 min
14:56:57 <rosmaita> i'm ok with it, don't love it, but then i'm not doing the implementation
14:57:15 <rosmaita> and i think the api WG is out of business
14:57:59 <jokke_> rosmaita: I hear you and I did share your concern when we initially talked about this. It just makes life so much easier to treat it as import job than duplicate all the piping to have it's own thing
14:58:20 <rosmaita> yeah, i think keep it simple for now
14:58:39 <jokke_> and we can always mask it in the client if we wish
14:58:44 <rosmaita> all that stuff may need to be refactored to a separate service at some point, so we can deal with it in v3
14:59:06 <jokke_> yeah, I leave to who ever is designing v3 after I'm dead :P
14:59:20 <jokke_> #topic Open Discussion
14:59:26 <jokke_> ok, last minute
14:59:31 <jokke_> #link https://review.opendev.org/#/c/698018/
15:00:05 <jokke_> selfish plug, the delete image from a store spec, the code is ready for glance and client
15:00:17 <jokke_> and we're out of time.
15:00:17 <rosmaita> ok, will put it on my list
15:00:20 <jokke_> Thanks all!
15:00:36 <yebinama> bye
15:00:39 <jokke_> #endmeeting