| *** yamamoto has joined #openstack-meeting-alt | 00:05 | |
| *** yamamoto has quit IRC | 00:10 | |
| *** admcleod has joined #openstack-meeting-alt | 00:13 | |
| *** jamesmcarthur has joined #openstack-meeting-alt | 00:35 | |
| *** gyee has quit IRC | 00:44 | |
| *** jamesmcarthur has quit IRC | 00:51 | |
| *** jamesmcarthur has joined #openstack-meeting-alt | 00:52 | |
| *** jamesmcarthur has quit IRC | 00:57 | |
| *** jamesmcarthur has joined #openstack-meeting-alt | 01:22 | |
| *** jamesmcarthur has quit IRC | 01:23 | |
| *** jamesmcarthur has joined #openstack-meeting-alt | 01:23 | |
| *** masahito has joined #openstack-meeting-alt | 01:54 | |
| *** masahito has quit IRC | 01:55 | |
| *** masahito has joined #openstack-meeting-alt | 01:55 | |
| *** jamesmcarthur has quit IRC | 01:55 | |
| *** masahito has quit IRC | 01:56 | |
| *** yamamoto has joined #openstack-meeting-alt | 01:56 | |
| *** jamesmcarthur has joined #openstack-meeting-alt | 02:00 | |
| *** masahito has joined #openstack-meeting-alt | 02:02 | |
| *** jamesmcarthur has quit IRC | 02:31 | |
| *** ijw has quit IRC | 02:37 | |
| *** jamesmcarthur has joined #openstack-meeting-alt | 02:43 | |
| *** jamesmcarthur has quit IRC | 02:49 | |
| *** yamamoto has quit IRC | 02:49 | |
| *** jamesmcarthur has joined #openstack-meeting-alt | 02:53 | |
| *** diablo_rojo has quit IRC | 02:57 | |
| *** jamesmcarthur has quit IRC | 03:07 | |
| *** jamesmcarthur has joined #openstack-meeting-alt | 03:31 | |
| *** yamamoto has joined #openstack-meeting-alt | 03:55 | |
| *** jamesmcarthur has quit IRC | 03:58 | |
| *** yamamoto has quit IRC | 04:00 | |
| *** yamamoto has joined #openstack-meeting-alt | 04:13 | |
| *** masahito has quit IRC | 04:59 | |
| *** vishakha has joined #openstack-meeting-alt | 05:21 | |
| *** masahito has joined #openstack-meeting-alt | 05:22 | |
| *** rcernin has quit IRC | 05:33 | |
| *** rcernin has joined #openstack-meeting-alt | 05:33 | |
| *** links has joined #openstack-meeting-alt | 05:53 | |
| *** kozhukalov has joined #openstack-meeting-alt | 06:07 | |
| *** rcernin has quit IRC | 06:24 | |
| *** lbragstad has quit IRC | 06:26 | |
| *** haixin has joined #openstack-meeting-alt | 06:27 | |
| *** ccamacho has quit IRC | 06:49 | |
| *** e0ne has joined #openstack-meeting-alt | 07:16 | |
| *** e0ne has quit IRC | 07:23 | |
| *** e0ne has joined #openstack-meeting-alt | 07:24 | |
| *** e0ne has quit IRC | 07:29 | |
| *** e0ne has joined #openstack-meeting-alt | 07:48 | |
| *** e0ne has quit IRC | 07:52 | |
| *** tesseract has joined #openstack-meeting-alt | 07:53 | |
| *** slaweq has joined #openstack-meeting-alt | 07:53 | |
| *** e0ne has joined #openstack-meeting-alt | 08:06 | |
| *** e0ne has quit IRC | 08:08 | |
| *** ccamacho has joined #openstack-meeting-alt | 08:18 | |
| *** masahito has quit IRC | 08:28 | |
| *** apetrich has joined #openstack-meeting-alt | 09:21 | |
| *** yamamoto has quit IRC | 09:35 | |
| *** masahito has joined #openstack-meeting-alt | 09:41 | |
| *** masahito has quit IRC | 09:56 | |
| *** haixin has quit IRC | 09:56 | |
| *** kozhukalov has quit IRC | 11:17 | |
| *** kozhukalov has joined #openstack-meeting-alt | 11:21 | |
| *** kozhukalov has quit IRC | 11:35 | |
| *** kozhukalov has joined #openstack-meeting-alt | 11:35 | |
| *** yamamoto has joined #openstack-meeting-alt | 11:42 | |
| *** kozhukalov has quit IRC | 11:43 | |
| *** yamamoto has quit IRC | 11:46 | |
| *** yamamoto has joined #openstack-meeting-alt | 12:25 | |
| *** jamesmcarthur has joined #openstack-meeting-alt | 12:36 | |
| *** kozhukalov has joined #openstack-meeting-alt | 12:39 | |
| *** jamesmcarthur has quit IRC | 13:00 | |
| *** jamesmcarthur has joined #openstack-meeting-alt | 13:00 | |
| *** jamesmcarthur has quit IRC | 13:06 | |
| *** jamesmcarthur has joined #openstack-meeting-alt | 13:10 | |
| *** rfolco has joined #openstack-meeting-alt | 13:28 | |
| *** rfolco has quit IRC | 13:29 | |
| *** jamesmcarthur has quit IRC | 13:32 | |
| *** jamesmcarthur has joined #openstack-meeting-alt | 13:32 | |
| *** yamamoto has quit IRC | 13:35 | |
| *** e0ne has joined #openstack-meeting-alt | 13:35 | |
| *** lpetrut has joined #openstack-meeting-alt | 13:36 | |
| *** e0ne has quit IRC | 13:46 | |
| *** jamesmcarthur has quit IRC | 13:47 | |
| *** jamesmcarthur_ has joined #openstack-meeting-alt | 13:47 | |
| *** yamamoto has joined #openstack-meeting-alt | 13:54 | |
| *** e0ne has joined #openstack-meeting-alt | 13:57 | |
| *** maaritamm has joined #openstack-meeting-alt | 13:57 | |
| *** lbragstad has joined #openstack-meeting-alt | 13:59 | |
| *** vhari has joined #openstack-meeting-alt | 14:00 | |
| *** e0ne_ has joined #openstack-meeting-alt | 14:08 | |
| *** e0ne has quit IRC | 14:08 | |
| *** yamamoto has quit IRC | 14:18 | |
| *** jamesmcarthur_ has quit IRC | 14:35 | |
| *** jamesmcarthur has joined #openstack-meeting-alt | 14:40 | |
| *** jamesmcarthur has quit IRC | 14:48 | |
| *** danielarthurt has joined #openstack-meeting-alt | 14:58 | |
| *** andrebeltrami has joined #openstack-meeting-alt | 14:58 | |
| gouthamr | #startmeeting manila | 15:01 |
|---|---|---|
| openstack | Meeting started Thu Feb 27 15:01:44 2020 UTC and is due to finish in 60 minutes. The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:01 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:01 |
| *** openstack changes topic to " (Meeting topic: manila)" | 15:01 | |
| openstack | The meeting name has been set to 'manila' | 15:01 |
| carloss | o/ | 15:01 |
| dviroel | hi | 15:01 |
| lseki | o/ | 15:01 |
| andrebeltrami | hi | 15:01 |
| tbarron | Hello | 15:01 |
| vhari | hey | 15:01 |
| danielarthurt | Hi | 15:02 |
| gouthamr | hello o/ | 15:02 |
| maaritamm | o/ | 15:02 |
| gouthamr | Agenda: https://wiki.openstack.org/wiki/Manila/Meetings | 15:02 |
| gouthamr | courtesy ping: xyang toabctl ganso vkmc amito | 15:03 |
| gouthamr | let's begin with | 15:03 |
| gouthamr | #topic Announcements | 15:03 |
| *** openstack changes topic to "Announcements (Meeting topic: manila)" | 15:03 | |
| gouthamr | #link https://releases.openstack.org/ussuri/schedule.html | 15:03 |
| gouthamr | We're two weeks away from manila's Feature Proposal Freeze | 15:04 |
| *** e0ne_ has quit IRC | 15:04 | |
| amito | hey | 15:04 |
| gouthamr | we're expecting new features to be substantially complete: i.e, unit, functional and integration tests passing by this deadline | 15:04 |
| gouthamr | Feature freeze itself isn't for a month after that - but it gives us enough time for review, rebases and other code churn | 15:05 |
| gouthamr | please let me know if you anticipate any problems with respect to that.. | 15:06 |
| gouthamr | no other announcements for the week | 15:06 |
| gouthamr | does anyone else have any? | 15:06 |
| gouthamr | #topic Goals for Victoria | 15:07 |
| *** openstack changes topic to "Goals for Victoria (Meeting topic: manila)" | 15:07 | |
| gouthamr | the goal search email went out to the ML | 15:07 |
| gouthamr | if you're interested in taking a look: | 15:08 |
| gouthamr | #link http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012396.html | 15:08 |
| gouthamr | #link https://etherpad.openstack.org/p/YVR-v-series-goals | 15:08 |
| gouthamr | we knew of the zuulv3 goal for a while now, but, we should anticipate another to be picked up by the community | 15:09 |
| gouthamr | if you're interested in proposing one, please do | 15:09 |
| gouthamr | We're looking ahead to Victoria, and a gentle reminder that we published our planning etherpad for the PTG here: | 15:10 |
| gouthamr | #link https://etherpad.openstack.org/p/vancouver-ptg-manila-planning (Victoria PTG Planning Etherpad) | 15:11 |
| gouthamr | so we'll dive into whatever goals evolve in more detail during the PTG | 15:11 |
| gouthamr | next up | 15:12 |
| gouthamr | #topic Tracking our work | 15:12 |
| *** openstack changes topic to "Tracking our work (Meeting topic: manila)" | 15:12 | |
| gouthamr | in terms of reviews needing attention | 15:12 |
| gouthamr | #link https://review.opendev.org/#/q/owner:tamm.maari%2540gmail.com+status:open | 15:13 |
| gouthamr | this is maaritamm's work with manilaclient/OSC ^ | 15:13 |
| gouthamr | if we don't find substantial issues, we should aim to get these patches merged by feature proposal freeze | 15:14 |
| gouthamr | maaritamm's internship is almost coming to an end :( | 15:14 |
| carloss | :/ | 15:14 |
| maaritamm | :( | 15:14 |
| lseki | :( | 15:14 |
| gouthamr | feels like yesterday that she started - i think she's done an incredible job ramping up and learning all the nuances of manilaclient | 15:15 |
| gouthamr | and of OSC | 15:15 |
| carloss | gouthamr ++ | 15:15 |
| dviroel | for sure | 15:15 |
| maaritamm | I will stick around as much as I can though still :) | 15:15 |
| gouthamr | that's commendable, thank you maaritamm :) | 15:17 |
| gouthamr | please give these patches all the review attention you can.. | 15:17 |
| gouthamr | any other reviews that need our attention? | 15:18 |
| dviroel | what about the last rocky backport? | 15:18 |
| gouthamr | dviroel: good point, i'm a little bothered by one issue wrt rocky | 15:19 |
| gouthamr | i'd like some closure for it this week - if any patches need to land there, please alert me | 15:19 |
| gouthamr | i think i didn't find any that needed to be in the release | 15:20 |
| *** gyee has joined #openstack-meeting-alt | 15:21 | |
| gouthamr | but, beyond sounding cryptic - we may have a significant bugfix coming that might be appropriate before we make that final release | 15:21 |
| gouthamr | if we can't have that bugfix by the end of the week, i'll +1 this: | 15:21 |
| gouthamr | #link https://review.opendev.org/#/c/709896/ (Rocky final release proposal) | 15:21 |
| gouthamr | does that sound sane? | 15:22 |
| dviroel | yes | 15:22 |
| gouthamr | on the review, i made it sound like we're going to discuss the issue in this meeting ^ | 15:23 |
| gouthamr | i'll keep you informed via #openstack-manila | 15:24 |
| dviroel | gouthamr: let us know if you need anything | 15:24 |
| *** e0ne has joined #openstack-meeting-alt | 15:24 | |
| gouthamr | thanks dviroel | 15:25 |
| gouthamr | cool, anything else? | 15:25 |
| gouthamr | #topic Bugs (vhari) | 15:26 |
| *** openstack changes topic to "Bugs (vhari) (Meeting topic: manila)" | 15:26 | |
| gouthamr | let's hear from vhari! | 15:26 |
| gouthamr | #link: https://etherpad.openstack.org/p/manila-bug-triage-pad-new (Bug Triage etherpad) | 15:26 |
| vhari | o/ | 15:26 |
| vhari | lets take a look at 1st bug https://bugs.launchpad.net/manila/+bug/1858328 | 15:27 |
| openstack | Launchpad bug 1858328 in Manila "Manila share does not get into "shrinking_possible_data_loss_error" status when shrinking a share" [Low,Confirmed] - Assigned to Douglas Viroel (dviroel) | 15:27 |
| tbarron | dviroel: When I looked at this one, I wondered if the NetApp driver didn't return the expected "possible data loss" error because | 15:27 |
| tbarron | it was of the opinion | 15:27 |
| tbarron | that it had caught the shrink attempt in time | 15:27 |
| tbarron | and there is no possible data loss | 15:27 |
| tbarron | Of course we don't have an error state in manila that really accomodates that .... | 15:28 |
| dviroel | tbarron: yes, at the is aborted. | 15:29 |
| dviroel | s/at the/at the end | 15:29 |
| tbarron | if so, then I think we have the question whether NetAop should adapt to manila manager expectations | 15:30 |
| tbarron | and the user will be told there is possible data loss even though | 15:30 |
| tbarron | there isn't really | 15:30 |
| tbarron | or whether we should adapt the manila manager framework | 15:30 |
| tbarron | which only allows AVAILABLE, ERORmumbleSHRINKING_POSSIBLE_DATA_LOSS | 15:31 |
| gouthamr | there's a comment in the code base that seems appropriate: | 15:31 |
| gouthamr | #link https://opendev.org/openstack/manila/src/commit/188705d58b7022b30955bfa49d7b62ba93b7e9ef/manila/share/manager.py#L3904-L3908 | 15:31 |
| gouthamr | feels like dejavu | 15:32 |
| gouthamr | it is strange we'd raise an "error" if the share is perfectly alright | 15:32 |
| tbarron | gouthamr: +1 | 15:32 |
| gouthamr | but, we'd have to possibly look if drivers don't validate, but detect data loss? (is such a thing possible?) | 15:32 |
| tbarron | lkuchlan is suggesting we set it to AVAILABLE but generate an ERROR user msg | 15:33 |
| tbarron | but I kinda think maybe we should have an additional error state | 15:33 |
| gouthamr | ack, that seems to be u_glide's thought as well, when implementing this state | 15:33 |
| tbarron | and trust the drivers to signal the right thing | 15:33 |
| tbarron | for each driver, if it decides to indicate the safe error, we | 15:34 |
| tbarron | validate that change in code review | 15:34 |
| tbarron | this would require a corresponding tempest test case change to allow the new error state | 15:35 |
| tbarron | maybe several tempest tests and unit tests | 15:35 |
| gouthamr | a quick code search confirms that assumption ^ | 15:36 |
| tbarron | I haven't checked, perhaps only NetApp is doing a safe check on shrinks | 15:36 |
| gouthamr | apart from the Dell/EMC Unity driver, all drivers check for instances where consumed space is greater than the requested space | 15:37 |
| gouthamr | and return the error | 15:37 |
| tbarron | k | 15:37 |
| gouthamr | the Unity storage driver seems to perform this validation on their storage system | 15:37 |
| gouthamr | #link https://opendev.org/openstack/manila/src/commit/73b0bccd9f0e3238a153cb9ee461bbaefd6aa6d4/manila/share/drivers/dell_emc/plugins/unity/client.py#L309-L318 (Dell/EMC Unity share shrinking possible data loss) | 15:38 |
| gouthamr | either case, it's a validation and data loss has been prevented | 15:38 |
| *** jamesmcarthur has joined #openstack-meeting-alt | 15:38 | |
| tbarron | yup | 15:38 |
| dviroel | yes, same thing. | 15:38 |
| gouthamr | so this bug is tech debt that we haven't gotten to? | 15:39 |
| gouthamr | would it make sense to address it uniformly as such, rather than change the NetApp driver? | 15:39 |
| tbarron | seems like it. How does the tempest test pass in 3rd party CI? | 15:39 |
| dviroel | ^ good question, need to take a look | 15:40 |
| gouthamr | lkuchlan's issue seems to be with a scenario test | 15:40 |
| gouthamr | we don't test for this status in an API test | 15:40 |
| tbarron | gouthamr: I'm for a uniform solution but that doesn't require that all drivers change at once. | 15:40 |
| tbarron | change the manager to support setting the new state (and the tests) | 15:40 |
| tbarron | then drivers can do it one by one | 15:40 |
| gouthamr | tbarron: new state? | 15:41 |
| tbarron | as motivated to not alarm their users unnecessarily | 15:41 |
| tbarron | gouthamr: I don't see any other way, do you? | 15:41 |
| tbarron | new exception and new state | 15:41 |
| gouthamr | it's a bigger fix, but here's what i'm thinking: | 15:41 |
| tbarron | raise SHRINK_REFUSED | 15:42 |
| gouthamr | 1) Fix the share manager to raise a user message on this validation error, and set the share status to "available" | 15:42 |
| gouthamr | 2) Fix the NetApp driver to return the exception expected by the share manager for this validation so it conforms with the other drivers | 15:42 |
| tbarron | mgr sets STATUS_SHINKKING_ERROR | 15:42 |
| gouthamr | 3) Fix our scenario test to expect the share to transition to "available" and for the share size to remain the same | 15:43 |
| dviroel | +1 | 15:43 |
| tbarron | does this leave us with possible data loss with some back ends but the share is available? | 15:44 |
| gouthamr | tbarron: that'd be the first thing to check | 15:44 |
| tbarron | well we no a priori that it could, so this solution seems to do the wrong thing from a logical standpoint | 15:44 |
| gouthamr | tbarron: i looked through the drivers now, none of them are forcing a shrink, possibly because we call out the need for this validation | 15:44 |
| tbarron | even it might work empirically, with all our drivers | 15:45 |
| gouthamr | in the driver developer guide (or the interface doc) | 15:45 |
| tbarron | we're keeping a possible data loss state and | 15:45 |
| tbarron | having to make sure every driver really prevents it | 15:45 |
| gouthamr | #link https://docs.openstack.org/manila/queens/contributor/driver_requirements.html#share-shrinking (driver expectations) | 15:45 |
| tbarron | tomorrow we get a driver where there might be possible data loss, and we keep a state for that, but never use it? | 15:46 |
| tbarron | it seems to me a kludge and a bad design | 15:46 |
| gouthamr | #link https://opendev.org/openstack/manila/src/commit/14d3e268a05265db53b5cfd19d9a85a3ba73a271/manila/share/driver.py#L1163-L1165 (driver interface doc) | 15:46 |
| gouthamr | tbarron: yeah, not inclined to do that - if a storage system can somehow detect data loss while shrinking a share, it should be able to do so before shrinking the share | 15:47 |
| tbarron | Sure, we set the expectations that drivers should do the right thing. But if we rely entirely on that then | 15:47 |
| gouthamr | tbarron: or during shrinking the share and refuse to shrink like Unity and NetApp doing so | 15:47 |
| tbarron | we can get rid of the possible data loss state entirely | 15:48 |
| tbarron | I think we all agree it's better for a back end to detect and prevent data loss. | 15:48 |
| gouthamr | yes, if there is an exception in that path, we'd set the status to "error" and log - allowing operators to take a look anyway | 15:48 |
| gouthamr | okay, dviroel are you still comfortable handling this bug? | 15:50 |
| dviroel | gouthamr: yes, we have danielarthurt looking at it right now | 15:50 |
| vhari | dviroel++ | 15:50 |
| tbarron | thanks dviroel | 15:50 |
| gouthamr | awesome, ty dviroel danielarthurt - when you have your findings, please summarize on the bug report | 15:51 |
| dviroel | sure thing | 15:51 |
| *** jakecoll has joined #openstack-meeting-alt | 15:52 | |
| vhari | cool, think we're almost out of time - passing on the token to gouthamr | 15:52 |
| gouthamr | this change should be backported, for us to continue using that test case as it is written | 15:52 |
| gouthamr | thank you vhari - this was an interesting one | 15:52 |
| vhari | indeed. yw | 15:52 |
| gouthamr | dviroel tbarron danielarthurt: we can brainstorm further on what that means - changing this behavior does seem like it gets into the grey area between a bugfix and a feature | 15:53 |
| gouthamr | but, i don't have bright ideas to fix a design issue like this | 15:54 |
| tbarron | yup | 15:54 |
| dviroel | +1 | 15:54 |
| gouthamr | okay, lets take this discussion to #openstack-manila and to the bug | 15:55 |
| gouthamr | danielarthurt: i'll subscribe to the bug, but, if you don't see a response from me/tbarron/dviroel after your update - please ping us :) | 15:55 |
| danielarthurt | Ok | 15:56 |
| gouthamr | ty | 15:56 |
| gouthamr | #topic Open Discussion | 15:56 |
| *** openstack changes topic to "Open Discussion (Meeting topic: manila)" | 15:56 | |
| andrebeltrami | dviroel: | 15:56 |
| dviroel | andrebeltrami has nothing to say, btw | 15:57 |
| dviroel | lol | 15:57 |
| lseki | lol | 15:57 |
| carloss | haha | 15:57 |
| gouthamr | haha, it was okay to gossip about you during open discussion | 15:57 |
| andrebeltrami | sorry for that :( | 15:58 |
| gouthamr | lol, np andrebeltrami | 15:58 |
| gouthamr | alright folks, lets wrap up and see each other on #openstack-manila | 15:58 |
| gouthamr | thank you for attending | 15:58 |
| carloss | thanks gouthamr | 15:58 |
| dviroel | thanks! | 15:58 |
| gouthamr | #endmeeting | 15:58 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings/" | 15:58 | |
| openstack | Meeting ended Thu Feb 27 15:58:45 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:58 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/manila/2020/manila.2020-02-27-15.01.html | 15:58 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/manila/2020/manila.2020-02-27-15.01.txt | 15:58 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/manila/2020/manila.2020-02-27-15.01.log.html | 15:58 |
| *** priteau has joined #openstack-meeting-alt | 16:00 | |
| *** diablo_rojo has joined #openstack-meeting-alt | 16:00 | |
| priteau | #startmeeting blazar | 16:00 |
| openstack | Meeting started Thu Feb 27 16:00:57 2020 UTC and is due to finish in 60 minutes. The chair is priteau. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| *** openstack changes topic to " (Meeting topic: blazar)" | 16:01 | |
| openstack | The meeting name has been set to 'blazar' | 16:01 |
| priteau | #topic Roll call | 16:01 |
| *** openstack changes topic to "Roll call (Meeting topic: blazar)" | 16:01 | |
| priteau | Hi jakecoll | 16:01 |
| jakecoll | good morning | 16:01 |
| priteau | Is diurnalist around? | 16:02 |
| jakecoll | He wanted to join today | 16:02 |
| jakecoll | I'll ping. He wanted to talk about a spec today. | 16:02 |
| *** diurnalist has joined #openstack-meeting-alt | 16:03 | |
| diurnalist | o/ | 16:03 |
| priteau | Hi diurnalist | 16:03 |
| diurnalist | Hello- I got mixed up with DST | 16:03 |
| priteau | Has it changed in the US already? | 16:04 |
| priteau | Nah it's in 10 days | 16:04 |
| priteau | Anyways | 16:04 |
| jakecoll | It messes with calendar if you haven't downloaded the ics file from the meetings page | 16:05 |
| priteau | Agenda for today: | 16:05 |
| priteau | * Update on specs work | 16:05 |
| diurnalist | ok, not sure what happened. i had it written down for 11am | 16:05 |
| priteau | * Upstream contributions | 16:05 |
| priteau | * AOB | 16:05 |
| jakecoll | http://eavesdrop.openstack.org/#Blazar_Team_Meeting | 16:05 |
| jakecoll | You'll want to add ics file at this link | 16:05 |
| priteau | Import the ical file and you won't have to ever update it | 16:05 |
| *** jcoufal has joined #openstack-meeting-alt | 16:05 | |
| diurnalist | thx | 16:06 |
| priteau | #topic Update on specs work | 16:06 |
| *** openstack changes topic to "Update on specs work (Meeting topic: blazar)" | 16:06 | |
| priteau | I am happy to say that I finally reviewed your spec diurnalist | 16:06 |
| priteau | #link https://review.opendev.org/#/c/707042/ | 16:06 |
| priteau | Sorry it took a couple of weeks | 16:07 |
| priteau | Overall I like the approach, just need to iron out some details of the payload | 16:08 |
| *** ccamacho has quit IRC | 16:08 | |
| priteau | Looks like tetsuro is not yet convinced | 16:09 |
| diurnalist | sounds good--I still prefer the service approach, but I'd be willing to follow something like a plugin approach using stevedore. with the downsides that it requires you to (a) use Python and (b) package the module locally (which usually means "manually") when using something like Kolla | 16:09 |
| diurnalist | i'll call out the downsides i see a bit more clearly in the alternatives and add the links you mentioned ot nova vendordata2. in that spec they discuss similar things | 16:10 |
| priteau | Did you see my suggestion from today | 16:10 |
| diurnalist | Yes | 16:10 |
| priteau | Use the plugin approach, with one of the plugins making calls to the external service | 16:10 |
| priteau | This way we could have a SimpleEnforcement plugin that does simple things like check max duration | 16:11 |
| priteau | NoopEnforcement would be default | 16:11 |
| diurnalist | ah, that's what you meant. yes, that might make sense | 16:11 |
| priteau | ExternalEnforcement would be your approach | 16:11 |
| priteau | Anyone could load their CustomEnforcement if they wish, their responsible for figuring out how to include the code in their container images if using kolla | 16:12 |
| *** e0ne has quit IRC | 16:12 | |
| priteau | s/their/they're/ | 16:12 |
| diurnalist | yes, that's of course more work but i had thought it would likely move in that direction eventually | 16:12 |
| priteau | A downside is that it means more places where the interface might change over time | 16:12 |
| priteau | But maybe it's not that much more work. After all, we probably want to encapsulate this anyway | 16:13 |
| diurnalist | it also opens the door to some sort of default QuotaEnforcement thing, which i think there is related work being thought about? | 16:13 |
| priteau | That's right | 16:13 |
| priteau | Although one might want QuotaEnforcement + ExternalEnforcement | 16:13 |
| diurnalist | >.< | 16:14 |
| diurnalist | haha | 16:14 |
| priteau | So it could be a list of plugins that are called sequentially | 16:14 |
| diurnalist | yeah, like nova's scheduler | 16:14 |
| priteau | like scheduler filters | 16:14 |
| *** links has quit IRC | 16:14 | |
| priteau | This is making the design a fair amount bigger, but it might be more flexible down the line | 16:15 |
| priteau | And if it solves tetsuro's concerns at the same time… | 16:15 |
| diurnalist | yep | 16:15 |
| diurnalist | I like the idea | 16:15 |
| priteau | The spec should describe the plugin API first then | 16:16 |
| priteau | Or another spec for the plugin API, the current one focusing on a specific implementation | 16:16 |
| diurnalist | Probably two specs makes sense in this case. If you have suggestions of how best to logically link them, I'd be interested | 16:17 |
| diurnalist | I can just put it in 'related' links | 16:17 |
| diurnalist | But I don't know if something more formal is usually done | 16:17 |
| priteau | I am not aware of any specific approach | 16:17 |
| priteau | References would be fine | 16:18 |
| priteau | What do you think about the need for identifying cloud & region in case the external service is shared? | 16:19 |
| diurnalist | Yes, I think that will be necessary. But, do you think that auth URL will be enough? I wonder if you can get region/domain from the client token. | 16:20 |
| diurnalist | I was just inspecting a token. One can get domain from that, but not region | 16:22 |
| priteau | I wanted to ask you why you were passing the client token to the service | 16:23 |
| priteau | In one of the vendordata2 specs, they say they should actually be passing a token from nova | 16:23 |
| diurnalist | I guess we don't need to. I initially thought it would be useful to fetch the list of leases under the user. But you can do that with the admin token. So, I guess user_id, project_id, user_domain_id, project_domain_id, and region_name will all have to be sent. Kind of a lot, but not sure how else to do it. | 16:24 |
| diurnalist | and auth_url | 16:24 |
| priteau | What's inside a fernet token? | 16:25 |
| diurnalist | project (id+name+domain), user (id+name+domain), roles attached, expiry, and endpoint catalog | 16:25 |
| diurnalist | and an issue date, and some other bookkeeping things like an audit ID and which auth method was used | 16:26 |
| priteau | Are you sure the catalog is in there? | 16:27 |
| priteau | https://docs.openstack.org/keystone/latest/admin/fernet-token-faq.html#why-should-i-choose-fernet-tokens-over-pki-or-pkiz-tokens | 16:27 |
| diurnalist | i'm just saying, if you inspect the token, the catalog is returned | 16:27 |
| priteau | "This issue is mitigated when switching to fernet because fernet tokens are kept under a 250 byte limit." | 16:27 |
| diurnalist | it's likely not encoded in there directly | 16:27 |
| priteau | Oh I see | 16:27 |
| *** tesseract has quit IRC | 16:27 | |
| priteau | PKI and PKIZ tokens apparently include the catalog | 16:27 |
| priteau | I think we should avoid transferring those tokens around | 16:28 |
| diurnalist | Sure | 16:28 |
| diurnalist | If everything can be done with the admin token, that is simpler | 16:28 |
| diurnalist | I was more worried that admin APIs might have missing functionality | 16:29 |
| diurnalist | if one needed to call other openstack APIs. a design where the token is decomposed as early as possible in the request chain is better in these distributed systems IMO | 16:29 |
| priteau | I think you can get all the information you need | 16:30 |
| diurnalist | We do at least need blazar to send some token of its own to the service, so the service knows it's actually blazar | 16:30 |
| priteau | I don't really like the idea of an external service making requests using a user token | 16:31 |
| diurnalist | which is in fact another argument for not sending the user token | 16:31 |
| diurnalist | I am not disagreeing | 16:31 |
| diurnalist | I'll update the spec | 16:32 |
| priteau | Thanks | 16:32 |
| priteau | I think that's the main points I wanted to raise | 16:32 |
| priteau | Already quite a lot :-) | 16:32 |
| priteau | #topic Upstream contributions | 16:33 |
| *** openstack changes topic to "Upstream contributions (Meeting topic: blazar)" | 16:33 | |
| priteau | jakecoll: I see you've updated your network reservation patch, thanks | 16:34 |
| priteau | It's next on my review list | 16:34 |
| priteau | I've also flagged it as a review priority for the rest of the team | 16:35 |
| jakecoll | yep. I just finished add allocations to networks on our fork. I'll update that as well. | 16:35 |
| priteau | That's great | 16:36 |
| priteau | Are you using the allocations API for blazar-dashboard now? | 16:36 |
| jakecoll | Yes. Just went live on prod 5 minutes ago. | 16:37 |
| priteau | wooo | 16:37 |
| diurnalist | We've been using it for the hosts dashboard for a few months | 16:37 |
| diurnalist | now it's in place for all types :) | 16:37 |
| priteau | I didn't realise it was already on the host dashboard | 16:38 |
| priteau | So except for gathering node types (which is a Chameleon concept), calendar could be database-query-free? | 16:38 |
| jakecoll | Well, diurnalist has another spec he wanted to talk about to get us there. | 16:39 |
| priteau | Ah, that's what you wanted to talk about? | 16:39 |
| priteau | Sorry, I thought it was the usage enforcement one | 16:39 |
| priteau | Let's talk about it then | 16:39 |
| *** lpetrut has quit IRC | 16:40 | |
| diurnalist | Yes, sorry | 16:41 |
| diurnalist | So, one of the improvements we've additionally made to blazar-dashboard is around making resource_properties easier to use | 16:42 |
| diurnalist | Right now you have to know the somewhat arcane invocation needed, especially when combining queries | 16:42 |
| diurnalist | So we have this resource filter (I know you know this, I'm just expanding for IRC logs) | 16:42 |
| diurnalist | It's a UI element that lists all the resource property keys that are available for filtering. The user selects which key they want to filter on, and then a list of all possible values for that key are displayed, allowing them to pick one. | 16:43 |
| diurnalist | This makes discovering possible resource property constraints much easier | 16:43 |
| priteau | And so we would need an API to discover these properties, as I think they are not visible to users by default? | 16:43 |
| diurnalist | Yes | 16:43 |
| diurnalist | They _may_ be visible to users by default, I'm not sure what the default host:list or host:get permissions are | 16:43 |
| diurnalist | But in any case, an API call will likely be much more efficient than the alternative, which is asking for every possible resource and then itemizing all keys/values | 16:44 |
| diurnalist | Plus, I thought it might actually be kind of easy to implement given how Blazar already has support for these extra capabilities, which are arbitrary k/v pairs | 16:44 |
| priteau | It's admin only by default | 16:44 |
| diurnalist | It's a bit of a weird API as it'd mainly be used in the dashboard, but if we design it nicely, it would probably be helpful for CLI users as well | 16:45 |
| diurnalist | Ah ok, then another reason to do it. | 16:45 |
| priteau | One thing I would say then | 16:45 |
| priteau | We may want to extend the DB schema to flag extra cap as user-visible | 16:45 |
| *** dosaboy has quit IRC | 16:45 | |
| priteau | Because operators may want to reserve some for them | 16:45 |
| *** jamesmcarthur has quit IRC | 16:45 | |
| diurnalist | That's a good point | 16:45 |
| priteau | You were thinking of something like GET /os-hosts/properties? | 16:46 |
| *** jamesmcarthur has joined #openstack-meeting-alt | 16:46 | |
| diurnalist | Yes, though extensions in to networks and other resources like IPs would also make sense | 16:46 |
| diurnalist | it's a cross-cutting feature in my mind | 16:47 |
| priteau | Of course | 16:47 |
| priteau | Though we already have /os-hosts/allocations | 16:47 |
| diurnalist | I think the API design is a bit odd in that we are re-implementing the same thing on multiple paths, but that's neither here nor there. I think if we define /properties as the path, it can extend os-hosts/ and networks/ and whatever else | 16:48 |
| *** ijw has joined #openstack-meeting-alt | 16:49 | |
| diurnalist | to be honest i'm not even sure how easy it is to make it a "general" feature because i think we re-implement all of the DB schemas as well for each resource type. don't we have to re-implement extra caps for example? i need to double-check | 16:49 |
| *** ijw has quit IRC | 16:49 | |
| priteau | extra caps is per-model | 16:49 |
| *** ijw has joined #openstack-meeting-alt | 16:49 | |
| priteau | Although I was thinking of abstracting it into a ResourceExtraCap model to make it more reusable | 16:49 |
| diurnalist | I would support that. I think there are other aspects of Blazar that should really be shared logic as well. it's becoming more important as the types of resources are scaling | 16:50 |
| diurnalist | But from this "properties" API--sounds OK in principle? | 16:50 |
| diurnalist | *for | 16:50 |
| priteau | Sounds OK to me | 16:51 |
| priteau | Spec needed of course | 16:51 |
| diurnalist | Yep | 16:51 |
| *** ccamacho has joined #openstack-meeting-alt | 16:53 | |
| priteau | We're getting near the end of the hour | 16:53 |
| priteau | #topic AOB | 16:53 |
| *** openstack changes topic to "AOB (Meeting topic: blazar)" | 16:53 | |
| priteau | Anything else to cover? | 16:53 |
| *** e0ne has joined #openstack-meeting-alt | 16:53 | |
| diurnalist | We have not yet discussed participating at Vancouver | 16:54 |
| jakecoll | I'm good for now. I'll keep a look out for comments on networks plugin | 16:54 |
| jakecoll | oh right | 16:54 |
| diurnalist | Maybe next time we will know what the plan is. Pierre, are you planning on being there? Are any other Blazar core members? | 16:54 |
| priteau | diurnalist: I've requested 0.5 to 1.5 day for Blazar | 16:54 |
| diurnalist | ok | 16:54 |
| priteau | tetsuro will be there. I don't know yet | 16:54 |
| priteau | Still some months away | 16:56 |
| diurnalist | mmhmm | 16:56 |
| diurnalist | Nothing else from me then | 16:57 |
| priteau | Wrapping up if there's nothing else? | 16:57 |
| priteau | Thanks a lot for the good discussion today | 16:57 |
| priteau | Great to get contributions from you | 16:57 |
| priteau | Next meeting the time will have changed in your local timezone! | 16:58 |
| diurnalist | Cheers! | 16:58 |
| priteau | #endmeeting | 16:58 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings/" | 16:58 | |
| openstack | Meeting ended Thu Feb 27 16:58:17 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:58 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/blazar/2020/blazar.2020-02-27-16.00.html | 16:58 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/blazar/2020/blazar.2020-02-27-16.00.txt | 16:58 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/blazar/2020/blazar.2020-02-27-16.00.log.html | 16:58 |
| *** dosaboy has joined #openstack-meeting-alt | 17:01 | |
| *** diurnalist has quit IRC | 17:09 | |
| *** diurnalist has joined #openstack-meeting-alt | 17:14 | |
| *** igordc has joined #openstack-meeting-alt | 17:39 | |
| *** priteau has quit IRC | 17:40 | |
| *** jakecoll has quit IRC | 17:42 | |
| *** igordc has quit IRC | 18:01 | |
| *** igordc has joined #openstack-meeting-alt | 18:04 | |
| *** danielarthurt has quit IRC | 18:08 | |
| *** macz_ has joined #openstack-meeting-alt | 18:12 | |
| *** macz_ has quit IRC | 18:14 | |
| *** macz_ has joined #openstack-meeting-alt | 18:15 | |
| *** e0ne has quit IRC | 18:21 | |
| *** jcoufal has quit IRC | 18:26 | |
| *** jamesmcarthur has quit IRC | 18:33 | |
| *** jamesmcarthur has joined #openstack-meeting-alt | 18:33 | |
| *** vhari has quit IRC | 18:52 | |
| *** e0ne has joined #openstack-meeting-alt | 18:57 | |
| *** andrebeltrami has quit IRC | 18:58 | |
| *** e0ne has quit IRC | 18:59 | |
| *** e0ne has joined #openstack-meeting-alt | 19:10 | |
| *** jamesmcarthur has quit IRC | 19:12 | |
| *** jamesmcarthur has joined #openstack-meeting-alt | 19:40 | |
| *** gyee has quit IRC | 19:49 | |
| *** gyee has joined #openstack-meeting-alt | 19:49 | |
| *** e0ne has quit IRC | 20:07 | |
| *** diurnalist has quit IRC | 20:16 | |
| *** ijw has quit IRC | 20:23 | |
| *** diurnalist has joined #openstack-meeting-alt | 20:26 | |
| *** kozhukalov has quit IRC | 20:27 | |
| *** kozhukalov has joined #openstack-meeting-alt | 20:28 | |
| *** ijw has joined #openstack-meeting-alt | 20:48 | |
| *** ijw has quit IRC | 20:53 | |
| *** ijw has joined #openstack-meeting-alt | 20:53 | |
| *** ijw has quit IRC | 20:54 | |
| *** ijw has joined #openstack-meeting-alt | 20:54 | |
| *** jamesmcarthur has quit IRC | 20:54 | |
| *** kozhukalov has quit IRC | 21:08 | |
| *** slaweq has quit IRC | 21:15 | |
| *** kozhukalov has joined #openstack-meeting-alt | 21:40 | |
| *** rcernin has joined #openstack-meeting-alt | 21:44 | |
| *** jamesmcarthur has joined #openstack-meeting-alt | 21:54 | |
| *** jamesmcarthur has quit IRC | 22:08 | |
| *** slaweq has joined #openstack-meeting-alt | 22:11 | |
| *** jamesmcarthur has joined #openstack-meeting-alt | 22:11 | |
| *** slaweq has quit IRC | 22:15 | |
| *** slaweq has joined #openstack-meeting-alt | 22:18 | |
| *** ijw has quit IRC | 22:19 | |
| *** slaweq has quit IRC | 22:22 | |
| *** ijw has joined #openstack-meeting-alt | 22:47 | |
| *** jamesmcarthur has quit IRC | 22:49 | |
| *** ijw has quit IRC | 22:52 | |
| *** ijw has joined #openstack-meeting-alt | 22:52 | |
| *** slaweq has joined #openstack-meeting-alt | 23:11 | |
| *** slaweq has quit IRC | 23:16 | |
| *** jamesmcarthur has joined #openstack-meeting-alt | 23:25 | |
| *** kozhukalov has quit IRC | 23:35 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!