| *** mhen_ is now known as mhen | 02:52 | |
| carloss | #startmeeting manila | 15:00 |
|---|---|---|
| opendevmeet | Meeting started Thu Jan 15 15:00:22 2026 UTC and is due to finish in 60 minutes. The chair is carloss. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| opendevmeet | The meeting name has been set to 'manila' | 15:00 |
| gouthamr | o/ | 15:00 |
| vhari | hi | 15:00 |
| carthaca | hi | 15:00 |
| carloss | courtesy ping: vhari carthaca Sai gireesh Kumar_T | 15:00 |
| Sai | o/ | 15:01 |
| carloss | #chair gouthamr vhari | 15:01 |
| opendevmeet | Current chairs: carloss gouthamr vhari | 15:01 |
| Kumar_T | Hi | 15:01 |
| Anoop_Shukla_ | O/ | 15:01 |
| gireesh | o/ | 15:02 |
| carloss | #topic Announcements | 15:02 |
| carloss | Schedule and Deadlines | 15:02 |
| carloss | #link https://releases.openstack.org/gazpacho/schedule.html (Gazpacho Schedule) | 15:03 |
| carloss | we're two weeks away from feature proposal freeze and new driver deadline | 15:03 |
| carloss | meaning: all new Manila features must be proposed and substantially completed, with unit, functional and integration tests by the end of the R-9 week. Collaborative review sessions must be proposed at this timeline, in order to speed up the review process. | 15:04 |
| carloss | and | 15:04 |
| carloss | by the end of the R-9 week, all new backend drivers for Manila must be substantially complete, with unit tests, and passing 3rd party CI. Drivers do not have to actually merge until feature freeze. | 15:04 |
| carloss | alright, that's all I had for $topic. Is there any other announcement you'd like to share with the community today? | 15:06 |
| carloss | #topic Review Focus | 15:08 |
| carloss | looking at our review focus etherpad | 15:09 |
| carloss | #link https://etherpad.opendev.org/p/manila-gazpacho-review-focus (Gazpacho review focus) | 15:09 |
| carloss | new changes were added and I was finally able to start working on the reviews for the features being proposed | 15:10 |
| carloss | and started with QoS specs | 15:10 |
| gouthamr | a word about ending this meeting early, carloss has to drop off to an appointment in 10 minutes, and I’m feeling under the weather :/ I can hang around and discuss things if needed.. | 15:10 |
| carloss | gouthamr++ | 15:11 |
| vhari | gouthamr++ | 15:11 |
| vhari | there are no new bugs to triage this week | 15:12 |
| vhari | pls share any concerns in this slot or via the manila channel | 15:12 |
| carloss | only one more note on review focus: we can use the etherpad to look at the changes. I'll keep doing so today and in the upcoming week | 15:13 |
| Anoop_Shukla_ | We wanted to talk about the same snapshot expectations from manila point of view. @Kumar_T - do you want to summarise the issue we are currently facing? | 15:14 |
| Sai | I think Kumar has already summarized it to carloss offline. | 15:16 |
| Sai | That should be fine I guess, today we have limited time :) | 15:16 |
| carloss | the context for everyone would be good though | 15:16 |
| carloss | but yes, if you'd like, we can also continue this in #openstack-manila | 15:17 |
| Kumar_T | At present ONTAP sync policy doesnt replication of the snapshots taken prior to relationship creation | 15:18 |
| Sai | > the context for everyone would be good though | 15:18 |
| Sai | Ack | 15:18 |
| gouthamr | from what I understand, snapshots taken prior to replica creation aren’t replicated when using synchronous replicas | 15:18 |
| Kumar_T | for sync policies | 15:18 |
| Kumar_T | We will be raising a dependency on ontap to provide option to copy the local snapshot at the time of snapmirror init or bulk snapshot copy api | 15:18 |
| Kumar_T | for now we will be documenting as we are aligning with ontap behavior and provide workaround of manually copy using ontap api if any users wants it to do | 15:19 |
| Kumar_T | 8:36:52 PM | 15:19 |
| Kumar_T | once ontap gives the option we will support that usecase | 15:19 |
| gouthamr | okay, doesn’t the driver have a mechanism to report individual snapshot status? if so it can set it to “error” and have a user message indicating why | 15:19 |
| Kumar_T | Yes | 15:19 |
| Kumar_T | we provide steps to copy manually | 15:20 |
| Kumar_T | once it is done it should be available and in-sync in next discovery | 15:20 |
| gouthamr | oh if there’s a workaround, wouldn’t the driver just want to do it? | 15:20 |
| gouthamr | carloss: I can take it from here, Ty! | 15:20 |
| carloss | gouthamr: thank you very much | 15:21 |
| Anoop_Shukla_ | Why is there an expectation from manila that all snapshots should be copied? Is that how all other storage policies for snapmirror work as well? | 15:21 |
| Kumar_T | the existing transfers api comes with limitation of single copy and no parallel calls | 15:21 |
| Anoop_Shukla_ | I mean for other vendor drivers. | 15:21 |
| gouthamr | Anoop_Shukla_: yes that’s how it was designed; but, with flexibility iirc to set an “error” state where a snapshot couldn’t be replicated | 15:23 |
| carloss | gouthamr++ Anoop_Shukla_++ Kumar_T++ vhari++ Sai++ thanks folks | 15:24 |
| gouthamr | Ty carloss | 15:24 |
| Anoop_Shukla_ | Is the expectation that a backup is unusable if it cannot be replicated? | 15:24 |
| Anoop_Shukla_ | Thanks Carlos take care. | 15:24 |
| Anoop_Shukla_ | Because these are two different use cases. One for local protection another one for remote protection. | 15:25 |
| Kumar_T | Ty Carlos | 15:25 |
| Sai | Take care and thanks carloss | 15:25 |
| gouthamr | yes, imagine the primary site is down, you promote to use the secondary site and expect to still use your backup | 15:26 |
| vhari | carloss++ | 15:26 |
| Anoop_Shukla_ | If we error out - a snapshot taken prior to replication cannot be used to revert share content. | 15:26 |
| Anoop_Shukla_ | Agreed.. | 15:26 |
| gouthamr | by backup here I mean a snapshot | 15:26 |
| gouthamr | A “point in time backup copy” as it is referred to sometimes | 15:27 |
| Anoop_Shukla_ | Yep..customers generally keep golden copies of backups..which serve as goto snapshots in worst case. | 15:27 |
| gouthamr | there is a natural queuing mechanism implemented in the creation of replicated snapshots | 15:28 |
| gouthamr | the manager polls the driver repeatedly to check whether the snapshot has made it | 15:28 |
| gouthamr | the ONTAP driver could rely on this and wait for a replica to go in-sync before attempting to replicate the snapshot | 15:29 |
| Anoop_Shukla_ | So in case currently we do not have a way to efficiently copy older snapshots with sync snapmirror..what should be our way forward? Should we still do it via snapmirror transfers api one by one..which can be painstakingly slow sometimes. | 15:29 |
| gouthamr | yes, you’re suggesting that as a workaround, aren’t you | 15:30 |
| Anoop_Shukla_ | Yep..since we cannot do it during initialize..we will need to perform it in looped call.. | 15:30 |
| gireesh | this should be one time operation, do we need looping call for this | 15:32 |
| gouthamr | yeah, consider that.. there may be some kinks to iron out in the share manager too wrt the status updates | 15:32 |
| Anoop_Shukla_ | We will open a requirement to the platform team..but till that's not there..we may need to use this workaround | 15:32 |
| gouthamr | the looping call runs from the share manager | 15:32 |
| Anoop_Shukla_ | Right | 15:32 |
| Anoop_Shukla_ | Kumar any other views on this? | 15:33 |
| Kumar_T | I dont have any, we need to go with manual steps for time being until either ontap support for sync or some other means platform you are referring. | 15:34 |
| gouthamr | by manual steps, you mean Apis explicitly executed by the driver after waiting | 15:35 |
| Anoop_Shukla_ | Manual you mean we will do transfers within the driver code right? | 15:35 |
| Kumar_T | not in code as parallel calls and bulk transfers are not allowed by SM on same target. | 15:36 |
| Kumar_T | using ontap cli or api. | 15:36 |
| Kumar_T | for those precreated snapshots | 15:36 |
| gouthamr | I’ll let you check how snapshots are replicated in the share manager before making that call | 15:38 |
| gouthamr | alright, any other topics for today? | 15:40 |
| gouthamr | looks like nothing else; if you have any please post on #openstack-manila | 15:42 |
| gouthamr | thank you for participating, apologies for the shorter meeting today | 15:42 |
| Sai | Thank you, take care gouthamr !! | 15:42 |
| Kumar_T | Thank you all. | 15:42 |
| gouthamr | #endmeeting | 15:42 |
| opendevmeet | Meeting ended Thu Jan 15 15:42:50 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:42 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/manila/2026/manila.2026-01-15-15.00.html | 15:42 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/manila/2026/manila.2026-01-15-15.00.txt | 15:42 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/manila/2026/manila.2026-01-15-15.00.log.html | 15:42 |
| gouthamr | thank you Sai | 15:42 |
| *** gmaan is now known as gmaan_afk | 16:33 | |
| *** gmaan_afk is now known as gmaan | 17:46 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!