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