SMAPIv3 community kickoff

[olivierlambert]

Hi everyone! 👋

We'd like to announce a public kickoff meeting related to SMAPIv3, under the aegis of the XAPI Project (inside Xen Project, inside LF). It will be related to the open part: the API and related architecture. Since we'll develop many different open source storage plugins, it's very likely we'll bring modification/improvements to the API and components. So it's better to do it collaboratively.

We already had some discussions about this with @edwintorok during the last Xen Summit, but this time we will bring a list of features and requirements that we identified on our side, that we'd like to complete with you guys. Then, we could split the work into smaller pieces to actually deliver something sooner than later.

Everyone is welcome obviously :) We'd like to target a first meeting somewhere next week (on Jitsi), 30min to list the prerequisites and target is reasonable to start with. If you have some preferences regarding the time slot, let me know, we are pretty flexible. Here is a first list of possible schedule:

• Tuesday afternoon (23rd) after 2PM UTC
• Wednesday morning (24th) after 10AM UTC or afternoon after 3PM UTC
• anytime Thursday or Friday (25/26th)

Let us know and see you there :)

[olivierlambert]

Adding also @robhoes in the loop :)

[alexbrett]

Hi Olivier - I'm responding on behalf of XenServer (and for the avoidance of doubt I am not trying to speak on behalf of the XAPI Project) - apologies for the delayed reply, but at the moment I'm afraid that SMAPIv3 is not high enough up our priority list to really dedicate time to having meetings or actually working on improvements for it. We would be OK (as time permits) to look at any proposed changes and potentially give some feedback though if you wanted to draft up a summary/document showing your thinking?

[olivierlambert]

Hello @alexbrett,

Thank you very much for your response and for clarifying XenServer's current stance on SMAPIv3. We understand and appreciate the constraints you are working under, and the importance of prioritizing your efforts where they are most needed.

Given the context you've provided, we would like to propose a compromise that acknowledges these constraints while still allowing for some level of collaboration. Our intention is not to impose a significant workload on the XenServer team but rather to ensure open communication and alignment on the future direction of SMAPIv3, particularly in terms of architecture and server-side considerations.

To that end, we are suggesting a brief, one-time discussion to cover the following points:

• Reviewing the current features of SMAPIv3 and identifying any significant gaps or missing elements.
• Discussing any potential concerns or objections XenServer might have regarding our proposed changes or directions.

Our goal with this meeting is not to commit XenServer to any immediate work, but rather to ensure that as we move forward, we do so with a clear understanding of your perspective and constraints. This way, we hope to minimize any future integration challenges and foster a more collaborative environment.

We believe that this approach will benefit both our teams by laying the groundwork for smoother cooperation and mutual support in the future, even if active development participation from XenServer is not feasible at this time.

Please let us know if this sounds like a reasonable approach to you, and if so, we can work together to find a suitable time for this discussion. We remain flexible on timing and are committed to making this as convenient as possible for your team.

Looking forward to your thoughts!

[alexbrett]

Hi Olivier,

I'm afraid that at the moment the team is very busy working to get XenServer 8 ready for general availability (GA), so I'd like to avoid adding any extra distractions at least until that has happened.

On the more general front, our current understanding (from our proprietary SMAPIv3 SR work) is that there aren't any significant gaps in the actual API, other than that we are aware of some limited Xapi work that will be needed to support e.g. storage motion. As such to make any discussion more useful, it might be helpful if you could document in advance any areas you think there are gaps, and perhaps a very rough outline of any proposed changes, so we could review them and have a chance to think about them, as I imagine otherwise an ad-hoc discussion may not be particularly productive - would that be possible?

[olivierlambert]

Hi Alex,

Thanks for the heads-up about XenServer 8. We get the pressure of GA deadlines and the need to keep the focus tight. That said, our decade-plus journey with Xen Orchestra, deeply entwined with SMAPI, has given us unique insights into the API's practicalities and its gaps—insights that we're eager to share for mutual benefit.

We're not just looking to highlight issues but to push for an API evolution that could significantly enhance XenServer's appeal to larger backup solution providers, like VEEAM, by simplifying integration and expanding functionality. To this end, we'll draft a concise document pinpointing the critical areas where enhancements could lead to broader adoption and better performance.

This isn't about adding to your workload; it's about laying a foundation for a more robust, attractive XenServer ecosystem. We believe that with minimal effort, based on strategic feedback from your side, we can help steer the API towards this goal.