*** kota_ has joined #openstack-meeting | 01:23 | |
*** carlotronics has quit IRC | 03:20 | |
*** carlotronics has joined #openstack-meeting | 03:24 | |
*** carloss has quit IRC | 03:40 | |
*** carlotronics has quit IRC | 03:56 | |
*** manub has joined #openstack-meeting | 04:21 | |
*** soniya29 has joined #openstack-meeting | 04:40 | |
*** abhishekk has joined #openstack-meeting | 04:52 | |
*** soniya29 has quit IRC | 05:04 | |
*** soniya29 has joined #openstack-meeting | 05:19 | |
*** soniya29 has quit IRC | 05:31 | |
*** soniya29 has joined #openstack-meeting | 05:32 | |
*** soniya29 has quit IRC | 05:43 | |
*** soniya29 has joined #openstack-meeting | 05:43 | |
*** ralonsoh has joined #openstack-meeting | 06:01 | |
*** slaweq has joined #openstack-meeting | 06:16 | |
*** slaweq has quit IRC | 06:57 | |
*** tosky has joined #openstack-meeting | 07:20 | |
*** rpittau|afk is now known as rpittau | 07:34 | |
*** yasufum has quit IRC | 08:10 | |
*** Luzi has joined #openstack-meeting | 08:52 | |
*** kota_ has quit IRC | 09:01 | |
*** kota_ has joined #openstack-meeting | 09:12 | |
*** jbadiapa_ has joined #openstack-meeting | 09:19 | |
*** kota_ has quit IRC | 09:20 | |
*** abhishekk has quit IRC | 09:24 | |
*** jbadiapa has quit IRC | 09:24 | |
*** soniya29 has quit IRC | 09:45 | |
*** osmanlic- has joined #openstack-meeting | 10:14 | |
*** osmanlicilegi has quit IRC | 10:17 | |
*** M0nk3Ee has quit IRC | 10:18 | |
*** M0nk3Ee has joined #openstack-meeting | 10:19 | |
*** rubasov_ has joined #openstack-meeting | 10:21 | |
*** bauzas has quit IRC | 10:23 | |
*** bauzas has joined #openstack-meeting | 10:23 | |
*** rubasov has quit IRC | 10:24 | |
*** armstrong has joined #openstack-meeting | 10:32 | |
*** soniya29 has joined #openstack-meeting | 10:34 | |
*** soniya has joined #openstack-meeting | 10:57 | |
*** soniya29 has quit IRC | 10:57 | |
*** soniya29 has joined #openstack-meeting | 11:15 | |
*** soniya has quit IRC | 11:20 | |
*** osmanlic- has quit IRC | 11:20 | |
*** osmanlicilegi has joined #openstack-meeting | 11:20 | |
*** carloss has joined #openstack-meeting | 11:23 | |
*** hemna has quit IRC | 11:29 | |
*** soniya29 has quit IRC | 11:43 | |
*** soniya29 has joined #openstack-meeting | 11:43 | |
*** hemna has joined #openstack-meeting | 11:46 | |
*** soniya29 has quit IRC | 11:51 | |
*** h_asahina has joined #openstack-meeting | 12:30 | |
*** Luzi has quit IRC | 12:32 | |
*** soniya29 has joined #openstack-meeting | 12:35 | |
*** masazumi_ota has quit IRC | 12:44 | |
*** armstrong has quit IRC | 12:52 | |
*** soniya has joined #openstack-meeting | 13:06 | |
*** soniya29 has quit IRC | 13:13 | |
*** manub has quit IRC | 13:13 | |
*** abhishekk has joined #openstack-meeting | 13:44 | |
*** Steap has joined #openstack-meeting | 13:47 | |
*** rosmaita has joined #openstack-meeting | 13:51 | |
*** armstrong has joined #openstack-meeting | 13:52 | |
*** jokke_ has joined #openstack-meeting | 13:59 | |
abhishekk | #startmeeting glance | 14:00 |
---|---|---|
opendevmeet | Meeting started Thu Jun 3 14:00:03 2021 UTC and is due to finish in 60 minutes. The chair is abhishekk. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:00 |
abhishekk | #topic roll call | 14:00 |
opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
jokke_ | o/ | 14:00 |
opendevmeet | The meeting name has been set to 'glance' | 14:00 |
abhishekk | #link https://etherpad.openstack.org/p/glance-team-meeting-agenda | 14:00 |
abhishekk | o/ | 14:00 |
dansmith | o/ | 14:00 |
abhishekk | lets wait couple of minutes for others to show | 14:00 |
rosmaita | o/ | 14:01 |
abhishekk | I think Steap will join us soon, till then we can start with the updates | 14:01 |
abhishekk | #topic release/periodic jobs update | 14:01 |
abhishekk | M2 is 6 week away | 14:01 |
abhishekk | we are going to target at least 2 main specs in this period | 14:02 |
abhishekk | which we will discuss in next topic | 14:02 |
*** rajivmucheli has joined #openstack-meeting | 14:02 | |
abhishekk | Periodic jobs all green for straight 4th week | 14:02 |
rosmaita | \o/ | 14:03 |
abhishekk | yes \o/ | 14:03 |
abhishekk | no timeouts at all | 14:03 |
jokke_ | nice | 14:03 |
abhishekk | cool, lets move to next topic | 14:04 |
Steap | o/ | 14:04 |
abhishekk | #topic Deadlines and review volunteers | 14:04 |
abhishekk | As decided/discussed in last week, we will be finalizing deadlines for 2 specs | 14:04 |
abhishekk | 1. Unified quota spec | 14:05 |
abhishekk | The spec is owned by dansmith | 14:05 |
abhishekk | Spec is approved in this week and implementation patches are up for review | 14:05 |
abhishekk | I am Expecting to be completed - M2 - 1 week i.e. 1 week before Milestone 2 | 14:06 |
abhishekk | Voluntary reviewers: abhishekk, Steap (as Steap agreed to help us on reviews) | 14:06 |
abhishekk | we need one additional voluntary core reviewer for this | 14:07 |
dansmith | can I volunteer rosmaita or does he have to do it? :) | 14:07 |
rosmaita | you can volunteer me | 14:07 |
abhishekk | Any one up for volunteer from rosmaita or jokke_ ?? | 14:07 |
dansmith | seems natural to have the spec +2ers be the code reviewers | 14:08 |
abhishekk | cool, then jokke_ will be standby reviewer | 14:08 |
abhishekk | yes | 14:08 |
abhishekk | In case one of the voluntary core is not available then standby core needs to step up | 14:09 |
abhishekk | dansmith, as a owner are you comfortable with deadline decided? | 14:09 |
dansmith | sure, the only thing that isn't up yet is docs | 14:09 |
dansmith | which I need to get going on now that we have settled all the design and behavior | 14:10 |
abhishekk | ack, so 1st one is final | 14:10 |
abhishekk | Lets move to 2nd one | 14:10 |
abhishekk | Cache API, Move cache operations under glance API | 14:10 |
abhishekk | Owner is jokke_ | 14:11 |
abhishekk | Spce is already approved by 2 cores, dansmith and jokke_ | 14:11 |
abhishekk | I need to come up with lite-spec for glanceclient changes | 14:11 |
abhishekk | Voluntary reviewers: | 14:11 |
abhishekk | I am considering dansmith and Me as a primary reviewers for this spec | 14:12 |
dansmith | sure | 14:12 |
abhishekk | great | 14:12 |
abhishekk | Steap, and rosmaita will be on standby for the same | 14:12 |
dansmith | can we go ahead and merge the spec? there's not much code up, so I assume merging the spec will allow that to proceed | 14:12 |
abhishekk | Steap, also has better knowledge of glance-cache so his inputs will also help us | 14:12 |
* Steap has got to sit down and read more patches | 14:13 | |
abhishekk | dansmith, yes, I will approve it after the meeting | 14:13 |
dansmith | cool | 14:13 |
abhishekk | Expected to be completed - M2 - 1 week | 14:13 |
abhishekk | jokke_, are you comfortable with the deadline? | 14:14 |
jokke_ | I'll likely need help figuring out how to test this, but the code itself is going to be pretty straight forward | 14:14 |
abhishekk | cool, we can work on testing part | 14:15 |
dansmith | it should be easy to test | 14:15 |
rosmaita | should probably add tempest tests for the new API and then they can be proposed as recommended items for interop | 14:15 |
dansmith | just looking at tempest/api/image/v2/test_images should be pretty instructive, but I can help with that | 14:15 |
dansmith | rosmaita: yep, noted in the spec :) | 14:16 |
abhishekk | ++ | 14:16 |
rosmaita | guess you can tell that i am behind on my reviewing | 14:16 |
abhishekk | :D | 14:16 |
jokke_ | rosmaita: that's IMO for next cycle as it's planned EXPERIMENTAL for this cycle | 14:16 |
abhishekk | No, rosmaita we are grateful for your efforts in glance | 14:16 |
abhishekk | SO, apart from these priorities specs we also need to keep reviewing other patches as well | 14:17 |
abhishekk | kindly don't forget that :D | 14:17 |
dansmith | so one related thing, | 14:18 |
dansmith | I think it would be nice if we're adding new APIs (the cache ones) to make them use a modern policy enforcement | 14:18 |
abhishekk | Also, each week we will discuss the progress of the work | 14:18 |
jokke_ | dansmith: I think we need to policy it both ways, no? | 14:19 |
dansmith | so I wonder if it's worth stacking a refactor of the cached_images enforce under the actual patch to add those new APIs? | 14:19 |
abhishekk | dansmith, If the new policy enforcement framework is up, running and approved until then there is no issue | 14:19 |
dansmith | abhishekk: well, right I'm just asking about trying to dovetail those two efforts | 14:20 |
dansmith | I'll have to go look at what cached_images does now I guess | 14:21 |
dansmith | I think it was just a single policy rule with no details such that you grant all or nothing to some role | 14:21 |
abhishekk | jokke_, what do you mean by both ways? | 14:21 |
dansmith | abhishekk: in your spec you called out the new rules, so I guess when we see the code for the api bit to use those rules we can go from there | 14:22 |
jokke_ | dansmith: if you end up playing around with it, just that you know. Currently the code is under api/v2/, but the API itself is exposed through the cahcemanagemnt middleware that works together with the cahing middleware. It's bit cumbersome, but that's how you can enable it for poking around | 14:22 |
jokke_ | abhishekk: I guess we need to have both checks, legacy glance policy and rbac checks for those endpoints | 14:23 |
dansmith | I don't know what that means | 14:24 |
abhishekk | jokke_, we don't need special arrangement for that, if rbac is disabled then it will enforce the policy in legacy format | 14:24 |
jokke_ | dansmith: so the two middlewares needs to be in your paste pipeline for that current cache management API to show up | 14:25 |
dansmith | I mean the policy thing | 14:26 |
abhishekk | I think there is some confusion here with rbac and legacy policy | 14:27 |
abhishekk | jokke_, do you mean we need to test the same with rbac as well as legacy policy enforcement? | 14:28 |
jokke_ | dansmith: so I think the new policy keys makes sense to be enforced at the API, then I just need to figure out how to work around so the old and new policies do not break eachother | 14:28 |
jokke_ | so likely easiest is to move the policy enforcement to the middleware where the API is exposed too to avoid either execution path going through both of them | 14:29 |
dansmith | I guess I need to look at this closer | 14:29 |
jokke_ | abhishekk: yeah, I think it would be very wrong of us to implement new API endpoints and not take the rbac work into account during the implementation | 14:30 |
abhishekk | jokke_, ack, but I think we don't need to follow onion layer for these APIs for some reasons | 14:31 |
dansmith | yeah, sounds like we agree on the goal at least | 14:31 |
abhishekk | I mean for the new cache APIs | 14:31 |
dansmith | this API seems like a good one to have all the policy enforced at the api layer, which might already be the case, but needs some rbac love | 14:31 |
dansmith | implementing it all in middleware seems wrong to me, but I need to look and see how that's all done I guess | 14:32 |
jokke_ | abhishekk: I thought it was agreed already ages ago that we avoid adding anythin we don't strictly need to the onion hell | 14:32 |
abhishekk | ok, I will keep the spec on hold till then | 14:32 |
abhishekk | I would like to explain this policy stuff with rbac in the spec | 14:33 |
jokke_ | dansmith: so the problem is the middleware is exposing the current api which is moving to the api/v2/mapper | 14:33 |
jokke_ | dansmith: we're planning to deprecate the cachemanagement middleware, so while it's deprecated it still needs to enforce it's current policies | 14:33 |
jokke_ | but as we agreed to put new clearly defined policy keys in place we need to avoid overlapping those two | 14:34 |
dansmith | did the old cachemanage hit APIs implemented in middleware? | 14:34 |
dansmith | I had assumed it twiddle the db directly | 14:35 |
jokke_ | dansmith: correct the cachemanagement middleware injected it's api endpoints | 14:35 |
jokke_ | that's why we are refactoring this to clean it up | 14:35 |
dansmith | right, but.. I didn't realize the manage tool hit those I guess | 14:35 |
dansmith | so the spec doesn't very clearly articulate that existing apis are going to be moving, and the one code patch that is up just adds new ones, | 14:36 |
dansmith | so I guess that's why I failed to grasp the moving aspect | 14:36 |
rosmaita | i missed that part as well | 14:36 |
dansmith | I'm still not sure what that has to do with what we do for policy though | 14:36 |
jokke_ | yeah, since few cycles ago, it had something to do about getting rid of registry and v1 api that changed it in a way that poking stuff directly got painful | 14:37 |
dansmith | jokke_: do you have more code for this sitting in the wings that you could push up to better show what all is going on? | 14:39 |
jokke_ | dansmith: they are sharing the functional code, and I'm pretty sure the old policies for it are enforced quite deep in that code. So to be able to introduce the policy keys and enforce the at API layer we need to make sure we don't get hit by the old policies down in the chain but also make sure they still get enformced in the middleware is in play | 14:39 |
abhishekk | https://review.opendev.org/c/openstack/glance/+/626097 | 14:39 |
abhishekk | this was the code to fix cache-manage when v1 was removed | 14:40 |
jokke_ | dansmith: no, I literally whipped that one patch for abhishekk to have an idea how we could consolidate the functionality under one /v2/cache endpoint | 14:40 |
*** rajivmucheli has quit IRC | 14:40 | |
dansmith | okay | 14:40 |
abhishekk | https://review.opendev.org/c/openstack/glance/+/626097/5/glance/api/v2/cached_images.py | 14:40 |
abhishekk | This is the existing policy manage_image_cache jokke_ is talking about | 14:41 |
dansmith | right | 14:41 |
*** soniya has quit IRC | 14:41 | |
abhishekk | so this is also injected at API side I guess | 14:41 |
dansmith | well, this _enforce method is what I was concerned about earlier: | 14:42 |
dansmith | self.policy.enforce(req.context, 'manage_image_cache', {}) | 14:42 |
dansmith | this is one policy element for the whole thing with no target, | 14:42 |
dansmith | which means you can delegate cache management to a role, but with no control beyond that | 14:42 |
abhishekk | ack | 14:42 |
jokke_ | dansmith: yup, that's why we discussed about splitting that policy to individual components. | 14:43 |
dansmith | for things like queue_image we should be passing the ImageTarget there so you can allow people to cache their own images, but not others (if that's what you want) | 14:43 |
dansmith | jokke_: it's more than that though | 14:43 |
dansmith | but that's an important part, of course | 14:43 |
abhishekk | So definitely spec need some additional information | 14:43 |
dansmith | for the rbac part that would be good, yeah, | 14:44 |
abhishekk | Can either of you comment on the spec, I will update it then | 14:44 |
dansmith | but abhishekk maybe you can put more detail in there too about the middleware->api spec? | 14:44 |
dansmith | er, s/spec?/part/ | 14:44 |
abhishekk | yes | 14:44 |
dansmith | cool | 14:44 |
jokke_ | dansmith: basically the assumption has been as it needs to be done node by node basis that all cache management has been done by admin or admin-like operator responsible for the cache management in the cloud (In reality very little by hand management happens anywhere I know of) | 14:44 |
dansmith | right, but the point of rbac is to allow for less-than-god-like admins to manage certain spheres of responsibility | 14:45 |
jokke_ | dansmith: which i why I said we need to take that into account for this work | 14:45 |
jokke_ | would be very wrong of us to make this new API endpoint and not implement it with rbac in mind from get go | 14:46 |
dansmith | I think we're agreeing...? | 14:46 |
abhishekk | Ok, I will update the spec with this | 14:46 |
abhishekk | we agreed :D | 14:47 |
abhishekk | Moving to next topic now | 14:47 |
abhishekk | #topic Metadef project scope implementation | 14:47 |
abhishekk | Should we start parallel with policy refactoring? | 14:47 |
abhishekk | Metadef has 5 to 6 APIs which are pending for project scope implementation | 14:48 |
jokke_ | dansmith: I think that's something at least I just assumed as impementation detail rather major design aspect ... Just expecting that all new API work we do needs to take rbac into consideration like we just assumed that policies needs to be taken into account before without necessarily specifically calling it out in a spec ;) | 14:48 |
abhishekk | and we need to complete project scope for glance in this cycle | 14:48 |
dansmith | abhishekk: are you talking about fixing some metadef CRUD APIs so they can be safe to allow project people to manage? | 14:48 |
dansmith | jokke_: okay, well, the spec is kinda for level-setting assumptions, so... :) | 14:49 |
abhishekk | yeah | 14:49 |
dansmith | abhishekk: I'm not sure that's worth the effort unless there's someone that is asking for it | 14:49 |
abhishekk | I have one associate who is willing to work on this metadef part | 14:49 |
dansmith | is someone asking for it? it sounded like 99% of people just leverage the inbuilt metadefs for things like horizon, and one entity spoke up (CERN) about updating them, but they were assuming admin-only anyway | 14:50 |
abhishekk | dansmith, nope no one is asking but its a target given to at least complete implementation of project scope for this cycle | 14:51 |
dansmith | okay, but if we just delcare that this is not a project-scope-able API then ... it doesn't matter right? | 14:52 |
jokke_ | My biggest concern with the whole rbac picture atm. is that when you turn that on we loose our 'admin' and we have lots of things that assumes admin overwrites and adminnes baked into our API. Like with just project scope implemented Glance will be very very broken service with rbac turned on | 14:52 |
dansmith | well, that's why it's a big effort (for all projects) and why they pay us the medium bucks to fix it right? :) | 14:53 |
jokke_ | and none of that translates to project admin | 14:54 |
abhishekk | 5 minutes, we can revisit this next week | 14:55 |
abhishekk | with more information | 14:55 |
abhishekk | #topic Open discussion | 14:55 |
abhishekk | is something missed? | 14:56 |
abhishekk | whay bot is not working ? | 14:56 |
abhishekk | so bots are not working since the begging | 14:57 |
rosmaita | looks like it crashed after #startmeeting | 14:57 |
dansmith | looks like it started the meeting, | 14:57 |
dansmith | but yeah | 14:57 |
dansmith | crashed setting topic maybe :) | 14:57 |
abhishekk | anything for open discussion? | 14:57 |
rosmaita | btw, i'll be away all next week, so will miss the meeting :) | 14:57 |
jokke_ | abhishekk: well it reported starting meeting ... might be that the oftc services are not exact compatible for topic setting or something | 14:57 |
jokke_ | fungi: ^^ | 14:57 |
abhishekk | I think so | 14:58 |
abhishekk | I think some1 should have noticed it earlier | 14:58 |
jokke_ | Monday is Bank Holiday here, so I'll be around 4 days next week | 14:58 |
fungi | yes, if you followed the announcements on the service-discuss ml, the meetbot can't currently alter channel topics | 14:58 |
fungi | we're rewriting the bot to interact with chanserv via privmsg to do it | 14:58 |
abhishekk | :D, thank you for the update | 14:58 |
abhishekk | jokke_, cool, have a nice weekend | 14:59 |
abhishekk | Ok, time is up | 15:00 |
abhishekk | thank you all | 15:00 |
jokke_ | thanks! | 15:00 |
abhishekk | #endmeeting | 15:00 |
opendevmeet | Meeting ended Thu Jun 3 15:00:19 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:00 |
opendevmeet | Minutes: http://eavesdrop.openstack.org/meetings/glance/2021/glance.2021-06-03-14.00.html | 15:00 |
opendevmeet | Minutes (text): http://eavesdrop.openstack.org/meetings/glance/2021/glance.2021-06-03-14.00.txt | 15:00 |
opendevmeet | Log: http://eavesdrop.openstack.org/meetings/glance/2021/glance.2021-06-03-14.00.log.html | 15:00 |
*** rosmaita has left #openstack-meeting | 15:00 | |
*** carlotronics has joined #openstack-meeting | 15:07 | |
*** abhishekk has quit IRC | 15:08 | |
*** abhishekk has joined #openstack-meeting | 15:08 | |
*** abhishekk has quit IRC | 15:08 | |
gagehugo | #startmeeting security | 15:11 |
opendevmeet | Meeting started Thu Jun 3 15:11:28 2021 UTC and is due to finish in 60 minutes. The chair is gagehugo. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:11 |
opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:11 |
opendevmeet | The meeting name has been set to 'security' | 15:11 |
gagehugo | o/ | 15:12 |
*** Steap_ has joined #openstack-meeting | 15:12 | |
fungi | ohai | 15:13 |
*** erlon has quit IRC | 15:13 | |
*** Steap has quit IRC | 15:14 | |
gagehugo | #link https://etherpad.opendev.org/p/security-agenda agenda | 15:14 |
gagehugo | apologies for the late start | 15:15 |
gagehugo | #topic Folding the openstack-security ML into openstack-discuss | 15:16 |
fungi | so... i go through the moderation queue for it daily and discard spam | 15:16 |
gagehugo | fungi: I guess we haven't really been using the openstack-security ML? | 15:16 |
fungi | but looking back at the archives there's not been a single post to it in over a year | 15:16 |
fungi | anyway what we've done with other lists is to send a message to it saying it's being closed down, then delete the configuration for it (leaving the archives intact for posterity), and we add mail address aliases to direct future messages to openstack-discuss | 15:19 |
gagehugo | I think that is fine | 15:19 |
fungi | i'm happy to take care of all that as long as we have consensus | 15:19 |
gagehugo | one ML to rule them all | 15:20 |
fungi | in that case i'll send a message to the openstack-security ml this week saying we're shutting it down | 15:20 |
fungi | and separately we'll want to use codesearch.o.o to find references to that ml and update them to point to the openstack-discuss ml (saying to use [security-sig] in the subject line) | 15:20 |
*** armstrong has quit IRC | 15:21 | |
gagehugo | ok | 15:23 |
gagehugo | #topic Need to update all the IRC references for security-sig | 15:24 |
gagehugo | This is likely just the same thing, using codesearch.o.o to find/replace any irc references to point to the new ones | 15:25 |
gagehugo | #topic open discussion | 15:26 |
gagehugo | fungi: any other updates? | 15:27 |
fungi | nope, none from me. i sent a batch of reminders to the discuss ml about outstanding public vulnerability reports | 15:32 |
fungi | there's been some movement on a few, so i'll try to keep doing that | 15:32 |
fungi | though others are also free to take a turn if they want | 15:33 |
*** Steap_ has left #openstack-meeting | 15:33 | |
fungi | eventually it would be great if the people taking bug triage shifts on the individual projects started to include status for outstanding public vulnerability reports in their own periodic bug status reports to raise visibility, but i'm not sure how to get them to do it. i've tried to suggest it and get the opinion i'm being ignored | 15:34 |
gagehugo | Lol | 15:37 |
gagehugo | Do all the projects have bug triage shifts? | 15:37 |
fungi | not all, but the ones who also tend to have a lot of vulnerability reports do | 15:40 |
fungi | the rotating "bug czars/tsars" or whatever fancy titles they like to give them to make it seem like it's not janitorial drudgery ;) | 15:41 |
gagehugo | hmm ok | 15:45 |
gagehugo | I need to hop on another call, thanks fungi as always | 15:45 |
gagehugo | #endmeeting | 15:45 |
opendevmeet | Meeting ended Thu Jun 3 15:45:54 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:45 |
opendevmeet | Minutes: http://eavesdrop.openstack.org/meetings/security/2021/security.2021-06-03-15.11.html | 15:45 |
*** armstrong has joined #openstack-meeting | 15:45 | |
opendevmeet | Minutes (text): http://eavesdrop.openstack.org/meetings/security/2021/security.2021-06-03-15.11.txt | 15:45 |
opendevmeet | Log: http://eavesdrop.openstack.org/meetings/security/2021/security.2021-06-03-15.11.log.html | 15:46 |
fungi | thanks gagehugo! | 15:46 |
*** armstrong has quit IRC | 15:55 | |
*** armstrong has joined #openstack-meeting | 16:04 | |
*** armstrong has quit IRC | 16:12 | |
*** rpittau is now known as rpittau|afk | 16:12 | |
*** armstrong has joined #openstack-meeting | 16:15 | |
*** ralonsoh has quit IRC | 16:24 | |
*** kota_ has joined #openstack-meeting | 17:11 | |
*** kota_ has quit IRC | 17:19 | |
*** ralonsoh has joined #openstack-meeting | 19:16 | |
*** armstrong has quit IRC | 20:22 | |
*** armstrong has joined #openstack-meeting | 20:22 | |
*** ralonsoh has quit IRC | 20:28 | |
*** armstrong_ has joined #openstack-meeting | 20:31 | |
*** armstrong_ has quit IRC | 20:37 | |
*** armstrong has quit IRC | 20:44 | |
*** kota_ has joined #openstack-meeting | 20:45 | |
*** armstrong has joined #openstack-meeting | 21:40 | |
*** armstrong has quit IRC | 21:43 | |
*** kota_ has quit IRC | 21:52 | |
*** armstrong has joined #openstack-meeting | 21:57 | |
*** eharney has quit IRC | 21:57 | |
*** armstrong has quit IRC | 21:57 | |
*** armstron1 has joined #openstack-meeting | 22:08 | |
*** armstron1 has quit IRC | 22:10 | |
*** yamamoto has quit IRC | 22:45 | |
*** tosky has quit IRC | 23:00 | |
*** masazumi_ota has joined #openstack-meeting | 23:29 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!