[WiP] CP-26340: SR.probe changes #208
Conversation
storage/storage_interface.ml
Outdated
| type probe = { | ||
| srs: (string * sr_info) list; (* SRs we found *) | ||
| uris: string list; (* other uris we found which could be probed recursively *) | ||
| attachable: (device_config * sr_info) list; (* Attachable SRs we found *) |
There was a problem hiding this comment.
Again, a question about the naming here: since in SMAPIv3 SM returns an sr for these SRs, which is the same type that's returned by SR.attach, does that mean that these SRs are already attached?
In SMAPIv3, the interface allows us to use these srs returned by probe to do operations like SR.ls. 🤔
There was a problem hiding this comment.
That is a good point, @MarkSymsCtx: does probe need to list already attached SRs differently from SRs that are present and not attached already?
Should we have 4 categories of probe results then?
- incomplete
- creatable
- attached
- introduceable/attachable
There was a problem hiding this comment.
Otherwise someone could take an SR returned by probe, run SR.ls on it as @gaborigloi pointed out and get an error because its not actually mounted anymore...
There was a problem hiding this comment.
Yeah, maybe we could return 4 lists of probe results. Or just have a variable which can be one of the four categories.
There was a problem hiding this comment.
I think for the above reasons we should definitely not return an sr for an existing SR that isn't attached. I think should indicate differently that there is an existing SR with this configuration.
There was a problem hiding this comment.
the plugin probe code is unlikely to be able to determine the difference between an attached SR and a detached but attachable SR give the input provided to it via probe.
edwintorok
force-pushed
the
feature/REQ477/probe
branch
from
91180d7
to
4a51c13
Compare
SMAPIv3 returns a list of configurations: * suitable for SR.attach together with sr_info * suitable for SR.create * suitable as further input to SR.probe (recursively) SMAPIv1 is unaffected, it always returns a `Raw` result. Signed-off-by: Edwin Török <edvin.torok@citrix.com>
Signed-off-by: Gabor Igloi <gabor.igloi@citrix.com>
edwintorok
force-pushed
the
feature/REQ477/probe
branch
from
4a51c13
to
1aed901
Compare
|
Closing, will reopen when probe branch is complete |
SMAPIv3 returns a list of configurations:
SMAPIv1 is unaffected, it always returns a
Rawresult.Has to be merged together with:
xapi-project/xapi-storage#74
xapi-project/xapi-storage-script#58
xapi-project/xen-api#3477
This is meant for discussion, we should merge only after the
xapi-storage-pluginsimplementation is done, and we've agreed how the final API should look like.In particular the SMAPIv3 plugin returns this type:
https://github.com/xapi-project/xapi-storage/blob/feature/REQ477/probe/generator/lib/control.ml#L59-L74
Should we make it return something more similar to the type here in xcp-idl? And what should we do with
extra_info, should we change the probed device_config type to: