14:01:48 <rosmaita> #startmeeting glance
14:01:49 <openstack> Meeting started Thu Sep 21 14:01:48 2017 UTC and is due to finish in 60 minutes.  The chair is rosmaita. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:53 <openstack> The meeting name has been set to 'glance'
14:01:59 <smcginnis> o/
14:02:04 <jokke_> o/
14:02:15 <abhishekk> o/
14:02:22 <rosmaita> sorry, was looking at the latest comments on the glare patch
14:03:21 <rosmaita> hello everyone
14:03:32 <rosmaita> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:03:39 <rosmaita> as always, there's the agenda ^^
14:04:08 <rosmaita> not many items, so here we go
14:04:22 <rosmaita> #topic updates
14:04:33 <rosmaita> #topic updates - roadmap
14:04:55 <rosmaita> our tentative queens roadmap is listed in the "spotlight links" on the agenda etherpad
14:04:57 <mfedosin> o/
14:05:18 <jokke_> rosmaita: very handy
14:05:26 <rosmaita> #link https://etherpad.openstack.org/p/glance-queens-ptg-roadmap
14:05:37 <rosmaita> sorry, am having copy & paste problems
14:05:38 <rosmaita> hi mike
14:05:58 <rosmaita> i'll put up a patch to the specs repo after the spec freeze happens
14:06:09 <rosmaita> but i don't expect many changes to the roadmap
14:06:13 <rosmaita> probably no changes
14:06:17 <rosmaita> ok, next item
14:06:39 <rosmaita> #topic updates - spec-related freezes
14:06:51 <rosmaita> #link http://lists.openstack.org/pipermail/openstack-dev/2017-September/122365.html
14:07:02 <rosmaita> you may have seen that email, it outlines the freezes & why so soon
14:07:11 <rosmaita> anyway, spec proposal freeze is next week
14:07:19 <rosmaita> spec freeze the week after that
14:08:10 <jokke_> ok, quick sanity check. Any of the things we have on the roadmap needing new specs written?
14:08:34 <jokke_> I know that abhishekk has been writing one for the property injections
14:08:48 <rosmaita> #link https://review.openstack.org/#/q/project:openstack/glance-specs+status:open
14:08:58 <rosmaita> those are the open ones, abhishekk 's spec is in the list
14:09:05 <rosmaita> the pluggable flow spec is the major one
14:09:14 <abhishekk> I guess for converting image format?
14:09:29 <rosmaita> the rest are spec-lites
14:09:54 <rosmaita> i'll put those together in the airport this afternoon
14:10:04 <rosmaita> (there's a list on the roadmap)
14:10:26 <rosmaita> jokke_ : do we know enough about the pluggable flow architecture to write a spec now?
14:10:40 <jokke_> rosmaita: not sure/really
14:10:54 <rosmaita> let's say it's covered by the image import mitaka spec
14:11:02 <jokke_> rosmaita: that's one of the things that is on my list for checking from the IIR spec
14:11:08 <rosmaita> we can add one later for documentation purposes if we have to
14:11:18 <rosmaita> definite spec freeze exception for that
14:11:25 <jokke_> as IIRC it was mentioned there while not really detailed
14:11:37 <rosmaita> jokke_ that's my recollection too
14:12:13 <jokke_> so I was more thingking how many of our items actually is covered spec wise already (or we are assuming so) and to which ones we should write one
14:12:23 <rosmaita> so for that, we can either do a spec if the architecture is controversial or needs discussion, or otherwise just add docs immediately
14:13:06 <rosmaita> i think we're pretty much committed to some kind of taskflow thing
14:13:20 <jokke_> and I'd assume we won't be amending the IIR spec anymore but rather writing new ones, even if it means it will overrule some parts of the IIR?
14:14:00 <rosmaita> i don't know, will have to think about that
14:14:06 <jokke_> I'd at least prefer that approach. The IIR spec is quite something already
14:14:24 <rosmaita> problem is, we don't want competing specs lying around
14:14:42 <rosmaita> and we can't move the IIR to 'implemented' if the implementation is significantly different
14:14:54 <rosmaita> let's worry about that later
14:14:59 <jokke_> ;)
14:15:21 <rosmaita> #action worry about strategy for ammending/updating IIR spec later
14:15:25 <rosmaita> :)
14:15:45 <jokke_> ok, sorry for bloating the topic
14:15:52 <rosmaita> np
14:15:58 <jokke_> the deadline just got me scared
14:16:02 <smcginnis> Some times it's easier updating specs after you see how things actually turn out. ;)
14:16:10 <jokke_> smcginnis: indeed
14:16:11 <rosmaita> smcginnis exactly!
14:16:23 <rosmaita> smcginnis it's just ... have you *seen* the IIR spec?
14:16:28 <rosmaita> it's a monster
14:16:29 <jokke_> :P
14:16:34 <rosmaita> but i digress
14:16:39 <smcginnis> :)
14:16:45 <rosmaita> ok, next item
14:16:56 <jokke_> rosmaita: do I need spec to refactor the IIR spec? :P
14:17:19 <rosmaita> jokke_ the new "official" name for IIR is "interoperable image import"
14:17:25 <rosmaita> iii
14:17:44 <rosmaita> anyway, quick update on this week's stuff on the roadmap
14:17:53 <jokke_> I like more "Refactoring the Image Import Refactoring spec spec" :P
14:17:56 <smcginnis> More like "aye aye aye"?
14:18:28 <rosmaita> https://etherpad.openstack.org/p/glance-queens-ptg-roadmap
14:18:33 <rosmaita> let's take a quick look
14:18:42 <rosmaita> i think most of this stuff is me
14:18:59 <rosmaita> did someone file a bug to track the iii test additions?
14:19:16 <abhishekk> nope
14:19:41 <rosmaita> abhishekk i think i saw that you had a list of something somewhere?
14:19:45 <jokke_> abhishekk: made nice etherpad listing the currently needed tests 'though
14:19:50 <abhishekk> I will put a new PS for property injection specs by tomorrow eod
14:20:11 <abhishekk> #link https://etherpad.openstack.org/p/glance-image-import-tests
14:20:12 <rosmaita> abhishekk i will read and comment on current spec today, or do you want me to wait?
14:20:35 <abhishekk> you can add comment
14:20:41 <rosmaita> ok, will do
14:20:45 <jokke_> rosmaita: if you have time, please do ... specially sanity check my comments there
14:21:02 <rosmaita> will be in the airport for a while, will start with abhishekk 's spec
14:21:03 <jokke_> before abhishekk rewrites it totally and then you disagree on those changes after ;)
14:21:08 <rosmaita> :)
14:21:18 <abhishekk> :D
14:21:43 <rosmaita> ok, i think we should file a bug referencing abhishekk 's etherpad, so we can track the test additions? or do we just want to tell people to use a special topic?
14:22:03 <rosmaita> i can go either way, just whatever's easier for people adding tests
14:22:30 <rosmaita> looks like gb21 found someone who's new to glance, but wants to learn
14:22:51 <abhishekk> I guess topic will be sufficient
14:23:12 <rosmaita> works for me
14:23:24 <jokke_> rosmaita: I'm not huge fan of tracking work items as bugs when they are enchancements but I do see the point for that as well
14:24:04 <jokke_> actually topic could be better as they are just tests ... that way we don't dump them into releasenotes
14:24:19 <rosmaita> "Please use the topic: import-tests for your patches"
14:24:24 <jokke_> as that's not really anything user/operator facing
14:24:29 <rosmaita> jokke_ good point
14:24:45 <rosmaita> the topic should be sufficient
14:24:52 <rosmaita> thanks for putting that together, abhishekk
14:24:55 <jokke_> #agreed "Please use the topic: import-tests for your patches"
14:25:02 <abhishekk> noted
14:25:34 <jokke_> ^^ we should have it easily found from the meeting notes summary
14:25:50 <abhishekk> rosmaita: np, may be sometime next week I will start working on if no one works on it
14:26:01 <rosmaita> ok, i have not made progress on running taskflow with eventlet
14:26:07 <rosmaita> due to not working on it
14:26:14 <jokke_> :P
14:26:16 <rosmaita> i will continue with that soon as i have some time
14:26:41 <rosmaita> which will happen soon, i've been travelling for meetings this week, will be back home this weekend
14:26:45 <jokke_> rosmaita: it works perfectly fine with eventlet :P
14:27:01 <rosmaita> ok, good point
14:27:17 <rosmaita> the key issue is that we need *all* of glance working with devstack
14:27:40 <rosmaita> i need to follow up on the oslo.concurrency bug, too
14:27:48 <rosmaita> ok, enough updates
14:27:53 <rosmaita> #topic community goals
14:27:55 <jokke_> rosmaita: yup ... and the plan was to look if we get it working without eventlet which is causing the problem under uwsgi
14:28:25 <rosmaita> ok, first goal is to split out the tempest plugin into its own repo
14:28:30 <rosmaita> and ...
14:28:34 <rosmaita> we don't have a tempest plugin
14:28:41 <rosmaita> so mission accomplished!
14:28:42 <jokke_> \\o \o/ o// o/7
14:28:52 <rosmaita> #link http://git.openstack.org/cgit/openstack/governance/commit/?id=18e24651cf9d0f5000bad9b0104cacf4c8734ee6
14:28:56 <jokke_> do we still need to have repo for it?
14:29:10 <smcginnis> Nice, one goal done already. :D
14:29:19 <rosmaita> jokke_ no, don't think so
14:29:27 <smcginnis> jokke_: No, shouldn't need it unless there is a plan to add tests there.
14:29:44 <rosmaita> ok, for the second goal, i've got a spec-lite up, which is how we've traditionally tracked these things
14:29:57 <rosmaita> #link https://review.openstack.org/#/c/501869/
14:30:22 <rosmaita> needs +2s so that i can put up a patch to governance repo about our plans
14:31:12 <rosmaita> so, glance cores, please take a look
14:31:20 <abhishekk> yes
14:31:22 <jokke_> smcginnis: I might have been slightly sarcastic there ;)
14:31:29 <rosmaita> #topic "multihash"
14:31:34 <smcginnis> jokke_: Hah! ;)
14:31:58 <rosmaita> i've put "multihash" in quotes because the name is a bit misleading
14:32:02 <smcginnis> rosmaita: I need to update the goal tracking for the tempest split for relmgt. Would you like me to submit a patch for glance noting there is no work to do?
14:32:26 <rosmaita> smcginnis thanks, but someone already put it up, and it was merged
14:32:50 <smcginnis> rosmaita: Oh, great. I must be looking at a stale view.
14:32:55 <jokke_> rosmaita: I do I remember totally wrong, but I think we originally agreed to default to the sha-512 due to the performance benefit of it?
14:33:24 <rosmaita> yes, that's why i want to discuss this
14:33:45 <rosmaita> scott mcclaymont, you may have seen his name on reviews recently, has been looking into picking this up
14:34:01 <rosmaita> he can't be here today, but i spoke with him yesterday
14:34:27 <rosmaita> he has a few suggestions i want to run by everyone before he revises the spec and proposes it for queens
14:34:32 <jokke_> ok
14:34:34 <jokke_> shoot
14:35:05 <rosmaita> so, the situation is that we currently have 'checksum' which is md5 and no longer considered a secure checksum
14:35:16 <rosmaita> but we are keeping it for backward compat with old tools
14:35:38 <rosmaita> scott's research is that most tooling these days uses sha-256 as the checksum
14:35:49 <rosmaita> which is secure for now
14:36:14 <rosmaita> so, the "multihash" idea was to future proof glance by using a self-describing checksum field
14:36:37 <rosmaita> but the problem with that is ... actually a bunch of things
14:36:55 <rosmaita> one is that you have to read the self-describing format (which isn't a big deal)
14:37:14 <jokke_> so there is one problem/solution pair I'd like to flag right away
14:37:23 <rosmaita> but the other is that you won't have the hash you want to use available, unless that's the one the operator chose
14:37:28 <rosmaita> jokke_ hang on a sec
14:37:40 <jokke_> we do _need_ to add the algorithm support to the discoverability API we have in 2.6
14:38:25 <rosmaita> so scott's idea is: we use 'checksum' for current backward compat, add a sha-256 for current tools and backward compat when sha-256 becomes "collidable", and sha-512 for future proofing
14:38:41 <rosmaita> no question about what algo is used, because there's a specific field for each one
14:39:14 <rosmaita> there is a sha-3 family of algos, but bruce schneier says that it's not significantly better than sha-512
14:39:34 <rosmaita> so sha-512 should suffice for a while, like through U or so
14:39:40 <rosmaita> and then we can revisit
14:39:42 <rosmaita> one other thing
14:40:11 <jokke_> so with the "current tools" I can't point a single major crypto lib that wouldn't support sha-512 as of now
14:40:33 <rosmaita> scott pointed out that no operator is going to want to migrate hashes, like if we are storing sha-256 in a self-describing field, no one will want to update all images to sha-512
14:40:43 <rosmaita> jokke_ exactly
14:40:54 <rosmaita> there is good support for md5, sha-256 and sha-512
14:41:07 <rosmaita> gitfs uses sha-256
14:41:17 <rosmaita> and a bunch of other things do too
14:41:39 <rosmaita> so it would be convenient to have the sha-256 for an image
14:41:55 <jokke_> but the whole thing of the multihash was that we have the capability not to carry on with known vulnerable hash ... say sha-(put your bitlength here) is found to be broken in January
14:42:24 <rosmaita> jokke_ exactly, but i'm beginning to think that's not helpfuyl
14:42:32 <jokke_> like we have the current hash tied to md5 today
14:42:57 <rosmaita> i know, and a lot of tooling still uses our md5
14:43:06 <jokke_> rosmaita: it might sound like a great idea to hardcode it as sufficient today (just like it probably did 7 years ago to do with md5)
14:43:12 <rosmaita> and a lot of tooling will still use sha-256 even if broken
14:43:24 <rosmaita> jokke_ i agree with where you are going
14:43:29 <rosmaita> but think about the migration issue
14:43:51 <rosmaita> anyway, we can discuss this on scott's patch
14:43:52 <jokke_> that, but also the tooling _needs_ to be changed already to use anything else than md5 as we haven't provided anything else so far.
14:44:01 <jokke_> so why not do it right for once?
14:44:32 <rosmaita> yeah, but we can do it right, but how do we force the tooling to comply?
14:44:50 <rosmaita> and i am worried about the migration issue
14:45:03 <rosmaita> which i guess goes away if we make sha-512 the default now
14:45:32 <jokke_> rosmaita: we don't and it's very much not our problem. We provided needed for the tooling to do right thing and be forwards compatible with it. If the tooling developer decides to do something else, it's absolutely their right and responsibility
14:46:37 <rosmaita> ok, this will provide scott with some stuff to read through later
14:46:58 <rosmaita> so the final question will be, "multihash" or 2 fields?
14:47:15 <rosmaita> but we are running out of time
14:47:29 <rosmaita> can discuss that on the patch
14:47:31 <jokke_> rosmaita: so if we inform what algo is used and the hash for it, it's both directions compatible and if the operator sees it important enough to migrate their lets say sha-256 hashes because it got broken, they can either do that or believe that the hash was valid when the image was created and check it against the old hash we have in records
14:48:28 <jokke_> rosmaita: just having new images hashed with new algorithm does not need to mean that the old hashes cannot be still validated
14:48:29 <rosmaita> i think the problem there is multi-region clouds, where you want to find the same image
14:48:46 <rosmaita> you can search for the same hash, but only if it's secure
14:49:24 <jokke_> ok, lets continue that on the patch, there is too much ifs for the time we have ;)
14:49:43 <rosmaita> the problem is last time i looked, you can't get the checksum of a DLO/SLO in swift without downloading the entirew thing and checksumming locally
14:50:04 <rosmaita> jokke_ agreed!
14:50:12 <rosmaita> #topic  open discussion
14:50:37 <rosmaita> oh yeah, priorities for the coming week
14:50:47 <rosmaita> there are some bugs marked for queens-1 milestone
14:50:55 <rosmaita> so those would be good to look at
14:51:04 <rosmaita> those and incoming specs
14:51:09 <rosmaita> anything else?
14:51:25 <jokke_> did I promise to look into making those deprecation patches?
14:51:37 <jokke_> registry and glanceclient
14:51:44 <rosmaita> jokke_ do you have time?
14:51:51 <rosmaita> or you can do one, i can do the other
14:52:00 <jokke_> rosmaita: no, but I can make time for it :P
14:52:09 <jokke_> I think I might have promised such
14:52:12 <rosmaita> ok, you choose ... both or just one
14:52:28 <rosmaita> yeah, my memory was that you said you would, but i was too polite to bring it up :)
14:53:03 <jokke_> rosmaita: ok so how about we take look of them together I can lead with the registry and you lead with the client
14:53:18 <rosmaita> ok, that works
14:53:19 <jokke_> likely something we need to brainstorm common approach anyways
14:53:49 <rosmaita> let's talk about that on monday?
14:53:54 <jokke_> ++
14:53:58 <rosmaita> ok, cool
14:54:04 <rosmaita> anything else on anyone's mind?
14:54:10 <jokke_> I'll hopefully have majority of this apartment packed by that
14:54:19 <abhishekk> nothing
14:54:30 <rosmaita> jokke_ oh yeah, i forgot about your move
14:54:34 <jokke_> I might not be able to join next weeks meeting. I'll definitely try to
14:54:40 <rosmaita> hope nothing got lost/broken
14:54:55 <jokke_> Will happen next Wed by current plans
14:55:16 <jokke_> so hopefully I'm online most of Wed and Thu but can't guarantee
14:55:22 <rosmaita> ok, well, good luck
14:55:31 <rosmaita> hope it goes well
14:55:36 <jokke_> cheers
14:55:46 <abhishekk> all the best ;)
14:56:33 <jokke_> that's all from me
14:57:13 <rosmaita> mfedosin anything?
14:57:37 <mfedosin> currently no :)
14:57:42 <rosmaita> ok, cool
14:57:51 <mfedosin> put +1 on the patch if you can :)
14:58:31 <rosmaita> mfedosin yeah, i guess i will +1 without a comment
14:58:47 <rosmaita> i am thinking that any comments will only lead to more confusion
14:59:02 <mfedosin> thanks Brian :)
14:59:15 <jokke_> thanks all!
14:59:17 <rosmaita> np
14:59:23 <rosmaita> ok, thanks everyone
14:59:25 <smcginnis> o/
14:59:32 <abhishekk> thank you all
14:59:42 <rosmaita> #endmeeting glance