Re: [vdsm] new API verb: getVersionInfo()
21.10.2012 09:23, Dan Kenigsberg kirjoitti: skip / We should decide NOW on the format of the capabilities «bag», and never change it. Testing for a capability is much more reliable than checking a version, and remembering which version had which capability. Dan. Ok, so what will we decide? 1. (long)int bitmask? … vdsm.caps.CAP_DRIVES = 0x2 … 2. list of literals? … vdsm.caps.capabilities = [drives, …] 3. something else? I would prefer the second way, with list of strings. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] new API verb: getVersionInfo()
On Sun, Oct 21, 2012 at 02:26:44PM +0200, Peter V. Saveliev wrote:
21.10.2012 09:23, Dan Kenigsberg kirjoitti:
skip /
We should decide NOW on the format of the capabilities «bag», and never
change it. Testing for a capability is much more reliable than checking
a version, and remembering which version had which capability.
Dan.
Ok, so what will we decide?
1. (long)int bitmask?
… vdsm.caps.CAP_DRIVES = 0x2 …
2. list of literals?
… vdsm.caps.capabilities = [drives, …]
I believe that (2) is basically what Adam Litke has propesed earlier, and I've
liked:
{'enum': 'Capabilities',
'data': ['StorageDomain_30', 'StorageDomain_22', 'Sanlock', ...]}
'capabilities': ['Capabilities']
Dan.
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] new API verb: getVersionInfo()
On 10/18/2012 10:11 PM, Saggi Mizrahi wrote: I don't see how pyinotify is even related to storage stats. Well I am not sure where I would have mentioned storage statistics. It doesn't work with NFS and is a bit flaky when it comes to VFSs like proc or dev. Also it doesn't check liveness or latency so the events don't really give us anything useful. It's not like that pyinotify is the holy grail for all purposes. I was talking about caching the package (rpm/dpkg) changes and have pyinotify track this for cache invalidation. After that I wrote that I really would like to cache everything. The data is being taken from cache. I assume there is a prepare call there that makes everything slower. What is 'everything'? You might have a slightly slower start up of VDSM however a faster response on getCaps. once everything is going to be cached. I am not sure where this relates to 'make everything slower'. This will only be fixed with new style domains that don't have a built in sdUUID. That is a particular problem then. And I have said that I will send it to the list before, so we can speak about the pro/contras in the proposal to fix it. - Original Message - From: Vinzenz Feenstra vfeen...@redhat.com To: Itamar Heim ih...@redhat.com Cc: Saggi Mizrahi smizr...@redhat.com, Michal Skrivanek mskri...@redhat.com, vdsm-devel@lists.fedorahosted.org Sent: Thursday, October 18, 2012 3:15:47 PM Subject: Re: [vdsm] new API verb: getVersionInfo() On 10/18/2012 08:34 PM, Itamar Heim wrote: On 10/18/2012 06:03 PM, Saggi Mizrahi wrote: currently getVdsCaps() does a lot of unrelated things most of them have no relation to capabilites. This was done because of HTTP overhead. Instead of calling multiple commands we will call one that does everything. I agree with the suggestion that getVdsCaps() will actually return the capabilities. Capabilities being: - storage core version supported domain formats - VM core version and supported host capabilites. - network core and capabilities. - etc... These all should be mostly static and set at boot. As to the query API. I personally dislike the idea of a bag API. Now that we are moving away from HTTP, call overhead is no longer an issue so we can have multiple verbs and call them sequentially. In actuality we already do. Internally getVdsCaps() just aggregates other APIs. This makes return values of the method easier to handle and makes changing the results of an API call not affect users that don't care about that change. This also has better performance as storage APIs tend to slow the response and sending multiple commands would mean that you can get the Network stats even though the storage server is down. i thought getVdsCaps return the storage results from cache, which is refreshed by another thread, to make sure getVdsCaps has no latency. Well this is what it should do but it still doesn't do it. At least from what I have seen so far. I am currently working on a PoC implementation for caching packages and having so pyinotify based trigger for refreshing the cache. I plan to really cache everything and we'll have a background thread running for updating the cached data on changes. I will be sending the proposed solution for it to the list. So we can discuss it into more details. -- Regards, Vinzenz Feenstra Senior Software Engineer IRC: vfeenstr or evilissimo -- Regards, Vinzenz Feenstra Senior Software Engineer IRC: vfeenstr or evilissimo ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] new API verb: getVersionInfo()
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
Re: [vdsm] new API verb: getVersionInfo()
currently getVdsCaps() does a lot of unrelated things most of them have no
relation to capabilites.
This was done because of HTTP overhead. Instead of calling multiple commands we
will call one that does everything.
I agree with the suggestion that getVdsCaps() will actually return the
capabilities.
Capabilities being:
- storage core version supported domain formats
- VM core version and supported host capabilites.
- network core and capabilities.
- etc...
These all should be mostly static and set at boot.
As to the query API. I personally dislike the idea of a bag API. Now that we
are moving away from HTTP, call overhead is no longer an issue so we can have
multiple verbs and call them sequentially. In actuality we already do.
Internally getVdsCaps() just aggregates other APIs.
This makes return values of the method easier to handle and makes changing the
results of an API call not affect users that don't care about that change.
This also has better performance as storage APIs tend to slow the response and
sending multiple commands would mean that you can get the Network stats even
though the storage server is down.
- Original Message -
From: Dan Kenigsberg dan...@redhat.com
To: Adam Litke a...@us.ibm.com
Cc: vdsm-devel@lists.fedorahosted.org, Michal Skrivanek
mskri...@redhat.com
Sent: Thursday, October 18, 2012 4:38:16 AM
Subject: Re: [vdsm] new API verb: getVersionInfo()
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
Re: [vdsm] new API verb: getVersionInfo()
On 10/18/2012 06:03 PM, Saggi Mizrahi wrote: currently getVdsCaps() does a lot of unrelated things most of them have no relation to capabilites. This was done because of HTTP overhead. Instead of calling multiple commands we will call one that does everything. I agree with the suggestion that getVdsCaps() will actually return the capabilities. Capabilities being: - storage core version supported domain formats - VM core version and supported host capabilites. - network core and capabilities. - etc... These all should be mostly static and set at boot. As to the query API. I personally dislike the idea of a bag API. Now that we are moving away from HTTP, call overhead is no longer an issue so we can have multiple verbs and call them sequentially. In actuality we already do. Internally getVdsCaps() just aggregates other APIs. This makes return values of the method easier to handle and makes changing the results of an API call not affect users that don't care about that change. This also has better performance as storage APIs tend to slow the response and sending multiple commands would mean that you can get the Network stats even though the storage server is down. i thought getVdsCaps return the storage results from cache, which is refreshed by another thread, to make sure getVdsCaps has no latency. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] new API verb: getVersionInfo()
On 10/18/2012 08:34 PM, Itamar Heim wrote: On 10/18/2012 06:03 PM, Saggi Mizrahi wrote: currently getVdsCaps() does a lot of unrelated things most of them have no relation to capabilites. This was done because of HTTP overhead. Instead of calling multiple commands we will call one that does everything. I agree with the suggestion that getVdsCaps() will actually return the capabilities. Capabilities being: - storage core version supported domain formats - VM core version and supported host capabilites. - network core and capabilities. - etc... These all should be mostly static and set at boot. As to the query API. I personally dislike the idea of a bag API. Now that we are moving away from HTTP, call overhead is no longer an issue so we can have multiple verbs and call them sequentially. In actuality we already do. Internally getVdsCaps() just aggregates other APIs. This makes return values of the method easier to handle and makes changing the results of an API call not affect users that don't care about that change. This also has better performance as storage APIs tend to slow the response and sending multiple commands would mean that you can get the Network stats even though the storage server is down. i thought getVdsCaps return the storage results from cache, which is refreshed by another thread, to make sure getVdsCaps has no latency. Well this is what it should do but it still doesn't do it. At least from what I have seen so far. I am currently working on a PoC implementation for caching packages and having so pyinotify based trigger for refreshing the cache. I plan to really cache everything and we'll have a background thread running for updating the cached data on changes. I will be sending the proposed solution for it to the list. So we can discuss it into more details. -- Regards, Vinzenz Feenstra Senior Software Engineer IRC: vfeenstr or evilissimo ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] new API verb: getVersionInfo()
I don't see how pyinotify is even related to storage stats. It doesn't work with NFS and is a bit flaky when it comes to VFSs like proc or dev. Also it doesn't check liveness or latency so the events don't really give us anything useful. The data is being taken from cache. I assume there is a prepare call there that makes everything slower. This will only be fixed with new style domains that don't have a built in sdUUID. - Original Message - From: Vinzenz Feenstra vfeen...@redhat.com To: Itamar Heim ih...@redhat.com Cc: Saggi Mizrahi smizr...@redhat.com, Michal Skrivanek mskri...@redhat.com, vdsm-devel@lists.fedorahosted.org Sent: Thursday, October 18, 2012 3:15:47 PM Subject: Re: [vdsm] new API verb: getVersionInfo() On 10/18/2012 08:34 PM, Itamar Heim wrote: On 10/18/2012 06:03 PM, Saggi Mizrahi wrote: currently getVdsCaps() does a lot of unrelated things most of them have no relation to capabilites. This was done because of HTTP overhead. Instead of calling multiple commands we will call one that does everything. I agree with the suggestion that getVdsCaps() will actually return the capabilities. Capabilities being: - storage core version supported domain formats - VM core version and supported host capabilites. - network core and capabilities. - etc... These all should be mostly static and set at boot. As to the query API. I personally dislike the idea of a bag API. Now that we are moving away from HTTP, call overhead is no longer an issue so we can have multiple verbs and call them sequentially. In actuality we already do. Internally getVdsCaps() just aggregates other APIs. This makes return values of the method easier to handle and makes changing the results of an API call not affect users that don't care about that change. This also has better performance as storage APIs tend to slow the response and sending multiple commands would mean that you can get the Network stats even though the storage server is down. i thought getVdsCaps return the storage results from cache, which is refreshed by another thread, to make sure getVdsCaps has no latency. Well this is what it should do but it still doesn't do it. At least from what I have seen so far. I am currently working on a PoC implementation for caching packages and having so pyinotify based trigger for refreshing the cache. I plan to really cache everything and we'll have a background thread running for updating the cached data on changes. I will be sending the proposed solution for it to the list. So we can discuss it into more details. -- Regards, Vinzenz Feenstra Senior Software Engineer IRC: vfeenstr or evilissimo ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] new API verb: getVersionInfo()
18.10.2012 18:03, Saggi Mizrahi kirjoitti: currently getVdsCaps() does a lot of unrelated things most of them have no relation to capabilites. This was done because of HTTP overhead. Instead of calling multiple commands we will call one that does everything. skip / Can I please make a small note, before we went too deeply into getVdsCapabilities() discussion. What the getVdsCapabilities returns now, it is, literally speaking, *host*info*. That means some reasonable description of the host — installed packages, cpu topology, so on, so forth. … What I propose, is just a dedicated call, that will not carry «all-in-one» info, but only the *version* information. By historical reason there are several meanings of the «version» term in the context of the VDSM — that is VDSM version, RHEV version, cluster versions… But nevertheless. I would stress again: * *not* the host info * *not* the installed packages list * *not* the installed hardware specifications Maybe even not the current weather conditions outside of the datacenter. But only supported *versions* of VDSM *protocols* (API versions). … Returning the version can be done in a fast, reliable manner — yes, I know that one can implement fast cache for rpm queries and so on, but please think: can *any* caching be more reliable and more fast than returning several constant literals? The version information is the basic and vital info in the mixed environment with several versions of the same software. It can be queried often, it must be as simple as it can be at all. That's why I proposed a dedicated API call, that does nothing but returns the version. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] new API verb: getVersionInfo()
… Just to be clear: yes, I think, that getVdsCapabilities() can and should be optimized, but as well it has quite different meaning for different purposes. And what about capabilities «bag» — its format also can be a subject of a change (e.g. long int bitmask ⇒ list of literals), but the version can always remain the version. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] new API verb: getVersionInfo()
… 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
