14:00:02 <jokke_> #startmeeting glance
14:00:03 <openstack> Meeting started Thu Jan 24 14:00:02 2019 UTC and is due to finish in 60 minutes.  The chair is jokke_. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:06 <openstack> The meeting name has been set to 'glance'
14:00:09 <jokke_> #topic roll-call
14:00:11 <jokke_> o/
14:00:15 <smcginnis> o/
14:00:19 <rosmaita> o/
14:00:23 <GregWaines> o/
14:00:29 <jokke_> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:01:01 <abhishekk> o/
14:01:40 <jokke_> #topic updates
14:02:28 <jokke_> So first of all the feature/metadata-caching branch has been added
14:02:40 <abhishekk> cool
14:02:46 <jokke_> GregWaines: feel free to start poking that :)
14:03:22 <jokke_> thanks smcginnis for swift processing of the patch ;)
14:03:34 <GregWaines> Will do ... thanks
14:04:06 <jokke_> the second thing I want to bring up is removal of moxstubout
14:04:38 <jokke_> Huge hand to Chuck Short who did the effort to get rid of them in glance_store
14:04:47 <abhishekk> +1
14:05:44 <jokke_> the 3rd think I have in my mind is to bring up the swift store encoding issue
14:06:39 <abhishekk> I have spend some time around but not able to find the exact reason for this  :(
14:06:48 <jokke_> I've spent days going back and forth and I do not know why that error happens and why we are pushing any encoded material to swift driver in the first place (clearly as the encoding the data fixes the issue)
14:07:48 <jokke_> I'm still very very worried that we will not get same hashes out after the encoding and doing the encoding on the data might have some serious consequences
14:08:02 <abhishekk> can we catch up driver-maintainers with this?
14:08:09 <rosmaita> yeah, we need to have some kind of tests
14:08:38 <abhishekk> our functional tests are using file stores only
14:09:10 <jokke_> iiuc tempest is defaulting to swift as backend
14:09:21 <jokke_> so I'm very surprised we do not fail there
14:11:13 <jokke_> So my big question is why we do not see this on automated tests but anything RH based seems to break. is this something related to the dependencies provided from RHEL or is this something that will seriously bite us once the barge of shait hits the tornado
14:12:26 <jokke_> unfortunately I have still more questions and 0 answers
14:12:46 <jokke_> but moving on we can continue this in open if needed
14:12:52 <jokke_> #topic release updates
14:13:39 <abhishekk> so we are in release-11 week
14:14:05 <abhishekk> we should be mostly focusing on glance-store release once our swift related issue is addressed
14:14:29 <abhishekk> Regarding periodic jobs everything is ok at the moment
14:15:23 <jokke_> cool
14:15:43 <jokke_> do you remember out of your head when the non-client lib deadline is?
14:16:58 <abhishekk> no, I need to see
14:17:10 <jokke_> ok ... I think it's closing quickly
14:17:22 <abhishekk> Its Feb 25 week
14:17:30 <smcginnis> One week before stein-3 IIRC.
14:17:57 <jokke_> oh so we have still a month. Good, even we can do bugfixes after I would love to have this sorted before
14:18:49 <jokke_> Brian had his computer freezing so lets wait for a bit for him to get back
14:19:28 <abhishekk> yeah
14:19:39 <abhishekk> that's it from me, we can move ahead
14:19:44 <jokke_> Anyone had anything out of agenda?
14:19:55 <jokke_> the 3 remaining topics are all rosmaita's
14:20:02 <rosmaita> hello
14:20:10 <jokke_> oh there you are, wb
14:20:15 <abhishekk> welcome back
14:20:22 <jokke_> #topic 2018 agendas moved
14:20:37 <rosmaita> yeah, i need to apologize to lenovo, i think the problem is a memory leak in google chrome calendar
14:21:10 <rosmaita> just wanted to point out that i moved the agendas from last year to their own page
14:21:31 <rosmaita> we've been doing that for a while, when the etherpad gets too big it's unresponsive
14:21:31 <jokke_> the joy of crappy web pages taking us back to 90's enjoying memory leaks :D
14:21:42 <rosmaita> you are correct, sir!
14:21:58 <rosmaita> but it did occur to me that if these agendas are worth having around
14:22:10 <rosmaita> maybe we should put them somewhere that's supposed to persist?
14:22:23 <jokke_> rosmaita: thanks for keeping up with the archival maintenance
14:22:27 <rosmaita> np
14:22:36 <jokke_> well in a sense they are ... the topics are in the logs
14:22:45 <jokke_> parsing them is bit of pain 'though :P
14:23:07 <rosmaita> yeah, but it will be a big PITA to put this stuff into the wiki, i think the formatting gets all messed up
14:23:17 <jokke_> indeed
14:23:22 <rosmaita> as you can see on the 2018 etherpad now, all items are #1
14:23:26 <rosmaita> :)
14:23:32 <abhishekk> :D
14:23:33 <jokke_> so how about we just put links to those archival etherpads?
14:23:54 <rosmaita> we sort of have links at the top of the current agenda
14:24:10 <rosmaita> i could copy that paragraph about how to find old agendas to the meeting page on the wiki
14:24:15 <rosmaita> ok, i will do that
14:24:18 <rosmaita> problem solved!
14:24:25 <rosmaita> jokke_: ++
14:24:28 <jokke_> I guess that's good enough. at least there is reasonable way to find when topic X was discussed to get into the irc logs
14:24:55 <jokke_> sounds good, moving on
14:25:10 <jokke_> #topic glance release version
14:25:41 <rosmaita> yeah, this is a weird one
14:26:06 <rosmaita> we have this situation that nikhil warned against, where we need to do some manual maintenance to update the db migration constants
14:26:12 <rosmaita> it's easy to forget to do that
14:26:15 <jokke_> yup
14:26:22 <rosmaita> so i was trying to figure out a test
14:26:47 <rosmaita> it matches the release number of the current branch via pbr to the first letter of the constant
14:27:05 <rosmaita> which won't distinguish 'austin' from 'aardvark'
14:27:13 <rosmaita> but it's good enough for current purposes
14:27:32 <rosmaita> anyway, the problem is that the way we're incrementing the version in the branch is by minor rev number
14:27:41 <rosmaita> so master is currently 17.1.x
14:27:53 <rosmaita> and will go to 18 when we do a release
14:28:00 <jokke_> yep
14:28:06 <rosmaita> (i think -- smcginnis can tell us the details)
14:28:21 <rosmaita> anyway, we could trigger master to go to 18.0.0 whenever we want
14:28:21 <jokke_> and we never hit this issue after the first milestone when those were still released ;)
14:28:31 <rosmaita> yeah, so there's that, too
14:28:49 <rosmaita> or, i could change the tests to look for minor version
14:28:56 <rosmaita> but i think that would not be so reliable?
14:29:27 <rosmaita> if a stable branch went to x.1.x instead of x.0.1, the tests would break in that branch
14:29:38 <rosmaita> anyway, i don't know what to do
14:29:43 <jokke_> so I think the easiest solution is to defer migrations post milestone 1 and start tagging beta on that first milestone even if we ignore the rest
14:30:18 <jokke_> or did that feature trick from smcginnis actually solve the issue?
14:30:31 <rosmaita> no, at least not for the test i wrote
14:30:56 <rosmaita> so i believe that as long as the release version and constant name are in sync, the test i wrote will pass
14:30:58 <rosmaita> which is good
14:31:13 <rosmaita> if we cut a release without updating the constant, tests will fail
14:31:19 <rosmaita> well one test, at least
14:31:34 <rosmaita> although there may be a timing issue here
14:31:53 <abhishekk> ok, so I need to add it in a todo list somewhere
14:31:53 <jokke_> ok, lets tag 18 beta from master and add to our releaseliaison notes that we want to do that on the first milestone and we open the migrations in future after that
14:32:24 <rosmaita> ok i will abandon the test patch and someone can pick it up later if they are so inclined
14:32:58 <rosmaita> but we do need to update the constant for the default visibility change
14:33:00 <jokke_> rosmaita: so if you ad bit of logic into that test it will keep working
14:33:27 <jokke_> we just want to check that the constant is equal or smaller than current release number
14:34:10 <jokke_> oh wait, that kind of defeats the purpose of that test, right?
14:34:22 <rosmaita> yeah, that was my first thought
14:34:29 <rosmaita> was trying to think it through
14:34:38 <rosmaita> it would always pass, though ... that's nice
14:34:41 <rosmaita> :)
14:34:47 <jokke_> so we would need to have first commit after the beta tag being the constant bump which will then open the development for migrations
14:35:27 <abhishekk> who has access to edit releaseliason notes?
14:35:31 <jokke_> well it would not pass if someone tried to make migrations before we have the next release lined up, which is kind of counterintuitive
14:35:37 <rosmaita> yeah, i think the test would break as soon as the bump happened
14:35:49 <rosmaita> and then the constant change would open the gate again
14:35:55 <jokke_> yes
14:36:05 <rosmaita> we'd have to be right on top of it, or the integrated gate will be a mess!
14:36:06 <jokke_> which is kind of good as then we will not forget to bump it
14:36:19 <rosmaita> abhishekk: they're in the regular docs, so you just put up a patch
14:36:30 <rosmaita> you may be looking at an old version if you are looking on the wiki
14:36:38 <abhishekk> rosmaita, ack
14:37:05 <rosmaita> ok, so real quick
14:37:29 <rosmaita> forget it, forgot what i was going to say
14:37:40 <rosmaita> it's that kind of morning here
14:38:07 <jokke_> ok, so are we in agreement that we will open db migrations on milestone 1 and in future tag that so we keep our pbr up to date for them and we do merge rosmaita's test for it which forces us to do the constant change?
14:38:39 <rosmaita> i think it makes sense :)
14:38:51 <abhishekk> +1
14:39:11 <smcginnis> Sounds like that should work. (sorry, lot's of distractions here)
14:39:34 <jokke_> obviously if we need something earlier, say fixing cva, we can tag that beta before milestone 1 for it
14:39:34 <rosmaita> iirc, my test is currently failing because it depends on the constant change in a different patch
14:39:46 <rosmaita> i can rebase it and i think it should pass now
14:40:06 <rosmaita> then the question is just do we do a quick milestone release, or just do the api-break thing to bump the version
14:40:20 <rosmaita> so we can get the db stuff corrected for the default visibility change
14:40:49 <jokke_> I'll do beta release patch for us so we get that moving
14:40:56 <smcginnis> ++
14:40:57 <jokke_> tags are cheap
14:41:25 <rosmaita> ok, i will abandon the api-break patch
14:41:28 <rosmaita> and rebase the test
14:42:50 <jokke_> #action rosmaita or abhishekk adds note to release liaison docs to make sure we tag beta release at latest on milestone 1 and change the migration constant to open development for db migrations
14:43:10 <abhishekk> ack
14:43:27 <jokke_> #topic db migration bug
14:43:40 <jokke_> rosmaita: this was your's as well, what bug is that?
14:44:06 <rosmaita> #link https://bugs.launchpad.net/glance/+bug/1812856
14:44:06 <openstack> Launchpad bug 1812856 in Glance "DB migration code will break after 'z' release" [Medium,Triaged]
14:44:18 <rosmaita> when i was looking into the previous topic
14:44:32 <rosmaita> i noticed that our code sorts the migration scripts alphabetically
14:44:40 <rosmaita> which will stop working after the 'z' cycle
14:44:48 <jokke_> oh
14:44:51 <rosmaita> so we have some time to figure this out
14:45:02 <rosmaita> but i did want to make everyone aware!
14:45:15 <smcginnis> Maybe we will have a different mechanism for it in 3.5 years. :)
14:45:27 <jokke_> great so after Z release we need to have zzbottom- prefix in our migration constants :P
14:45:37 <abhishekk> :D
14:45:41 <smcginnis> :)
14:45:42 <rosmaita> yeah, like i said on the bug, when we designed this in ocata, we all thought we'd be gone by Z
14:45:52 <jokke_> lol
14:45:58 <jokke_> we still might
14:46:03 <rosmaita> :)
14:46:24 <jokke_> or we might not be using alembic but have moved to elastic on our db and never need to migrate anything anymore
14:46:31 <rosmaita> anyway, that's all from me
14:46:40 <rosmaita> i've done enough damage for one meeting
14:46:49 <jokke_> as we can just throw any garbage to the db
14:47:31 <jokke_> rosmaita: nono, this is good. and I think it's good to have the test breaking the gate intentionally and odcumentation why so we keep on track with these
14:48:10 <jokke_> the manual housekeeping is bitch and what ever we can do to remind us is good
14:48:43 <jokke_> just please make sure the test provides some reasonable fail line so we do remember why it broke in 5 months time :P
14:49:12 <jokke_> #topic open discussion
14:49:33 <jokke_> #action jokke to put up 18-beta release patch
14:49:34 <rosmaita> ok, will do, because the release number gets modded with 26, so after z the failure messages won't be clear at all
14:49:36 <jokke_> forgot this one
14:50:00 <jokke_> Anything else?
14:50:31 <rosmaita> quick question ... can i rebase that test patch onto current master from the gerrit interface?
14:51:08 <abhishekk> never tried, but you can
14:51:21 <GregWaines> Wanted to let you guys know that I sent out an email with some updates on the Glance Edge Caching ... take a look and let me know your thoughts.
14:51:31 <smcginnis> I think you can.
14:51:31 <rosmaita> ack
14:51:57 <jokke_> GregWaines: sure will do thanks
14:52:31 <jokke_> oh and btw, I submitted talk proposal for the summit around Image management edge scenarios
14:52:44 <abhishekk> great
14:52:54 <GregWaines> cool
14:53:28 <abhishekk> jokke_, rosmaita imacdonn has also asking about location related bug, I guess he has replied to ML as well
14:53:30 <jokke_> if it gets approved my idea is to run a bit of recap of the discussions I've had with various people over past 2 years or so and what is currently available and what we're working on to make the life in edge possible
14:53:59 <jokke_> abhishekk: ohh yeah, there was that
14:54:08 <jokke_> totally forgot it from the agenda
14:55:04 <jokke_> so I think we keep the multiple backends EXPERIMENTAL for Stein just to make sure we have covered all the needs to address the destination backend and start defaulting into it in Train
14:55:06 <abhishekk> last 5 minutes
14:55:14 <jokke_> anyone heavily opposing that?
14:55:35 <rosmaita> no opposition from me
14:55:42 <rosmaita> did you get any feedback at the summit?
14:55:58 <rosmaita> i mean, are operators dying to use the feature right now
14:56:05 <abhishekk> no problem for me
14:57:01 <jokke_> no, more similar concerns as imacdonn of quick transition needing to start using it
14:57:12 <rosmaita> btw, i just hit the rebase button in gerrit, checked the "change parent revision" box, and left the text box blank, and it rebased on master like normal
14:57:27 <abhishekk> cool
14:57:42 <abhishekk> so please reply to his mail as well
14:58:07 <abhishekk> I guess we need to document it as well
14:58:12 <jokke_> so if we have no problem making sure we have all bases covered I'll shoot email to the list stating that we're deferring it by a cycle and coordinate with cinder and nova that we do take care of any details needed from their side in Train
14:58:32 <abhishekk> +1
14:58:49 <jokke_> last minute
14:59:01 <jokke_> anything else?
14:59:13 <GregWaines> .... have a good week.
14:59:13 <abhishekk> thank you all
14:59:21 <jokke_> GregWaines: you too!
14:59:25 <jokke_> thanks all
14:59:33 <jokke_> #endmeeting