Thursday, 2018-10-04

*** diablo_rojo has quit IRC00:26
*** dave-mccowan has quit IRC00:52
*** slaweq has joined #openstack-meeting-401:11
*** slaweq has quit IRC01:15
*** iyamahat__ has joined #openstack-meeting-401:32
*** yamahata has quit IRC01:35
*** iyamahat_ has quit IRC01:35
*** iyamahat__ has quit IRC01:38
*** iyamahat has joined #openstack-meeting-401:39
*** iyamahat has quit IRC01:44
*** hongbin has joined #openstack-meeting-401:55
*** iyamahat has joined #openstack-meeting-402:00
*** yamamoto has quit IRC02:47
*** yamamoto has joined #openstack-meeting-402:47
*** hongbin has quit IRC03:27
*** yboaron has joined #openstack-meeting-404:23
*** yboaron has quit IRC04:27
*** slaweq has joined #openstack-meeting-405:11
*** slaweq has quit IRC05:16
*** eyalb has joined #openstack-meeting-405:39
*** eyalb has left #openstack-meeting-405:41
*** Luzi has joined #openstack-meeting-405:57
*** yboaron has joined #openstack-meeting-406:03
*** iyamahat has quit IRC06:35
*** pcaruana has joined #openstack-meeting-406:40
*** shachar has joined #openstack-meeting-406:54
*** shachar has quit IRC06:54
*** slaweq has joined #openstack-meeting-406:57
*** shachar has joined #openstack-meeting-407:15
*** shachar has quit IRC07:16
*** iyamahat has joined #openstack-meeting-407:53
*** snapiri has quit IRC07:54
*** pcaruana has quit IRC07:55
*** pcaruana has joined #openstack-meeting-407:57
*** snapiri has joined #openstack-meeting-408:01
*** yboaron_ has joined #openstack-meeting-408:22
*** gkadam has joined #openstack-meeting-408:30
*** gkadam has quit IRC08:31
*** ktibi has joined #openstack-meeting-408:36
*** e0ne has joined #openstack-meeting-408:42
*** iyamahat has quit IRC09:02
*** yamamoto has quit IRC09:22
*** yamamoto has joined #openstack-meeting-409:22
*** salmankhan has joined #openstack-meeting-409:24
*** ktibi has quit IRC09:57
*** slaweq_ has joined #openstack-meeting-410:38
*** slaweq has quit IRC10:40
*** yamamoto has quit IRC10:49
*** yamamoto has joined #openstack-meeting-410:49
*** yamamoto has quit IRC10:54
*** slaweq__ has joined #openstack-meeting-410:56
*** slaweq_ has quit IRC10:57
*** dave-mccowan has joined #openstack-meeting-411:02
*** pcaruana has quit IRC11:02
*** pcaruana has joined #openstack-meeting-411:02
*** janki has joined #openstack-meeting-411:06
*** yamamoto has joined #openstack-meeting-411:38
*** seajay has joined #openstack-meeting-412:16
*** celebdor has quit IRC12:24
*** celebdor has joined #openstack-meeting-412:30
*** yboaron has quit IRC12:33
*** yboaron_ has quit IRC12:34
*** yboaron_ has joined #openstack-meeting-412:34
*** yboaron has joined #openstack-meeting-412:34
*** bobh has joined #openstack-meeting-412:59
*** yboaron has quit IRC13:29
*** yboaron has joined #openstack-meeting-413:29
*** yboaron_ has quit IRC13:29
*** yboaron_ has joined #openstack-meeting-413:29
*** slaweq__ is now known as slaweq13:36
*** mjturek has joined #openstack-meeting-413:37
*** abhishekk has joined #openstack-meeting-413:39
*** rosmaita has joined #openstack-meeting-413:46
*** pcaruana has quit IRC13:50
*** oanson has quit IRC13:51
*** mhen has joined #openstack-meeting-413:55
*** smcginnis has joined #openstack-meeting-413:59
*** gkadam has joined #openstack-meeting-414:00
abhishekko/14:01
rosmaitaabhishekk: do you want to kick off the meeting?14:01
smcginnisHey abhishekk14:01
*** iyamahat has joined #openstack-meeting-414:02
*** jokke__ has joined #openstack-meeting-414:02
smcginnisInteresting the topic still says vitrage.14:02
jokke__#startmeeting glance14:02
openstackMeeting started Thu Oct  4 14:02:20 2018 UTC and is due to finish in 60 minutes.  The chair is jokke__. Information about MeetBot at http://wiki.debian.org/MeetBot.14:02
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:02
abhishekkI thought I was late14:02
*** openstack changes topic to " (Meeting topic: glance)"14:02
openstackThe meeting name has been set to 'glance'14:02
jokke__o/14:02
Luzio/14:02
*** njohnston has quit IRC14:02
*** jokke__ is now known as jokke_14:02
abhishekko/14:02
mheno/14:02
smcginniso/14:02
abhishekksmcginnis, rosmaita o/14:02
*** njohnston has joined #openstack-meeting-414:03
jokke_ok so I actually don't have any updates for us ... quiet start for the cycle14:04
jokke_#topic tip jobs14:04
jokke_ohhh14:05
*** jokke_ is now known as jokke__14:05
jokke__#topic tip jobs14:05
*** openstack changes topic to "tip jobs (Meeting topic: glance)"14:05
rosmaitaclient, store are all green14:05
rosmaitacursive is suddenly failing py35-functional on master14:05
rosmaitawhich is weird, i don't think that library is being actively maintained14:06
rosmaitathey are time outs14:06
rosmaitai will take a look later14:06
jokke__functional-py35 was failing yesterday on master due to timeout14:06
smcginnisThere was some dependency update issue with cursive over the weekend I thought, but I also thought it was cleared up.14:06
rosmaitaahh14:06
jokke__this morn passing again14:06
rosmaitai have not been reading the ML14:06
smcginnisBut that manifested itself as a stacking failure I thought.14:06
rosmaitaok, maybe it has fixed itself14:07
rosmaitaok, i'll look at today's run (happens in 8 hours or so) and see what's up14:07
rosmaitanext item14:07
rosmaitahow to configure the jobs14:08
rosmaitathere is a small controversy happening14:08
rosmaitaquick reminder of what we're talking about14:08
rosmaitaduring rocky, we configured periodic "tips" jobs so we will get advance notice if some project we depend on merges a change to their master that breaks glance tests14:08
rosmaitaproblem is, when we cut stable/rocky from master, the periodic tests also started running in stable/r, which is pointless14:09
rosmaitasolution was to modify .zuul.yaml so that the periodic jobs only run against master no matter what branch .zuul.yaml is in14:09
rosmaitabut, there is some pushback from infra team because now we have all this cruft in the stable branch that is nonoperational and possibly confusing to people looking at the file14:09
rosmaitaso, our options are:14:09
rosmaita1) do what we did with glance_store and just leave the cruft in the stable branch14:09
rosmaita2) have the release CPL remove the cruft manually at the time the stable branch is cut14:09
rosmaita3) andreas's suggestion: move the periodic jobs to project-config, where they will be defined to be only run against master and then won't show up in our local .zuul.yaml and won't confuse anyone14:09
*** hamzy has quit IRC14:10
rosmaitaeditorial comment from me: if we do 3), then any change to these jobs has to go through the infra team for approval (makes us less agile)14:10
rosmaitaanother editorial comment: the infra manual says that jobs like this (only run against master) should be defined in project-config, but, infra team members in IRC have indicated that they aren't interested in policing this, it's more of a suggestion14:10
rosmaitaanyway, the changes for glance and glanceclient have yet to be approved, so it would be good to have a decision about what we want to do here14:10
rosmaitaquestions?14:10
jokke__not only that but it was very strong request not having the jobs defined there and move them to the project repo14:10
rosmaitayes, their position on that seems a bit inconsistent14:11
jokke__which causes IMO even more confusion when people start trying to find where these jobs are coming from as they are not in .zuul.yaml14:11
*** JamesBenson has joined #openstack-meeting-414:11
rosmaitajokke__: ++14:11
rosmaitai agree entirely, it's always a PITA to figure out where the stuff is coming from14:12
jokke__Personally I think the cruft in the .zuul.yaml is not that big of a deal ... if one does not know a) what it is doing b) why it's there they likely should not touch it14:12
rosmaitaok, so first item is: (1) we will keep the periodic tips jobs in our local .zuul.yaml14:13
rosmaitai mean, we agree on that14:13
jokke__like all that was implemented exactly for the reason so we don't need to be manually playing with the .zuul.yaml on every release and risking breaking something14:13
rosmaitaright14:13
smcginnisWe can have a branch filter on the job in .zuul.yaml. Even though I think overall the use of that was trying to be avoided.14:14
rosmaitaok, so second point of agreement: (2) we will modify the .zuul.yaml for glance, glanceclient same way as glance_store is now14:14
rosmaitasmcginnis: i think we have the branch filter (at your suggestion) in glance_store14:15
smcginnis:)14:15
jokke__if there is too much confusion about it, maybe we should try to document it bit better inline what we are achieving with those definitions14:16
rosmaitathe problem is that since it makes the tests nonoperational in stable/r, andreas would prefer to see them removed14:16
jokke__so what was the reason we avoided the branch filter in the first place?14:16
rosmaitai didn't know about it14:16
jokke__ahh14:16
rosmaitabut the one we merged has hte branch filter14:16
rosmaitait makes the periodic job defs a bit verbose14:17
rosmaitatake a look at .zuul.yaml in glance_store14:17
jokke__well, I'm more than happy to review his contributions of cleaning them up from each stable branch when they are cut. If he has problem them being there and doing nothing ;)14:17
*** hongbin has joined #openstack-meeting-414:17
rosmaitaok, that's fine then14:18
rosmaitaso let's merge these:14:18
rosmaitahttps://review.openstack.org/59983714:18
rosmaitahttps://review.openstack.org/59984414:18
rosmaitaand then i will backport them to stable/r14:19
rosmaitaand hten someone else can clean up the cruft if they are sufficiently motivated14:19
rosmaitaand i will put up a patch to release CPL docs about it14:19
rosmaitasound good?14:19
jokke__so we do need to specify the branch for each job, we can't do that on group level?14:21
rosmaitayes, don't remember why, but that was the way to do it14:21
rosmaita(i consulted with top professionals)14:21
jokke__sure ... oh well14:22
jokke__it is what it is14:22
rosmaitait may be doable, someone else can try it out14:22
rosmaitabut the key thing is i want to stop running the periodic jobs against stable/r14:23
rosmaitakind of a daily waste of resources14:23
jokke__++14:23
jokke__ok moving on14:23
rosmaitaok, that's all from me ... please review & approve the reviews linked above!14:24
jokke__#topic json-patching and Glance MIME types14:24
*** openstack changes topic to "json-patching and Glance MIME types (Meeting topic: glance)"14:24
rosmaitai guess that's me too14:24
rosmaitai left comments on the spec14:24
rosmaitaproblem is that the current proposal is not consistent with json-patch14:24
rosmaitabecause it adds or replaces an object that isn't actually there in the representation14:25
rosmaita#link https://review.openstack.org/#/c/597648/14:26
rosmaitajokke__ is going to hate this, but the "proper" way to do this will be to directly patch /checksum, etc14:26
smcginnisI'm not sure I followed the recommendation for how to handle that with the schema and such.14:26
*** shachar has joined #openstack-meeting-414:27
jokke__I'd like to hear other opinions, but I'd rather define that new version than open the can of worms of trying to solve the opening of those attributes14:27
jokke__that will be absolutely nightmare to maintain and likely bring us couple of new security bugs before we get it right14:27
abhishekkagree14:28
rosmaitai'm not so sure about that14:28
rosmaitawe have readonly_properties or something internally, we keep them in there14:28
rosmaitawe would just change them on the schema to not have readOnly: true14:28
rosmaitaor14:28
rosmaitawe could leave them as readOnly in the schema14:29
rosmaitait's allowed by the json-patch standard14:29
*** snapiri has quit IRC14:29
rosmaitai discussed this with ian in glance channel yesterday, you can look at the log14:29
rosmaitahas some references to the standard14:29
rosmaitabut, if we want to change the image schema to allow validation_data as a location attribute14:30
rosmaitawe can look into that14:30
rosmaitai guess we just make it not a required property14:31
rosmaitathen when it never shows up in the response, that's fine14:31
rosmaitaand it will be rejected in most PATCH calls14:31
jokke__so can't change multiple objects at once with json-patch ... meaning that limiting the ability to set the checksums only when setting the location and all the side effects not doing that on single call will be nightmare to handle14:32
rosmaitajokke__: well, we have a validator on the request deserializer14:32
rosmaitai think ian has a patch or paste up that does that14:33
rosmaitawe can talk with him later14:33
jokke__like we would need to reject all upload and import calls once one sets the checksum14:33
jokke__which is ridiculously bad user experience14:33
abhishekkBut will it not be a patchy then?14:34
jokke__or we would need to rework how the image gets activated when the locations are set causing the same14:34
rosmaitayeah, it is starting to sound bad14:34
*** liuyulong has joined #openstack-meeting-414:34
rosmaitaok, i will take a crack at how we can add validation_data to the image schema so this will work in a standard json-patch way14:35
rosmaitai guess that's all from me about this14:37
rosmaitaalthough, schema change means api bump14:37
rosmaitawhich maybe means this needs to be a full spec, not spec-lite?14:37
jokke__like we already have defined our own MIME type for the patch calls, we're not accepting json-patch call even it is within our parameters ... I look forward for seeing if there is better way to do it, but we had legnthy discussion about this in PTG trying not to srew over our users and still making the it possible to have the checksums in images that currently can't have it14:38
rosmaitawell, right now we accept a strict subset of json-patch calls14:39
rosmaitaif we make the change as the spec is now, we will be accepting some stuff that is ruled out by json-patch14:39
rosmaitawhich is not helpful to users14:39
jokke__tru, it still doesn't change the fact that we follow the standard only partially ;)14:39
rosmaitawell, it's all about the containment relation ... we follow it partially but what we do follow is all allowed by the spec14:40
rosmaitathat will no longer be true if we accept this proposal as it is14:40
jokke__I guess my point is that the audience for this change is very small and the work needed to do it by json-patch spec limitations vs. bumping the mime version and extending json-patch for what we need to do (and documenting it) is quite a bit less overhead14:41
jokke__like said I'm more than happy to hear if there is clean better way to do this. We just couldn't figure one out14:42
jokke__so looking forward what you can come up with14:42
rosmaitaok, so to be clear, if we accept the spec as written now, we will have to introduce a new openstack-json-patch-v2.214:42
jokke__yes, I do see that14:43
rosmaitai think changing the image spec so that we can stick with v2.1 will be easier14:43
rosmaitaok, just want to be sure14:43
jokke__is it openstack-json-patch we call it?14:43
rosmaitaapplication/openstack-images-v2.1-json-patch14:43
jokke__ok, so it's not claiming to be openstack wide it had glance/image specific component on it14:44
rosmaitabasically, what we do is constrain json-patch to what we have implemented by requiring this MIME type14:44
rosmaitaoh yeah, this is just us14:44
rosmaitai don't know if anyone else uses PATCH14:45
jokke__yeah, I was worried it was something openstack wide we would have had to coordinate much more14:45
rosmaitaright14:45
rosmaitathe only coordination would be to discuss with the API SIG14:45
rosmaitawhich i sort of did by speaking with cdent yesterday (notes are on the review)14:45
*** hamzy has joined #openstack-meeting-414:45
jokke__so likely _if_ we do it this way we want to have couple of conditions and support v2.1 and v2.2 just to not break all the clients out there as it's clean extensions14:46
jokke__and just not allow them if them mime type is v2.114:46
rosmaitawe also still support v2.014:46
jokke__yeah14:46
jokke__*shrug*14:46
rosmaitabut yeah, we should check mime type14:46
rosmaitabut actually, if we change the image schema, we can keep v2.114:47
rosmaitawon't have to change the mime type14:47
rosmaitathe change will be ruled out by the older image schema that doesn't have 'validation_data' as a locations property14:48
rosmaitasorry that this has dragged on so long ... i will see what i can come up with on an etherpad and send a link to the ML14:49
jokke__well it's still affecting the other object (image) instead of the location14:49
jokke__sure, that would be gr814:49
jokke__lets hop the encryption before we run out of time14:49
jokke__#topic image encrypion clarifications14:49
*** openstack changes topic to "image encrypion clarifications (Meeting topic: glance)"14:49
Luzihi14:50
Luziwe had a mail on the ML and a discussion in cinder, as you suggested14:50
rosmaitaLuzi: quick question ... when you have one of these encrypted images on a disk, what's the result of doing 'file' on it?14:50
*** jchhatbar has joined #openstack-meeting-414:50
Luziit should be: gpg symmetrical encrypted data14:51
rosmaitacool, ty14:51
Luziwe have found some further questions, we would like to ask you14:51
Luziwhen handling encrypted images we need keys for encryption and decryption, which we retrieve from Barbican14:51
Luzidefault OpenStack behavior for encrypted resources is to automatically generate and delete keys on-demand14:52
Luziin our current proposal we rely on the user to create and delete keys in Barbican for the image encryption14:52
Luzido you think we should change our approach to completely automate this for images as well?14:52
LuziThis would mean the glance server needing to delete Barbican keys upon image deletion – which is actually an open TODO from Cinder already: https://github.com/openstack/cinder/blob/1060074dcb80dc10a4f3353e6bd7c39402f0c321/cinder/api/contrib/volume_actions.py#L22514:53
*** janki has quit IRC14:53
jokke__I personally really hate the idea of system doing something I did not ask it to do14:54
mhensame here ;)14:54
jokke__meaning that's kinf of like making nova deleting the image when user deletes the instance14:54
rosmaitaalso, if you want to import an image that is already encrypted (which i think is the use case), you can't have glance generate the key, can you?14:55
Luziin the cinder yase: no, the key is just copied14:55
jokke__oh users would love that amount of database overhead when every single time the same data is copied over and over again14:56
jokke__how about we don't do that? ;P14:56
Luziit is needed, because when you create an image from an encrypted volume it is automatically encrypted14:57
*** shachar is now known as snapiri14:57
Luziso cinder copies the key, to be able to decrypt the image even when the original volume is deleted14:57
mhenthe current cinder case is the only one where encrypted images already exist in openstack14:57
*** bobh has quit IRC14:58
jokke__and that's exactly the reason why cinder shouldn't be deleting the user's resource on a different service in the first place ;)14:58
*** JamesBenson has quit IRC14:58
*** e0ne has quit IRC14:58
Luzithat might take longer, so before the time is over, we have other questions too:14:59
jokke__I quess the one thing we should make sure is that the key id is retained when the image gets deleted so those kays can be tracked and cleaned out14:59
jokke__quick14:59
Luziwe are currently planning to outsource the encryption mechanism14:59
Luziimplementations into the openstacksdk, because it is used across several14:59
Luzicomponents14:59
Luziseems like the other teams have differing opinions on that in regards to where to outsource the code to – what’s yours?14:59
Luziwe can also discuss this further in the glance chat15:01
abhishekkwe are out of time15:01
jokke__I really don't have opinion on that ... neither cinder nor nova uses it to access glance 'though iiuc so it might be problematic to tap in15:01
Luziokay15:01
jokke__yeah ... lets continue this on #openstack-glance15:01
jokke__#endmeeting15:01
*** openstack changes topic to " (Meeting topic: vitrage)"15:01
openstackMeeting ended Thu Oct  4 15:01:41 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:01
openstackMinutes:        http://eavesdrop.openstack.org/meetings/glance/2018/glance.2018-10-04-14.02.html15:01
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/glance/2018/glance.2018-10-04-14.02.txt15:01
*** abhishekk has quit IRC15:01
openstackLog:            http://eavesdrop.openstack.org/meetings/glance/2018/glance.2018-10-04-14.02.log.html15:01
jokke__thanks all!15:01
*** bobh has joined #openstack-meeting-415:04
*** jokke__ is now known as jokke_15:05
*** iyamahat has quit IRC15:08
*** bobh has quit IRC15:10
*** e0ne has joined #openstack-meeting-415:13
*** JamesBenson has joined #openstack-meeting-415:23
*** Luzi has quit IRC15:25
*** macza has joined #openstack-meeting-415:25
*** bobh has joined #openstack-meeting-415:37
*** hamzy_ has joined #openstack-meeting-415:42
*** bobh has quit IRC15:44
*** hamzy has quit IRC15:44
*** jchhatbar has quit IRC15:46
*** e0ne has quit IRC15:47
*** liuyulong has quit IRC15:51
*** yboaron has quit IRC16:02
*** yboaron_ has quit IRC16:03
*** smcginnis has left #openstack-meeting-416:13
*** iyamahat has joined #openstack-meeting-416:14
*** dosaboy has quit IRC16:39
*** dosaboy has joined #openstack-meeting-416:45
*** iyamahat has quit IRC16:51
*** dosaboy has quit IRC16:55
*** diablo_rojo has joined #openstack-meeting-416:55
*** dosaboy has joined #openstack-meeting-417:01
*** salmankhan has quit IRC17:04
*** iyamahat has joined #openstack-meeting-417:04
*** yamahata has joined #openstack-meeting-417:04
*** gkadam has quit IRC17:08
*** pcaruana has joined #openstack-meeting-417:17
*** bobh has joined #openstack-meeting-417:45
*** yamamoto has quit IRC17:51
*** yamamoto has joined #openstack-meeting-417:52
*** yamamoto has quit IRC17:57
*** pcaruana has quit IRC18:01
*** iyamahat_ has joined #openstack-meeting-418:02
*** iyamahat has quit IRC18:05
*** macza has quit IRC18:25
*** macza has joined #openstack-meeting-418:26
*** yamamoto has joined #openstack-meeting-418:30
*** e0ne has joined #openstack-meeting-418:31
*** e0ne has quit IRC18:33
*** mjturek has quit IRC19:17
*** mjturek has joined #openstack-meeting-419:49
*** mjturek has quit IRC20:00
*** e0ne has joined #openstack-meeting-420:08
*** mjturek has joined #openstack-meeting-420:12
*** e0ne has quit IRC20:14
*** mjturek has quit IRC20:17
*** mjturek has joined #openstack-meeting-420:19
*** mjturek has quit IRC20:23
*** diablo_rojo has quit IRC20:24
*** diablo_rojo has joined #openstack-meeting-420:25
*** e0ne has joined #openstack-meeting-420:30
*** macza has quit IRC20:40
*** macza has joined #openstack-meeting-420:41
*** hamzy_ has quit IRC20:44
*** celebdor has quit IRC20:46
*** mjturek has joined #openstack-meeting-420:47
*** mjturek has quit IRC20:54
*** e0ne has quit IRC21:00
*** bobh has quit IRC21:58
*** JamesBenson has quit IRC22:03
*** seajay has quit IRC22:13
*** hongbin has quit IRC22:57
*** macza has quit IRC22:58
*** pbourke has quit IRC23:03
*** pbourke has joined #openstack-meeting-423:04
*** edleafe has quit IRC23:39

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!