On Wed, Oct 17, 2012 at 10:07:43AM -0500, Adam Litke wrote:
> Thanks for posting your idea on the list here. I like the idea of a more
> fine-grained version query API. getVdsCapabilities has become too much of a
> catch-all and I agree that something lighter is useful. I do think vdsm will
> want to add a real capabilities mechanism and it could probably go here as
> well.
>
> As we work to make the vdsm API evolve in a stable, compatible manner,
> capabilities/feature-bits will come into play. Since you're proposing a
> structure return value, we can easily add the capabilities field to it in a
> future release, but it might make sense to have it there now to reduce
> client-side complexity of figuring out if the return value has a capabilities
> item.
>
> To avoid the bloat that we have with the current getVdsCapabilities API, I
> propose a simple format for the new capabilities:
>
> {'enum': 'Capabilities',
> 'data': ['StorageDomain_30', 'StorageDomain_22', 'Sanlock', ...]}
>
> and then add the following to the return type for your new API:
>
> 'capabilities': ['Capabilities']
>
> This is essentially an expandable bitmask of features where a feature is
> present
> by its presense in the 'capabilities' array. This will be extensible by
> simply
> adding new capabilities to the enum as we find them to be necessary.
>
> Thoughts on this? The reason I am bringing it up now is it would be nice to
> restrict the pain of migrating to this new version API to just one time.
I fully agree - that's what I've ment in my
http://gerrit.ovirt.org/#/c/8431/4/vdsm_api/vdsmapi-schema.json comment
on a "bag" of capability flags.
>
>
> On Wed, Oct 17, 2012 at 01:37:08PM +0200, Peter V. Saveliev wrote:
> > …
> >
> > New verb proposal: getVersionInfo()
> >
> >
> > Background
> >
> > Right now VDSM has only one possibility to discover the peer VDSM
> > version — it is to call getVdsCapabilities(). All would be nice, but
> > the verb does a lot of stuff, including disk I/O (rpm data query).
> > It is a serious issue for high-loaded hosts, that can even trigger
> > call timeout.
> >
> >
> > Rationale
> >
> > Working in an environment with multiple VDSM versions, it is
> > inevitable to fall in a simple choice:
> >
> > * always operate with one API, described once and forever
> > * use different protocol versions.
> >
> > It is a common practice to reserve something in a protocol, that
> > will represent the protocol version. Any protocols w/o version info
> > sooner or later face the need to guess a version, that is much
> > worse.
> >
> > On the other hand, involving rpm queries and CPU topology
> > calculation into the protocol version discovery is an overkill. So
> > the simplest way is to reserve a new verb for it.
> >
> >
> > Usecases
> >
> > It can be used in the future in *any* VDSM communication that can
> > expose version difference.
> >
> >
> > Implementation
> >
> > Obviously, the usage of a new verb in the current release, e.g.
> > RHEV-3.1 can be done only in try/catch way, 'cause RHEV-3.0 does not
> > support it. But to be able to use it in RHEV-3.2, we should already
> > have it in 3.1. Even if we will not use it yet, the future usecases
> > are pretty straightforward.
> >
> > So pls comment it: http://gerrit.ovirt.org/#/c/8431/
> >
> > --
> > Peter V. Saveliev
> >
> > _______________________________________________
> > vdsm-devel mailing list
> > vdsm-devel@lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>
> --
> Adam Litke <a...@us.ibm.com>
> IBM Linux Technology Center
>
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel@lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
