| opendevreview | melanie witt proposed openstack/devstack-plugin-ceph master: DNM try without debian 12 https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/969523 | 00:22 |
|---|---|---|
| opendevreview | Inyong Hong proposed openstack/manila master: NetApp: Update created_at during manage operations https://review.opendev.org/c/openstack/manila/+/969546 | 01:11 |
| opendevreview | Inyong Hong proposed openstack/manila master: NetApp: Update created_at during manage operations https://review.opendev.org/c/openstack/manila/+/969546 | 01:12 |
| opendevreview | Inyong Hong proposed openstack/manila master: NetApp: Update created_at during manage operations https://review.opendev.org/c/openstack/manila/+/969546 | 01:12 |
| opendevreview | Inyong Hong proposed openstack/manila master: NetApp: Update created_at during manage operations https://review.opendev.org/c/openstack/manila/+/969546 | 01:13 |
| opendevreview | Inyong Hong proposed openstack/manila master: NetApp: Update created_at during manage operations https://review.opendev.org/c/openstack/manila/+/969546 | 01:21 |
| hong-p[m] | hi gouthamr carloss During the last PTG we discussed improving the created_at value for share and snapshot manage so that it reflects the actual creation timestamp in the storage backend instead of the time when Manila starts managing the resource. I have now created the corresponding Blueprint and a Change Request (CR) for this change. Could you please take a look and review? https://review.opendev.org/c/openstack/manila/+/969546 | 01:34 |
| opendevreview | kiran pawar proposed openstack/manila-specs master: Add spec for qos types https://review.opendev.org/c/openstack/manila-specs/+/962706 | 08:28 |
| opendevreview | Merged openstack/manila master: Drop eventlet usage in ssh pools https://review.opendev.org/c/openstack/manila/+/960231 | 09:34 |
| carloss | hey hong-p[m] - thanks for creating the blueprint and proposing the change | 10:11 |
| carloss | I'll take a look at both | 10:11 |
| opendevreview | Carlos Eduardo proposed openstack/manila master: [WIP] Fix rally jobs https://review.opendev.org/c/openstack/manila/+/969594 | 10:45 |
| opendevreview | Carlos Eduardo proposed openstack/manila master: [WIP] Fix rally jobs https://review.opendev.org/c/openstack/manila/+/969594 | 10:51 |
| opendevreview | Carlos Eduardo proposed openstack/manila master: [WIP] Fix rally jobs https://review.opendev.org/c/openstack/manila/+/969594 | 11:22 |
| opendevreview | Carlos Eduardo proposed openstack/manila master: Fix rally jobs https://review.opendev.org/c/openstack/manila/+/969594 | 12:06 |
| opendevreview | Carlos Eduardo proposed openstack/manila master: Fix rally jobs https://review.opendev.org/c/openstack/manila/+/969594 | 12:37 |
| opendevreview | kiran pawar proposed openstack/manila master: Add support for QoS type and specs https://review.opendev.org/c/openstack/manila/+/967822 | 14:52 |
| opendevreview | Goutham Pacha Ravi proposed openstack/manila stable/2025.2: Fix shares getting stuck in ensuring status https://review.opendev.org/c/openstack/manila/+/969795 | 15:29 |
| gouthamr | Kumar_T: from my understanding, NetApp supports migrating share servers that have replicated shares.. | 16:07 |
| gouthamr | the doc probably needs to call out there's a driver-reported attribute called: "share_replicas_migration_support" that allows/denies server migrations with replicated shares | 16:07 |
| Kumar_T | Ok. That guideline can be overridden by flag | 16:08 |
| kpdev | yes, we support migration with replicas and also removed all blocking code from API in our downstream repo | 16:08 |
| Kumar_T | Yes | 16:08 |
| gouthamr | specifically, if admins are concerned that they'd not be able to migrate share servers when replicated shares show up, they should be using that attribute as a share type extra-spec | 16:08 |
| gouthamr | that way they can prevent creation of replicated shares on DHSS=True backends where servers can't be migrated with replicas | 16:09 |
| Kumar_T | Kpdev you recall which version? | 16:09 |
| kpdev | i can not recollect version. may be git log . will help to see when migration with replica support was added | 16:10 |
| gouthamr | https://bugs.launchpad.net/manila/+bug/2052785 | 16:12 |
| gouthamr | https://review.opendev.org/c/openstack/manila/+/933902 | 16:12 |
| gouthamr | This issue was fixed in the openstack/manila 20.0.0.0rc1 Epoxy release candidate | 16:12 |
| kpdev | I had worked on this.. sorry I was not able to remeber it | 16:13 |
| kpdev | anyone has any questions on QoS spec, please raise. I will be here next 20 minuts. | 16:15 |
| Kumar_T | kpdev | 16:17 |
| Kumar_T | QoS spec feature is applicable for both DHSS mode ? Or only for DHSS true case? | 16:18 |
| Kumar_T | Next question: There will be drivers like NetApp who supports qos creation/usage using share extra specs already. | 16:19 |
| Kumar_T | https://netapp-openstack-dev.github.io/openstack-docs/draft/manila/deployment_choice/section_creating_service_catalog.html#table-6-12 | 16:19 |
| kpdev | for both, But please check internally | 16:19 |
| kpdev | Anoop has commented to keep this for DHSS=True and use legacy way of adaptive_qos i.e. share_type extra-spec for DHSS=False | 16:20 |
| kpdev | >Next question: There will be drivers like NetApp who supports qos creation/usage using share extra specs already. | 16:20 |
| kpdev | yes, we know this | 16:20 |
| Kumar_T | If user pass both in extra specs what is the outcome? Error? or some precedence? | 16:20 |
| Kumar_T | Sure lets discuss internally on driver behavior | 16:21 |
| kpdev | The create API is ADMIN only. so it is assumed that admin will configure share_type and qos_type correctly. | 16:21 |
| * carloss following the conversation, wanted to share a suggestion | 16:22 | |
| carloss | > But please check internally | 16:23 |
| carloss | kpdev internally you mean internal chats? | 16:23 |
| kpdev | The existing deployment can keep using specifying spec for fixed policy i.e. share type extra specs. and adaptive the same way for dhss=false as it takes only name | 16:23 |
| kpdev | for dhss=true we need all params i.e. using qos_type. | 16:24 |
| kpdev | internally means within Netapp team, I had couple of sync up calls with Netapp for Qos since last 2 months and after discussion and use case, the spec is created. | 16:24 |
| kpdev | So it was more suggestion from Netapp only to keep existing way for dhss=False and use new way for DHSS=True. In either case, Admin should make the correct configuration of qos_type and its mention in share-type extra-specs | 16:25 |
| carloss | kpdev ack, thanks... this is an interesting discussion and is nice context for upstream as well. Is it okay if I ask you guys to please use #openstack-manila for discussions around proposed specs/functionalities? I think it also helps everyone upstream | 16:26 |
| carloss | of course we should not drop customer names | 16:27 |
| carloss | but a question like this: QoS spec feature is applicable for both DHSS mode ? Or only for DHSS true case? | 16:27 |
| carloss | is definitely good context for upstream | 16:27 |
| kpdev | The spec ideally can be used for both DHSS=False and True. For SAP use case only DHSS=True as that is only scenario we support. | 16:28 |
| carloss | driver behavior is also something nice to keep the discussion upstream :) | 16:29 |
| carloss | sorry, trying to keep these discussions here so that you guys don't need to answer the same questions if someone upstream asks | 16:29 |
| carloss | also helps on getting feedback earlier | 16:29 |
| kpdev | we dont have deployment with fixed QoS and also no deployment with DHSS=False. So adaptive_qos and dhss=true was use case behind this. But since its way of specifying policy, this can be applied to fixed as well. | 16:30 |
| kpdev | since there will be some deployments with netapp having adaptive qos and dhss=false, Anoop asked to keep this support as it is. | 16:32 |
| carloss | > The create API is ADMIN only. so it is assumed that admin will configure share_type and qos_type correctly. | 16:32 |
| carloss | makes sense and that's a good question, Kumar_T - should we do checks to prevent this from happening though? | 16:32 |
| kpdev | the share type and qos type are passed to driver and driver can invalidate the share creation if both things exist w.r.t given share create request . Is it ? @carloss ? | 16:35 |
| carloss | yeah, or even in the api kpdev: that conflict can be identified earlier than in the driver | 16:35 |
| carloss | if both are provided and both have conflicting specs, then we'd know earlier | 16:36 |
| kpdev | in api layer then it will be driver specific check. are you ok with it ? | 16:36 |
| carloss | kpdev: not driver specific check, extra spec check | 16:36 |
| carloss | different things | 16:36 |
| kpdev | which extra spec check ? | 16:37 |
| kpdev | if default_qos_type and netapp:max_iops exist in extra-spec ? | 16:38 |
| carloss | what I mean is: qos is currently set through extra specs, right? qos type will also have key value specs, right? | 16:38 |
| carloss | if qos type has max_iops and share type has max_iops, what happens? | 16:39 |
| carloss | or am I misunderstanding how we'll set the qos specs to the qos type? | 16:39 |
| kpdev | share_type wont have max_iops. this will be netapp:max_iops and so the check will be driver specific | 16:40 |
| kpdev | so let driver handle mismatch | 16:40 |
| carloss | yep, that works | 16:40 |
| kpdev | Ack | 16:40 |
| kpdev | Leaving, thanks ! | 16:49 |
| opendevreview | Goutham Pacha Ravi proposed openstack/manila stable/2025.1: Fix shares getting stuck in ensuring status https://review.opendev.org/c/openstack/manila/+/969827 | 17:57 |
| opendevreview | Merged openstack/manila stable/2025.2: Fix shares getting stuck in ensuring status https://review.opendev.org/c/openstack/manila/+/969795 | 18:42 |
| opendevreview | Goutham Pacha Ravi proposed openstack/python-manilaclient master: Add missing api_versions decorator for _update_share_group https://review.opendev.org/c/openstack/python-manilaclient/+/968436 | 18:43 |
| opendevreview | Merged openstack/manila master: Fix rally jobs https://review.opendev.org/c/openstack/manila/+/969594 | 19:21 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!