From: "Livnat Peer" <lpeer(a)redhat.com&gt; To: "Saggi Mizrahi" <smizrahi(a)redhat.com&gt; Cc: vdsm-devel(a)lists.fedorahosted.org, engine-devel(a)ovirt.org Sent: Tuesday, January 24, 2012 12:43:39 PM Subject: Re: [Engine-devel] [RFC] New Connection Management API On 23/01/12 23:54, Saggi Mizrahi wrote: > I have begun work at changing how API clients can control storage > connections when interacting with VDSM. > > Currently there are 2 API calls: > connectStorageServer() - Will connect to the storage target if the > host is not already connected to it. > disconnectStorageServer() - Will disconnect from the storage target > if the host is connected to it. > > This API is very simple but is inappropriate when multiple clients > and flows try to access the same storage. > > This is currently solved by trying to synchronize things inside > rhevm. This is hard and convoluted. It also brings out issues with > other clients using the VDSM API. > > Another problem is error recovery. Currently ovirt-engine(OE) has > no way of monitoring the connections on all the hosts an if a > connection disappears it's OE's responsibility to reconnect. > > I suggest a different concept where VDSM 'manages' the connections. > VDSM receives a manage request with the connection information and > from that point forward VDSM will try to keep this connection > alive. If the connection fails VDSM will automatically try and > recover. > > Every manage request will also have a connection ID(CID). This CID > will be used when the same client asks to unamange the connection. > When multiple requests for manage are received to the same > connection they all have to have their own unique CID. By > internally mapping CIDs to actual connections VDSM can properly > disconnect when no CID is addressing the connection. This allows > each client and even each flow to have it's own CID effectively > eliminating connect\disconnect races. > > The change from (dis)connect to (un)manage also changes the > semantics of the calls significantly. > Whereas connectStorageServer would have returned when the storage > is either connected or failed to connect, manageStorageServer will > return once VDSM registered the CID. This means that the > connection might not be active immediately as the VDSM tries to > connect. The connection might remain down for a long time if the > storage target is down or is having issues. > > This allows for VDSM to receive the manage request even if the > storage is having issues and recover as soon as it's operational > without user intervention. > > In order for the client to query the current state of the > connections I propose getStorageConnectionList(). This will return > a mapping of CID to connection status. The status contains the > connection info (excluding credentials), whether the connection is > active, whether the connection is managed (unamanged connection > are returned with transient IDs), and, if the connection is down, > the last error information. > > The same actual connection can return multiple times, once for each > CID. > > For cases where an operation requires a connection to be active a > user can poll the status of the CID. The user can then choose to > poll for a certain amount of time or until an error appears in the > error field of the status. This will give you either a timeout or > a "try once" semantic depending on the flows needs. > > All connections that have been managed persist VDSM restart and > will be managed until a corresponding unmanage command has been > issued. > > There is no concept of temporary connections as "temporary" is flow > dependent and VDSM can't accommodate all interpretation of > "temporary". An ad-hoc mechanism can be build using the CID field. > For instance a client can manage a connection with > "ENGINE_FLOW101_CON1". If the flow got interrupted the client can > clean all IDs with certain flow IDs. > > I think this API gives safety, robustness, and implementation > freedom. > > > Nitty Gritty: > > manageStorageServer > =================== > Synopsis: > manageStorageServer(uri, connectionID): > > Parameters: > uri - a uri pointing to a storage target (eg: nfs://server:export, > iscsi://host/iqn;portal=1) > connectionID - string with any char except "/". > > Description: > Tells VDSM to start managing the connection. From this moment on > VDSM will try and have the connection available when needed. VDSM > will monitor the connection and will automatically reconnect on > failure. > Returns: > Success code if VDSM was able to manage the connection. > It usually just verifies that the arguments are sane and that the > CID is not already in use. > This doesn't mean the host is connected. > ---- > unmanageStorageServer > ===================== > Synopsis: > unmanageStorageServer(connectionID): > > Parameters: > connectionID - string with any char except "/". > > Descriptions: > Tells VDSM to stop managing the connection. VDSM will try and > disconnect for the storage target if this is the last CID > referencing the storage connection. > > Returns: > Success code if VDSM was able to unmanage the connection. > It will return an error if the CID is not registered with VDSM. > Disconnect failures are not reported. Active unmanaged connections > can be tracked with getStorageServerList() > ---- > getStorageServerList > ==================== > Synopsis: > getStorageServerList() > > Description: > Will return list of all managed and unmanaged connections. > Unmanaged connections have temporary IDs and are not guaranteed to > be consistent across calls. > > Results:VDSM was able to manage the connection. > It usually just verifies that the arguments are sane and that the > CID is not already in use. > This doesn't mean the host is connected. > ---- > unmanageStorageServer > ===================== > Synopsis: > unmanageStorageServer(connectionID): > > Parameters: > connectionID - string with any char except "/". > > Descriptions: > Tells VDSM to stop managing the connection. VDSM will try and > disconnect for the storage target if this is the last CID > referencing the storage connection. > > Returns: > Success code if VDSM was able to unmanage the connection. > It will return an error if the CID is not registered with VDSM. > Disconnect failures are not reported. Active unmanaged connections > can be tracked with getStorageServerList() > ---- > getStorageServerList > ==================== > Synopsis: > getStorageServerList() > > Description: > Will return list of all managed and unmanaged connections. > Unmanaged connections have temporary IDs and are not guaranteed to > be consistent across calls. > > Results: > A mapping between CIDs and the status. > example return value (Actual key names may differ) > > {'conA': {'connected': True, 'managed': True, 'lastError': 0, > 'connectionInfo': { > 'remotePath': 'server:/export > 'retrans': 3 > 'version': 4 > }} > 'iscsi_session_34': {'connected': False, 'managed': False, > 'lastError': 339, 'connectionIfno': { > 'hostname': 'dandylopn' > 'portal': 1}} > } > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel Hi Saggi, I see the added value in the above functionality and I think it is a needed functionality in VDSM. Your suggestion includes 2 concepts: - Persist connection - auto-reconnect on failures - Reference counting (with CID granularity)

Here are some comments: * Assuming you meant that the new API will be a replacement to the current API (based on previous chats we had on this topic)

I think you are missing a needed functionality to support non-persisted connection.

creating a storage domain is an example where it can be useful. The flow includes connecting the host to the storage server creating storage domain and disconnecting from the storage server.

Let's assume VDSM hangs while creating the storage domain any unmanageStorageServer will fail, the engine rolls back and tries to create the storage domain on another host, there is no reason for the host to reconnect to this storage server.

In the above flow i would use non-persist connection if I had one.

* In the suggested solution the connect will not initiate an immediate connect to the storage server instead it will register the connection as handled connection and will actually generate the connect as part of the managed connection mechanism.

I argue that this modeling is implementation driven which is wrong from the user perspective.

As a user I expect connect to actually initiate a connect action and that the return value should indicate if the connect succeeded, the way you modeled it the API will return true if you succeeded 'registering' the connect. You modeled the API to be asynchronous with no handler (task id) to monitor the results of the action, which requires polling

in the create storage domain flow which I really don't like. In addition you introduced a verb for monitoring the status of the connections alone I would like to be able to monitor it as part of the general host status and not have to poll on a new verb in addition to the current one. As part of solving the connection management flows in OE I am missing: - A way to clear all managed connections. use case: We move a host from one data center to another and we want the host to clear all the managed connections. we can ask for the list of managed connection and clear them but having clearAll is much easier.

- Handling a list of Ids in each API verb

- A verb which handles create storage domain and encapsulates the connect create and disconnect.

Thanks, Livnat

On 25/01/12 23:35, Saggi Mizrahi wrote: > <SNIP> > This is mail was getting way too long. > > About the clear all verb. > No. > Just loop, find the connections YOU OWN and clean them. Even though you don't want to support multiple clients to VDSM API doesn't mean the engine shouldn't behave like a proper citizen. > It's the same reason why VDSM tries and not mess system resources it didn't initiate. There is a big difference, VDSM living in hybrid mode with other workload on the host is a valid use case, having more than one concurrent manager for VDSM is not. Generating a disconnect request for each connection does not seem like the right API to me, again think on the simple flow of moving host from one data center to another, the engine needs to disconnect tall storage domains (each domain can have couple of connections associated with it). I am giving example from the engine use cases as it is the main user of VDSM ATM but I am sure it will be relevant to any other user of VDSM.

> > ------------------------ > > As I see it the only point of conflict is the so called non-peristed connections. > I will call them transient connections from now on. > > There are 2 user cases being discussed > 1. Wait until a connection is made, if it fails don't retry and automatically unmanage. > 2. If the called of the API forgets or fails to unmanage a connection. > Actually I was not discussing #2 at all. > Your suggestion as I understand it: > Transient connections are: > - Connection that VDSM will only try to connect to once and will not reconnect to in case of disconnect. yes > > My problem with this definition that it does not specify the "end of life" of the connection. > Meaning it solves only use case 1. since this is the only use case i had in mind, it is what i was looking for. > If all is well, and it usually is, VDSM will not invoke a disconnect. > So the caller would have to call unmanage if the connection succeeded at the end of the flow. agree. > Now, if you are already calling unmanage if connection succeeded you can just call it anyway. not exactly, an example I gave earlier on the thread was that VSDM hangs or have other error and the engine can not initiate unmanaged, instead let's assume the host is fenced (self-fence or external fence does not matter), in this scenario the engine will not issue unmanage. > > instead of doing: (with your suggestion) > ---------------- > manage > wait until succeeds or lastError has value > try: > do stuff > finally: > unmanage > > do: (with the canonical flow) > --- > manage > try: > wait until succeeds or lastError has value > do stuff > finally: > unmanage > > This is simpler to do than having another connection type. You are assuming the engine can communicate with VDSM and there are scenarios where it is not feasible. > > Now that we got that out of the way lets talk about the 2nd use case. Since I did not ask VDSM to clean after the (engine) user and you don't want to do it I am not sure we need to discuss this. If you insist we can start the discussion on who should implement the cleanup mechanism but I'm afraid I have no strong arguments for VDSM to do it, so I rather not go there ;) You dropped from the discussion my request for supporting list of connections for manage and unmanage verbs. > API client died in the middle of the operation and unmanage was never called. > > Your suggested definition means that unless there was a problem with the connection VDSM will still have this connection active. The engine will have to clean it anyway. > > The problem is, VDSM has no way of knowing that a client died, forgot or is thinking really hard and will continue on in about 2 minutes. > > Connections that live until they die is a hard to define and work with lifecycle. Solving this problem is theoretically simple. > > Have clients hold some sort of session token and force the client to update it at a specified interval. You could bind resources (like domains, VMs, connections) to that session token so when it expires VDSM auto cleans the resources. > > This kind of mechanism is out of the scope of this API change. Further more I think that this mechanism should sit in the engine since the session might actually contain resources from multiple hosts and resources that are not managed by VDSM. > > In GUI flows specifically the user might do actions that don't even touch the engine and forcing it to refresh the engine token is simpler then having it refresh the VDSM token. > > I understand that engine currently has no way of tracking a user session. This, as I said, is also true in the case of VDSM. We can start and argue about which project should implement the session semantics. But as I see it it's not relevant to the connection management API. _______________________________________________ vdsm-devel mailing list vdsm-devel(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel

On 01/26/2012 03:01 PM, Adam Litke wrote: > On Thu, Jan 26, 2012 at 12:22:42PM +0200, Livnat Peer wrote: >> On 25/01/12 23:35, Saggi Mizrahi wrote: >>> About the clear all verb. >>> No. >>> Just loop, find the connections YOU OWN and clean them. Even though you don't want to support multiple clients to VDSM API doesn't mean the engine shouldn't behave like a proper citizen. >>> It's the same reason why VDSM tries and not mess system resources it didn't initiate. >> >> There is a big difference, VDSM living in hybrid mode with other >> workload on the host is a valid use case, having more than one >> concurrent manager for VDSM is not. >> Generating a disconnect request for each connection does not seem like >> the right API to me, again think on the simple flow of moving host from >> one data center to another, the engine needs to disconnect tall storage >> domains (each domain can have couple of connections associated with it). >> >> I am giving example from the engine use cases as it is the main user of >> VDSM ATM but I am sure it will be relevant to any other user of VDSM. > I will speak up to represent other potential users of the VDSM API. My vote is > with Saggi here to keep the API simple and have an unmanage call that operates > on a single connection only. Every programming language has looping constructs > that make it easy to implement unmanageAll. Why clog up vdsm's API with an > extra function just to avoid writing a 'for' loop? A very good reason to have that kind of bulk operations (in general, maybe not in this case) is to reduce the number of network round trips and thus improve performance. The loop is very easy to write, and very expensive to execute.

_______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

<snip> Again trying to sum up and address all comments Clear all: ========== My opinions is still to not implement it. Even though it might generate a bit more traffic premature optimization is bad and there are other reasons we can improve VDSM command overhead without doing this. In any case this argument is redundant because my intention is (as Litke pointed out) is to have a lean API. and API call is something you have to support across versions, this call implemented in the engine is something that no one has to support and can change\evolve easily. As a rule, if an API call C and be implemented by doing A + B then C is redundant. List of connections as args: ============================ Sorry I forgot to respond about that. I'm not as strongly opposed to the idea as the other things you suggested. It'll just make implementing the persistence logic in VDSM significantly more complicated as I will have to commit multiple connection information to disk in an all or nothing mode. I can create a small sqlitedb to do that or do some directory tricks and exploit FS rename atomicity but I'd rather not.

The demands are not without base. I would like to keep the code simple under the hood in the price of a few more calls. You would like to make less calls and keep the code simpler on your side. There isn't a real way to settle this. If anyone on the list as pros and cons for either way I'd be happy to hear them. If no compelling arguments arise I will let Ayal call this one. Transient connections: ====================== The problem you are describing as I understand it is that VDSM did not respond and not that the API client did not respond. Again, this can happen for a number of reason, most of which VDSM might not be aware that there is actually a problem (network issues). This relates to the EOL policy. I agree we have to find a good way to define an automatic EOL for resources. I have made my suggestion. Out of the scope of the API. In the meantime cleaning stale connections is trivial and I have made it clear a previous email about how to go about it in a simple non intrusive way. Clean hosts on host connect, and on every poll if you find connections that you don't like. This should keep things squeaky clean. ----- Original Message ----- > From: "Livnat Peer" <lpeer(a)redhat.com&gt; > To: "Saggi Mizrahi" <smizrahi(a)redhat.com&gt; > Cc: vdsm-devel(a)lists.fedorahosted.org, engine-devel(a)ovirt.org > Sent: Thursday, January 26, 2012 5:22:42 AM > Subject: Re: [Engine-devel] [RFC] New Connection Management API > > On 25/01/12 23:35, Saggi Mizrahi wrote: > > <SNIP> > > This is mail was getting way too long. > > > > About the clear all verb. > > No. > > Just loop, find the connections YOU OWN and clean them. Even though > > you don't want to support multiple clients to VDSM API doesn't > > mean the engine shouldn't behave like a proper citizen. > > It's the same reason why VDSM tries and not mess system resources > > it didn't initiate. > > > There is a big difference, VDSM living in hybrid mode with other > workload on the host is a valid use case, having more than one > concurrent manager for VDSM is not. > Generating a disconnect request for each connection does not seem > like > the right API to me, again think on the simple flow of moving host > from > one data center to another, the engine needs to disconnect tall > storage > domains (each domain can have couple of connections associated with > it). > > I am giving example from the engine use cases as it is the main user > of > VDSM ATM but I am sure it will be relevant to any other user of VDSM. > > > > > ------------------------ > > > > As I see it the only point of conflict is the so called > > non-peristed connections. > > I will call them transient connections from now on. > > > > There are 2 user cases being discussed > > 1. Wait until a connection is made, if it fails don't retry and > > automatically unmanage. > > 2. If the called of the API forgets or fails to unmanage a > > connection. > > > > Actually I was not discussing #2 at all. > > > Your suggestion as I understand it: > > Transient connections are: > > - Connection that VDSM will only try to connect to once and > > will not reconnect to in case of disconnect. > > yes > > > > > My problem with this definition that it does not specify the "end > > of life" of the connection. > > Meaning it solves only use case 1. > > since this is the only use case i had in mind, it is what i was > looking for. > > > If all is well, and it usually is, VDSM will not invoke a > > disconnect. > > So the caller would have to call unmanage if the connection > > succeeded at the end of the flow. > > agree. > > > Now, if you are already calling unmanage if connection succeeded > > you can just call it anyway. > > not exactly, an example I gave earlier on the thread was that VSDM > hangs > or have other error and the engine can not initiate unmanaged, > instead > let's assume the host is fenced (self-fence or external fence does > not > matter), in this scenario the engine will not issue unmanage. > > > > > instead of doing: (with your suggestion) > > ---------------- > > manage > > wait until succeeds or lastError has value > > try: > > do stuff > > finally: > > unmanage > > > > do: (with the canonical flow) > > --- > > manage > > try: > > wait until succeeds or lastError has value > > do stuff > > finally: > > unmanage > > > > This is simpler to do than having another connection type. > > You are assuming the engine can communicate with VDSM and there are > scenarios where it is not feasible. > > > > > Now that we got that out of the way lets talk about the 2nd use > > case. > > Since I did not ask VDSM to clean after the (engine) user and you > don't > want to do it I am not sure we need to discuss this. > > If you insist we can start the discussion on who should implement the > cleanup mechanism but I'm afraid I have no strong arguments for VDSM > to > do it, so I rather not go there ;) > > > You dropped from the discussion my request for supporting list of > connections for manage and unmanage verbs. > > > API client died in the middle of the operation and unmanage was > > never called. > > > > Your suggested definition means that unless there was a problem > > with the connection VDSM will still have this connection active. > > The engine will have to clean it anyway. > > > > The problem is, VDSM has no way of knowing that a client died, > > forgot or is thinking really hard and will continue on in about 2 > > minutes. > > > > > Connections that live until they die is a hard to define and work > > with lifecycle. Solving this problem is theoretically simple. > > > > Have clients hold some sort of session token and force the client > > to update it at a specified interval. You could bind resources > > (like domains, VMs, connections) to that session token so when it > > expires VDSM auto cleans the resources. > > > > This kind of mechanism is out of the scope of this API change. > > Further more I think that this mechanism should sit in the engine > > since the session might actually contain resources from multiple > > hosts and resources that are not managed by VDSM. > > > > In GUI flows specifically the user might do actions that don't even > > touch the engine and forcing it to refresh the engine token is > > simpler then having it refresh the VDSM token. > > > > I understand that engine currently has no way of tracking a user > > session. This, as I said, is also true in the case of VDSM. We can > > start and argue about which project should implement the session > > semantics. But as I see it it's not relevant to the connection > > management API. > > _______________________________________________ vdsm-devel mailing list vdsm-devel(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel

----- Original Message ----- > From: "Adam Litke" <agl(a)us.ibm.com&gt; > To: "Saggi Mizrahi" <smizrahi(a)redhat.com&gt; > Cc: "Livnat Peer" <lpeer(a)redhat.com&gt;, engine-devel(a)ovirt.org, vdsm-devel(a)lists.fedorahosted.org > Sent: Thursday, January 26, 2012 1:58:40 PM > Subject: Re: [vdsm] [Engine-devel] [RFC] New Connection Management API > > On Thu, Jan 26, 2012 at 10:00:57AM -0500, Saggi Mizrahi wrote: >> <snip> >> Again trying to sum up and address all comments >> >> Clear all: >> ========== >> My opinions is still to not implement it. >> Even though it might generate a bit more traffic premature >> optimization is bad and there are other reasons we can improve >> VDSM command overhead without doing this. >> >> In any case this argument is redundant because my intention is (as >> Litke pointed out) is to have a lean API. >> and API call is something you have to support across versions, this >> call implemented in the engine is something that no one has to >> support and can change\evolve easily. >> >> As a rule, if an API call C and be implemented by doing A + B then >> C is redundant. >> >> List of connections as args: >> ============================ >> Sorry I forgot to respond about that. I'm not as strongly opposed >> to the idea as the other things you suggested. It'll just make >> implementing the persistence logic in VDSM significantly more >> complicated as I will have to commit multiple connection >> information to disk in an all or nothing mode. I can create a >> small sqlitedb to do that or do some directory tricks and exploit >> FS rename atomicity but I'd rather not. > > I would be strongly opposed to introducing a sqlite database into > vdsm just to > enable "convenience mode" for this API. Does the operation really > need to be > atomic? Why not just perform each connection sequentially and return > a list of > statuses? Is the only motivation for allowing a list of parameters > to reduce > the number of API calls between engine and vdsm)? If so, the same > argument > Saggi makes above applies here. I try and have VDSM expose APIs that are simple to predict. a command can either succeed or fail. The problem is not actually validating the connections. The problem is that once I concluded that they are all OK I need to persist to disk the information that will allow me to reconnect if VDSM happens to crash. If I naively save them one by one I could get in a state where only some of the connections persisted before the operation failed. So I have to somehow put all this in a transaction. I don't have to use sqlite. I could also put all the persistence information in a new dir for every call named <UUID>.tmp. Once I wrote everything down I rename the directory to just <UUID> and fsync it. This is guarantied by posix to be atomic. For unmanage, I move all the persistence information from the directories they sit in to a new dir named <UUID>. Rename it to a <UUDI>.tmp, fsync it and then remove it. This all just looks like more trouble then it's worth to me.

> >> The demands are not without base. I would like to keep the code >> simple under the hood in the price of a few more calls. You would >> like to make less calls and keep the code simpler on your side. >> There isn't a real way to settle this. >> If anyone on the list as pros and cons for either way I'd be happy >> to hear them. >> If no compelling arguments arise I will let Ayal call this one. >> >> Transient connections: >> ====================== >> The problem you are describing as I understand it is that VDSM did >> not respond and not that the API client did not respond. >> Again, this can happen for a number of reason, most of which VDSM >> might not be aware that there is actually a problem (network >> issues). >> >> This relates to the EOL policy. I agree we have to find a good way >> to define an automatic EOL for resources. I have made my >> suggestion. Out of the scope of the API. >> >> In the meantime cleaning stale connections is trivial and I have >> made it clear a previous email about how to go about it in a >> simple non intrusive way. Clean hosts on host connect, and on >> every poll if you find connections that you don't like. This >> should keep things squeaky clean. >> >> ----- Original Message ----- >>> From: "Livnat Peer" <lpeer(a)redhat.com&gt; >>> To: "Saggi Mizrahi" <smizrahi(a)redhat.com&gt; >>> Cc: vdsm-devel(a)lists.fedorahosted.org, engine-devel(a)ovirt.org >>> Sent: Thursday, January 26, 2012 5:22:42 AM >>> Subject: Re: [Engine-devel] [RFC] New Connection Management API >>> >>> On 25/01/12 23:35, Saggi Mizrahi wrote: >>>> <SNIP> >>>> This is mail was getting way too long. >>>> >>>> About the clear all verb. >>>> No. >>>> Just loop, find the connections YOU OWN and clean them. Even >>>> though >>>> you don't want to support multiple clients to VDSM API doesn't >>>> mean the engine shouldn't behave like a proper citizen. >>>> It's the same reason why VDSM tries and not mess system >>>> resources >>>> it didn't initiate. >>> >>> >>> There is a big difference, VDSM living in hybrid mode with other >>> workload on the host is a valid use case, having more than one >>> concurrent manager for VDSM is not. >>> Generating a disconnect request for each connection does not seem >>> like >>> the right API to me, again think on the simple flow of moving >>> host >>> from >>> one data center to another, the engine needs to disconnect tall >>> storage >>> domains (each domain can have couple of connections associated >>> with >>> it). >>> >>> I am giving example from the engine use cases as it is the main >>> user >>> of >>> VDSM ATM but I am sure it will be relevant to any other user of >>> VDSM. >>> >>>> >>>> ------------------------ >>>> >>>> As I see it the only point of conflict is the so called >>>> non-peristed connections. >>>> I will call them transient connections from now on. >>>> >>>> There are 2 user cases being discussed >>>> 1. Wait until a connection is made, if it fails don't retry and >>>> automatically unmanage. >>>> 2. If the called of the API forgets or fails to unmanage a >>>> connection. >>>> >>> >>> Actually I was not discussing #2 at all. >>> >>>> Your suggestion as I understand it: >>>> Transient connections are: >>>> - Connection that VDSM will only try to connect to once >>>> and >>>> will not reconnect to in case of disconnect. >>> >>> yes >>> >>>> >>>> My problem with this definition that it does not specify the >>>> "end >>>> of life" of the connection. >>>> Meaning it solves only use case 1. >>> >>> since this is the only use case i had in mind, it is what i was >>> looking for. >>> >>>> If all is well, and it usually is, VDSM will not invoke a >>>> disconnect. >>>> So the caller would have to call unmanage if the connection >>>> succeeded at the end of the flow. >>> >>> agree. >>> >>>> Now, if you are already calling unmanage if connection >>>> succeeded >>>> you can just call it anyway. >>> >>> not exactly, an example I gave earlier on the thread was that >>> VSDM >>> hangs >>> or have other error and the engine can not initiate unmanaged, >>> instead >>> let's assume the host is fenced (self-fence or external fence >>> does >>> not >>> matter), in this scenario the engine will not issue unmanage. >>> >>>> >>>> instead of doing: (with your suggestion) >>>> ---------------- >>>> manage >>>> wait until succeeds or lastError has value >>>> try: >>>> do stuff >>>> finally: >>>> unmanage >>>> >>>> do: (with the canonical flow) >>>> --- >>>> manage >>>> try: >>>> wait until succeeds or lastError has value >>>> do stuff >>>> finally: >>>> unmanage >>>> >>>> This is simpler to do than having another connection type. >>> >>> You are assuming the engine can communicate with VDSM and there >>> are >>> scenarios where it is not feasible. >>> >>>> >>>> Now that we got that out of the way lets talk about the 2nd use >>>> case. >>> >>> Since I did not ask VDSM to clean after the (engine) user and you >>> don't >>> want to do it I am not sure we need to discuss this. >>> >>> If you insist we can start the discussion on who should implement >>> the >>> cleanup mechanism but I'm afraid I have no strong arguments for >>> VDSM >>> to >>> do it, so I rather not go there ;) >>> >>> >>> You dropped from the discussion my request for supporting list of >>> connections for manage and unmanage verbs. >>> >>>> API client died in the middle of the operation and unmanage was >>>> never called. >>>> >>>> Your suggested definition means that unless there was a problem >>>> with the connection VDSM will still have this connection >>>> active. >>>> The engine will have to clean it anyway. >>>> >>>> The problem is, VDSM has no way of knowing that a client died, >>>> forgot or is thinking really hard and will continue on in about >>>> 2 >>>> minutes. >>> >>>> >>>> Connections that live until they die is a hard to define and >>>> work >>>> with lifecycle. Solving this problem is theoretically simple. >>>> >>>> Have clients hold some sort of session token and force the >>>> client >>>> to update it at a specified interval. You could bind resources >>>> (like domains, VMs, connections) to that session token so when >>>> it >>>> expires VDSM auto cleans the resources. >>>> >>>> This kind of mechanism is out of the scope of this API change. >>>> Further more I think that this mechanism should sit in the >>>> engine >>>> since the session might actually contain resources from >>>> multiple >>>> hosts and resources that are not managed by VDSM. >>>> >>>> In GUI flows specifically the user might do actions that don't >>>> even >>>> touch the engine and forcing it to refresh the engine token is >>>> simpler then having it refresh the VDSM token. >>>> >>>> I understand that engine currently has no way of tracking a >>>> user >>>> session. This, as I said, is also true in the case of VDSM. We >>>> can >>>> start and argue about which project should implement the >>>> session >>>> semantics. But as I see it it's not relevant to the connection >>>> management API. >>> >>> >> _______________________________________________ >> vdsm-devel mailing list >> vdsm-devel(a)lists.fedorahosted.org >> https://fedorahosted.org/mailman/listinfo/vdsm-devel > > -- > Adam Litke <agl(a)us.ibm.com&gt; > IBM Linux Technology Center > >

----- Original Message ----- > From: "Livnat Peer" <lpeer(a)redhat.com&gt; > To: "Saggi Mizrahi" <smizrahi(a)redhat.com&gt; > Cc: "Adam Litke" <agl(a)us.ibm.com&gt;, engine-devel(a)ovirt.org, vdsm-devel(a)lists.fedorahosted.org > Sent: Thursday, January 26, 2012 3:16:32 PM > Subject: Re: [vdsm] [Engine-devel] [RFC] New Connection Management API > > On 26/01/12 21:21, Saggi Mizrahi wrote: >> >> >> ----- Original Message ----- >>> From: "Adam Litke" <agl(a)us.ibm.com&gt; >>> To: "Saggi Mizrahi" <smizrahi(a)redhat.com&gt; >>> Cc: "Livnat Peer" <lpeer(a)redhat.com&gt;, engine-devel(a)ovirt.org, >>> vdsm-devel(a)lists.fedorahosted.org >>> Sent: Thursday, January 26, 2012 1:58:40 PM >>> Subject: Re: [vdsm] [Engine-devel] [RFC] New Connection Management >>> API >>> >>> On Thu, Jan 26, 2012 at 10:00:57AM -0500, Saggi Mizrahi wrote: >>>> <snip> >>>> Again trying to sum up and address all comments >>>> >>>> Clear all: >>>> ========== >>>> My opinions is still to not implement it. >>>> Even though it might generate a bit more traffic premature >>>> optimization is bad and there are other reasons we can improve >>>> VDSM command overhead without doing this. >>>> >>>> In any case this argument is redundant because my intention is >>>> (as >>>> Litke pointed out) is to have a lean API. >>>> and API call is something you have to support across versions, >>>> this >>>> call implemented in the engine is something that no one has to >>>> support and can change\evolve easily. >>>> >>>> As a rule, if an API call C and be implemented by doing A + B >>>> then >>>> C is redundant. >>>> >>>> List of connections as args: >>>> ============================ >>>> Sorry I forgot to respond about that. I'm not as strongly opposed >>>> to the idea as the other things you suggested. It'll just make >>>> implementing the persistence logic in VDSM significantly more >>>> complicated as I will have to commit multiple connection >>>> information to disk in an all or nothing mode. I can create a >>>> small sqlitedb to do that or do some directory tricks and exploit >>>> FS rename atomicity but I'd rather not. >>> >>> I would be strongly opposed to introducing a sqlite database into >>> vdsm just to >>> enable "convenience mode" for this API. Does the operation really >>> need to be >>> atomic? Why not just perform each connection sequentially and >>> return >>> a list of >>> statuses? Is the only motivation for allowing a list of parameters >>> to reduce >>> the number of API calls between engine and vdsm)? If so, the same >>> argument >>> Saggi makes above applies here. >> >> I try and have VDSM expose APIs that are simple to predict. a >> command can either succeed or fail. >> The problem is not actually validating the connections. The problem >> is that once I concluded that they are all OK I need to persist to >> disk the information that will allow me to reconnect if VDSM >> happens to crash. If I naively save them one by one I could get in >> a state where only some of the connections persisted before the >> operation failed. So I have to somehow put all this in a >> transaction. >> >> I don't have to use sqlite. I could also put all the persistence >> information in a new dir for every call named <UUID>.tmp. Once I >> wrote everything down I rename the directory to just <UUID> and >> fsync it. This is guarantied by posix to be atomic. For unmanage, >> I move all the persistence information from the directories they >> sit in to a new dir named <UUID>. Rename it to a <UUDI>.tmp, fsync >> it and then remove it. >> >> This all just looks like more trouble then it's worth to me. >> > > > I agree with Adam, I don't think the operation should be atomic, > having > only some of the connections persisted is a perfectly valid outcome > if > the API returns a list of statuses. What if it doesn't return at all? The only reasons that something will fail manage is if the URI is broken so I assume 99% of the issued manage commands will succeed. My problem is with VDSM crashing mid operation. The operation will appear to fail but when VDSM returns some of the connections persisted so it will reconnect. because the client's manage call failed it doesn't expect the CIDs to be in the list. This will cause ambiguity when finding an already registered CID at runtime.

> > >>> >>>> The demands are not without base. I would like to keep the code >>>> simple under the hood in the price of a few more calls. You would >>>> like to make less calls and keep the code simpler on your side. >>>> There isn't a real way to settle this. >>>> If anyone on the list as pros and cons for either way I'd be >>>> happy >>>> to hear them. >>>> If no compelling arguments arise I will let Ayal call this one. >>>> >>>> Transient connections: >>>> ====================== >>>> The problem you are describing as I understand it is that VDSM >>>> did >>>> not respond and not that the API client did not respond. >>>> Again, this can happen for a number of reason, most of which VDSM >>>> might not be aware that there is actually a problem (network >>>> issues). >>>> >>>> This relates to the EOL policy. I agree we have to find a good >>>> way >>>> to define an automatic EOL for resources. I have made my >>>> suggestion. Out of the scope of the API. >>>> >>>> In the meantime cleaning stale connections is trivial and I have >>>> made it clear a previous email about how to go about it in a >>>> simple non intrusive way. Clean hosts on host connect, and on >>>> every poll if you find connections that you don't like. This >>>> should keep things squeaky clean. >>>> >>>> ----- Original Message ----- >>>>> From: "Livnat Peer" <lpeer(a)redhat.com&gt; >>>>> To: "Saggi Mizrahi" <smizrahi(a)redhat.com&gt; >>>>> Cc: vdsm-devel(a)lists.fedorahosted.org, engine-devel(a)ovirt.org >>>>> Sent: Thursday, January 26, 2012 5:22:42 AM >>>>> Subject: Re: [Engine-devel] [RFC] New Connection Management API >>>>> >>>>> On 25/01/12 23:35, Saggi Mizrahi wrote: >>>>>> <SNIP> >>>>>> This is mail was getting way too long. >>>>>> >>>>>> About the clear all verb. >>>>>> No. >>>>>> Just loop, find the connections YOU OWN and clean them. Even >>>>>> though >>>>>> you don't want to support multiple clients to VDSM API doesn't >>>>>> mean the engine shouldn't behave like a proper citizen. >>>>>> It's the same reason why VDSM tries and not mess system >>>>>> resources >>>>>> it didn't initiate. >>>>> >>>>> >>>>> There is a big difference, VDSM living in hybrid mode with other >>>>> workload on the host is a valid use case, having more than one >>>>> concurrent manager for VDSM is not. >>>>> Generating a disconnect request for each connection does not >>>>> seem >>>>> like >>>>> the right API to me, again think on the simple flow of moving >>>>> host >>>>> from >>>>> one data center to another, the engine needs to disconnect tall >>>>> storage >>>>> domains (each domain can have couple of connections associated >>>>> with >>>>> it). >>>>> >>>>> I am giving example from the engine use cases as it is the main >>>>> user >>>>> of >>>>> VDSM ATM but I am sure it will be relevant to any other user of >>>>> VDSM. >>>>> >>>>>> >>>>>> ------------------------ >>>>>> >>>>>> As I see it the only point of conflict is the so called >>>>>> non-peristed connections. >>>>>> I will call them transient connections from now on. >>>>>> >>>>>> There are 2 user cases being discussed >>>>>> 1. Wait until a connection is made, if it fails don't retry and >>>>>> automatically unmanage. >>>>>> 2. If the called of the API forgets or fails to unmanage a >>>>>> connection. >>>>>> >>>>> >>>>> Actually I was not discussing #2 at all. >>>>> >>>>>> Your suggestion as I understand it: >>>>>> Transient connections are: >>>>>> - Connection that VDSM will only try to connect to once >>>>>> and >>>>>> will not reconnect to in case of disconnect. >>>>> >>>>> yes >>>>> >>>>>> >>>>>> My problem with this definition that it does not specify the >>>>>> "end >>>>>> of life" of the connection. >>>>>> Meaning it solves only use case 1. >>>>> >>>>> since this is the only use case i had in mind, it is what i was >>>>> looking for. >>>>> >>>>>> If all is well, and it usually is, VDSM will not invoke a >>>>>> disconnect. >>>>>> So the caller would have to call unmanage if the connection >>>>>> succeeded at the end of the flow. >>>>> >>>>> agree. >>>>> >>>>>> Now, if you are already calling unmanage if connection >>>>>> succeeded >>>>>> you can just call it anyway. >>>>> >>>>> not exactly, an example I gave earlier on the thread was that >>>>> VSDM >>>>> hangs >>>>> or have other error and the engine can not initiate unmanaged, >>>>> instead >>>>> let's assume the host is fenced (self-fence or external fence >>>>> does >>>>> not >>>>> matter), in this scenario the engine will not issue unmanage. >>>>> >>>>>> >>>>>> instead of doing: (with your suggestion) >>>>>> ---------------- >>>>>> manage >>>>>> wait until succeeds or lastError has value >>>>>> try: >>>>>> do stuff >>>>>> finally: >>>>>> unmanage >>>>>> >>>>>> do: (with the canonical flow) >>>>>> --- >>>>>> manage >>>>>> try: >>>>>> wait until succeeds or lastError has value >>>>>> do stuff >>>>>> finally: >>>>>> unmanage >>>>>> >>>>>> This is simpler to do than having another connection type. >>>>> >>>>> You are assuming the engine can communicate with VDSM and there >>>>> are >>>>> scenarios where it is not feasible. >>>>> >>>>>> >>>>>> Now that we got that out of the way lets talk about the 2nd use >>>>>> case. >>>>> >>>>> Since I did not ask VDSM to clean after the (engine) user and >>>>> you >>>>> don't >>>>> want to do it I am not sure we need to discuss this. >>>>> >>>>> If you insist we can start the discussion on who should >>>>> implement >>>>> the >>>>> cleanup mechanism but I'm afraid I have no strong arguments for >>>>> VDSM >>>>> to >>>>> do it, so I rather not go there ;) >>>>> >>>>> >>>>> You dropped from the discussion my request for supporting list >>>>> of >>>>> connections for manage and unmanage verbs. >>>>> >>>>>> API client died in the middle of the operation and unmanage was >>>>>> never called. >>>>>> >>>>>> Your suggested definition means that unless there was a problem >>>>>> with the connection VDSM will still have this connection >>>>>> active. >>>>>> The engine will have to clean it anyway. >>>>>> >>>>>> The problem is, VDSM has no way of knowing that a client died, >>>>>> forgot or is thinking really hard and will continue on in about >>>>>> 2 >>>>>> minutes. >>>>> >>>>>> >>>>>> Connections that live until they die is a hard to define and >>>>>> work >>>>>> with lifecycle. Solving this problem is theoretically simple. >>>>>> >>>>>> Have clients hold some sort of session token and force the >>>>>> client >>>>>> to update it at a specified interval. You could bind resources >>>>>> (like domains, VMs, connections) to that session token so when >>>>>> it >>>>>> expires VDSM auto cleans the resources. >>>>>> >>>>>> This kind of mechanism is out of the scope of this API change. >>>>>> Further more I think that this mechanism should sit in the >>>>>> engine >>>>>> since the session might actually contain resources from >>>>>> multiple >>>>>> hosts and resources that are not managed by VDSM. >>>>>> >>>>>> In GUI flows specifically the user might do actions that don't >>>>>> even >>>>>> touch the engine and forcing it to refresh the engine token is >>>>>> simpler then having it refresh the VDSM token. >>>>>> >>>>>> I understand that engine currently has no way of tracking a >>>>>> user >>>>>> session. This, as I said, is also true in the case of VDSM. We >>>>>> can >>>>>> start and argue about which project should implement the >>>>>> session >>>>>> semantics. But as I see it it's not relevant to the connection >>>>>> management API. >>>>> >>>>> >>>> _______________________________________________ >>>> vdsm-devel mailing list >>>> vdsm-devel(a)lists.fedorahosted.org >>>> https://fedorahosted.org/mailman/listinfo/vdsm-devel >>> >>> -- >>> Adam Litke <agl(a)us.ibm.com&gt; >>> IBM Linux Technology Center >>> >>> > >

From: "Livnat Peer" <lpeer(a)redhat.com&gt; To: "Saggi Mizrahi" <smizrahi(a)redhat.com&gt; Cc: vdsm-devel(a)lists.fedorahosted.org, engine-devel(a)ovirt.org Sent: Thursday, January 26, 2012 3:03:39 PM Subject: Re: [Engine-devel] [RFC] New Connection Management API On 26/01/12 17:00, Saggi Mizrahi wrote: > <snip> > Again trying to sum up and address all comments > > Clear all: > ========== > My opinions is still to not implement it. > Even though it might generate a bit more traffic premature > optimization is bad and there are other reasons we can improve > VDSM command overhead without doing this. > > In any case this argument is redundant because my intention is (as > Litke pointed out) is to have a lean API. > and API call is something you have to support across versions, this > call implemented in the engine is something that no one has to > support and can change\evolve easily. > > As a rule, if an API call C and be implemented by doing A + B then > C is redundant. I disagree with the above statement, exposing a bulk of operations in a single API call is very common and not considered redundant.

> > List of connections as args: > ============================ > Sorry I forgot to respond about that. I'm not as strongly opposed > to the idea as the other things you suggested. It'll just make > implementing the persistence logic in VDSM significantly more > complicated as I will have to commit multiple connection > information to disk in an all or nothing mode. I can create a > small sqlitedb to do that or do some directory tricks and exploit > FS rename atomicity but I'd rather not. > > The demands are not without base. I would like to keep the code > simple under the hood in the price of a few more calls. You would > like to make less calls and keep the code simpler on your side. > There isn't a real way to settle this. It is not about keeping the code simple (writing a loop is simple as well), it is about redundant round trips.

> If anyone on the list as pros and cons for either way I'd be happy > to hear them. > If no compelling arguments arise I will let Ayal call this one. > > Transient connections: > ====================== > The problem you are describing as I understand it is that VDSM did > not respond and not that the API client did not respond. > Again, this can happen for a number of reason, most of which VDSM > might not be aware that there is actually a problem (network > issues). > > This relates to the EOL policy. I agree we have to find a good way > to define an automatic EOL for resources. I have made my > suggestion. Out of the scope of the API. > > In the meantime cleaning stale connections is trivial and I have > made it clear a previous email about how to go about it in a > simple non intrusive way. Clean hosts on host connect, and on > every poll if you find connections that you don't like. This > should keep things squeaky clean. I have no additional input on this.

I truly appreciate your effort for modeling clean and simple API, but at the end of the day if the users of the API don't think it is clean and simple you missed your goal.

> > ----- Original Message ----- >> From: "Livnat Peer" <lpeer(a)redhat.com&gt; >> To: "Saggi Mizrahi" <smizrahi(a)redhat.com&gt; >> Cc: vdsm-devel(a)lists.fedorahosted.org, engine-devel(a)ovirt.org >> Sent: Thursday, January 26, 2012 5:22:42 AM >> Subject: Re: [Engine-devel] [RFC] New Connection Management API >> >> On 25/01/12 23:35, Saggi Mizrahi wrote: >>> <SNIP> >>> This is mail was getting way too long. >>> >>> About the clear all verb. >>> No. >>> Just loop, find the connections YOU OWN and clean them. Even >>> though >>> you don't want to support multiple clients to VDSM API doesn't >>> mean the engine shouldn't behave like a proper citizen. >>> It's the same reason why VDSM tries and not mess system resources >>> it didn't initiate. >> >> >> There is a big difference, VDSM living in hybrid mode with other >> workload on the host is a valid use case, having more than one >> concurrent manager for VDSM is not. >> Generating a disconnect request for each connection does not seem >> like >> the right API to me, again think on the simple flow of moving host >> from >> one data center to another, the engine needs to disconnect tall >> storage >> domains (each domain can have couple of connections associated >> with >> it). >> >> I am giving example from the engine use cases as it is the main >> user >> of >> VDSM ATM but I am sure it will be relevant to any other user of >> VDSM. >> >>> >>> ------------------------ >>> >>> As I see it the only point of conflict is the so called >>> non-peristed connections. >>> I will call them transient connections from now on. >>> >>> There are 2 user cases being discussed >>> 1. Wait until a connection is made, if it fails don't retry and >>> automatically unmanage. >>> 2. If the called of the API forgets or fails to unmanage a >>> connection. >>> >> >> Actually I was not discussing #2 at all. >> >>> Your suggestion as I understand it: >>> Transient connections are: >>> - Connection that VDSM will only try to connect to once and >>> will not reconnect to in case of disconnect. >> >> yes >> >>> >>> My problem with this definition that it does not specify the "end >>> of life" of the connection. >>> Meaning it solves only use case 1. >> >> since this is the only use case i had in mind, it is what i was >> looking for. >> >>> If all is well, and it usually is, VDSM will not invoke a >>> disconnect. >>> So the caller would have to call unmanage if the connection >>> succeeded at the end of the flow. >> >> agree. >> >>> Now, if you are already calling unmanage if connection succeeded >>> you can just call it anyway. >> >> not exactly, an example I gave earlier on the thread was that VSDM >> hangs >> or have other error and the engine can not initiate unmanaged, >> instead >> let's assume the host is fenced (self-fence or external fence does >> not >> matter), in this scenario the engine will not issue unmanage. >> >>> >>> instead of doing: (with your suggestion) >>> ---------------- >>> manage >>> wait until succeeds or lastError has value >>> try: >>> do stuff >>> finally: >>> unmanage >>> >>> do: (with the canonical flow) >>> --- >>> manage >>> try: >>> wait until succeeds or lastError has value >>> do stuff >>> finally: >>> unmanage >>> >>> This is simpler to do than having another connection type. >> >> You are assuming the engine can communicate with VDSM and there >> are >> scenarios where it is not feasible. >> >>> >>> Now that we got that out of the way lets talk about the 2nd use >>> case. >> >> Since I did not ask VDSM to clean after the (engine) user and you >> don't >> want to do it I am not sure we need to discuss this. >> >> If you insist we can start the discussion on who should implement >> the >> cleanup mechanism but I'm afraid I have no strong arguments for >> VDSM >> to >> do it, so I rather not go there ;) >> >> >> You dropped from the discussion my request for supporting list of >> connections for manage and unmanage verbs. >> >>> API client died in the middle of the operation and unmanage was >>> never called. >>> >>> Your suggested definition means that unless there was a problem >>> with the connection VDSM will still have this connection active. >>> The engine will have to clean it anyway. >>> >>> The problem is, VDSM has no way of knowing that a client died, >>> forgot or is thinking really hard and will continue on in about 2 >>> minutes. >> >>> >>> Connections that live until they die is a hard to define and work >>> with lifecycle. Solving this problem is theoretically simple. >>> >>> Have clients hold some sort of session token and force the client >>> to update it at a specified interval. You could bind resources >>> (like domains, VMs, connections) to that session token so when it >>> expires VDSM auto cleans the resources. >>> >>> This kind of mechanism is out of the scope of this API change. >>> Further more I think that this mechanism should sit in the engine >>> since the session might actually contain resources from multiple >>> hosts and resources that are not managed by VDSM. >>> >>> In GUI flows specifically the user might do actions that don't >>> even >>> touch the engine and forcing it to refresh the engine token is >>> simpler then having it refresh the VDSM token. >>> >>> I understand that engine currently has no way of tracking a user >>> session. This, as I said, is also true in the case of VDSM. We >>> can >>> start and argue about which project should implement the session >>> semantics. But as I see it it's not relevant to the connection >>> management API. >> >>

On Mon, Jan 23, 2012 at 04:54:10PM -0500, Saggi Mizrahi wrote: > Nitty Gritty: This seems like a good API but I have some suggestions with respect to API naming: > manageStorageServer > =================== Could we name this manageStorageConnection or manageStorageServerConnection? Manage storage server is confusing because it implies you are managing the server itself (ie. server configuration, NFS exports, reboot, etc).

> Synopsis: > manageStorageServer(uri, connectionID): > > Parameters: > uri - a uri pointing to a storage target (eg: nfs://server:export, iscsi://host/iqn;portal=1) > connectionID - string with any char except "/". > > Description: > Tells VDSM to start managing the connection. From this moment on VDSM will try and have the connection available when needed. VDSM will monitor the connection and will automatically reconnect on failure. > Returns: > Success code if VDSM was able to manage the connection. > It usually just verifies that the arguments are sane and that the CID is not already in use. > This doesn't mean the host is connected. > ---- > unmanageStorageServer > ===================== To match above: unmanageStorageConnection or unmanageStorageServerConnection

> Synopsis: > unmanageStorageServer(connectionID): > > Parameters: > connectionID - string with any char except "/". > > Descriptions: > Tells VDSM to stop managing the connection. VDSM will try and disconnect for the storage target if this is the last CID referencing the storage connection. > > Returns: > Success code if VDSM was able to unmanage the connection. > It will return an error if the CID is not registered with VDSM. Disconnect failures are not reported. Active unmanaged connections can be tracked with getStorageServerList() > ---- > getStorageServerList > ==================== getStorageConnectionList or getStorageServerConnectionList

> Synopsis: > getStorageServerList() > > Description: > Will return list of all managed and unmanaged connections. Unmanaged connections have temporary IDs and are not guaranteed to be consistent across calls. > > Results:VDSM was able to manage the connection. > It usually just verifies that the arguments are sane and that the CID is not already in use. > This doesn't mean the host is connected. > ---- > unmanageStorageServer > ===================== > Synopsis: > unmanageStorageServer(connectionID): > > Parameters: > connectionID - string with any char except "/". > > Descriptions: > Tells VDSM to stop managing the connection. VDSM will try and disconnect for the storage target if this is the last CID referencing the storage connection. > > Returns: > Success code if VDSM was able to unmanage the connection. > It will return an error if the CID is not registered with VDSM. Disconnect failures are not reported. Active unmanaged connections can be tracked with getStorageServerList() > ---- > getStorageServerList > ==================== > Synopsis: > getStorageServerList() > > Description: > Will return list of all managed and unmanaged connections. Unmanaged connections have temporary IDs and are not guaranteed to be consistent across calls. > > Results: > A mapping between CIDs and the status. > example return value (Actual key names may differ) > > {'conA': {'connected': True, 'managed': True, 'lastError': 0, 'connectionInfo': { > 'remotePath': 'server:/export > 'retrans': 3 > 'version': 4 > }} > 'iscsi_session_34': {'connected': False, 'managed': False, 'lastError': 339, 'connectionIfno': { > 'hostname': 'dandylopn' > 'portal': 1}} > } > _______________________________________________ > vdsm-devel mailing list > vdsm-devel(a)lists.fedorahosted.org > https://fedorahosted.org/mailman/listinfo/vdsm-devel

top posting since there was a long thread on this anyway. some questions/comments: 1. about the CIDs - it sounds like the engine needs to persist this info, so it can resume normally in case of a failure/restart (this is different than today, when the persisted info is the connection details, rather than some generated identifier)?

2. sounds like the engine needs to block in certain cases after a manageConnection to make sure it is there and alive before doing an operation. this means now engine has to check a host has all relevant connections online before choosing it as a target for live migration even for a regular VM (all disks on a storage domain).

worse/uglier (well, imho), in case of a disk based on a direct LUN, the engine needs to actively connect the target host, poll till it's up, and only then live migrate (would be much nicer if vdsm migration protocol would have taken care of this manageConnection call (preserving the CID?) 3. in unmanageStorageServer(connectionID) below you finish with "Returns: Success code if VDSM was able to unmanage the connection. It will return an error if the CID is not registered with VDSM. Disconnect failures are not reported. Active unmanaged connections can be tracked with getStorageServerList()" it is not clear if vdsm will retry to disconnect, and how races between those retries and new manage connection requests will be handled. if the connection only becomes unmanaged, there is no way to track and clean it up (engine is not supposed to touch the unmanaged connections) 4. I don't think we handle this today, but while we are planning for the future - what if the host needs one of the connections to exist regardless of engine for another need (say it does boot from network from same iscsi target - this is an unmanaged connection which you will disconnect based on the CID refcount concept). i.e., what happens if the host has an unmanaged connection, which becomes a managed one. solving this probably means when adding a connection, need to add an unmanaged_existed_before CID for refcount? On 01/23/2012 11:54 PM, Saggi Mizrahi wrote: > I have begun work at changing how API clients can control storage > connections when interacting with VDSM. > > Currently there are 2 API calls: > connectStorageServer() - Will connect to the storage target if the > host is not already connected to it. > disconnectStorageServer() - Will disconnect from the storage target if > the host is connected to it. > > This API is very simple but is inappropriate when multiple clients and > flows try to access the same storage. > > This is currently solved by trying to synchronize things inside rhevm. > This is hard and convoluted. It also brings out issues with other > clients using the VDSM API. > > Another problem is error recovery. Currently ovirt-engine(OE) has no > way of monitoring the connections on all the hosts an if a connection > disappears it's OE's responsibility to reconnect. > > I suggest a different concept where VDSM 'manages' the connections. > VDSM receives a manage request with the connection information and > from that point forward VDSM will try to keep this connection alive. > If the connection fails VDSM will automatically try and recover. > > Every manage request will also have a connection ID(CID). This CID > will be used when the same client asks to unamange the connection. > When multiple requests for manage are received to the same connection > they all have to have their own unique CID. By internally mapping CIDs > to actual connections VDSM can properly disconnect when no CID is > addressing the connection. This allows each client and even each flow > to have it's own CID effectively eliminating connect\disconnect races. > > The change from (dis)connect to (un)manage also changes the semantics > of the calls significantly. > Whereas connectStorageServer would have returned when the storage is > either connected or failed to connect, manageStorageServer will return > once VDSM registered the CID. This means that the connection might not > be active immediately as the VDSM tries to connect. The connection > might remain down for a long time if the storage target is down or is > having issues. > > This allows for VDSM to receive the manage request even if the storage > is having issues and recover as soon as it's operational without user > intervention. > > In order for the client to query the current state of the connections > I propose getStorageConnectionList(). This will return a mapping of > CID to connection status. The status contains the connection info > (excluding credentials), whether the connection is active, whether the > connection is managed (unamanged connection are returned with > transient IDs), and, if the connection is down, the last error > information. > > The same actual connection can return multiple times, once for each CID. > > For cases where an operation requires a connection to be active a user > can poll the status of the CID. The user can then choose to poll for a > certain amount of time or until an error appears in the error field of > the status. This will give you either a timeout or a "try once" > semantic depending on the flows needs. > > All connections that have been managed persist VDSM restart and will > be managed until a corresponding unmanage command has been issued. > > There is no concept of temporary connections as "temporary" is flow > dependent and VDSM can't accommodate all interpretation of > "temporary". An ad-hoc mechanism can be build using the CID field. For > instance a client can manage a connection with "ENGINE_FLOW101_CON1". > If the flow got interrupted the client can clean all IDs with certain > flow IDs. > > I think this API gives safety, robustness, and implementation freedom. > > > Nitty Gritty: > > manageStorageServer > =================== > Synopsis: > manageStorageServer(uri, connectionID): > > Parameters: > uri - a uri pointing to a storage target (eg: nfs://server:export, > iscsi://host/iqn;portal=1) > connectionID - string with any char except "/". > > Description: > Tells VDSM to start managing the connection. From this moment on VDSM > will try and have the connection available when needed. VDSM will > monitor the connection and will automatically reconnect on failure. > Returns: > Success code if VDSM was able to manage the connection. > It usually just verifies that the arguments are sane and that the CID > is not already in use. > This doesn't mean the host is connected. > ---- > unmanageStorageServer > ===================== > Synopsis: > unmanageStorageServer(connectionID): > > Parameters: > connectionID - string with any char except "/". > > Descriptions: > Tells VDSM to stop managing the connection. VDSM will try and > disconnect for the storage target if this is the last CID referencing > the storage connection. > > Returns: > Success code if VDSM was able to unmanage the connection. > It will return an error if the CID is not registered with VDSM. > Disconnect failures are not reported. Active unmanaged connections can > be tracked with getStorageServerList() > ---- > getStorageServerList > ==================== > Synopsis: > getStorageServerList() > > Description: > Will return list of all managed and unmanaged connections. Unmanaged > connections have temporary IDs and are not guaranteed to be consistent > across calls. > > Results:VDSM was able to manage the connection. > It usually just verifies that the arguments are sane and that the CID > is not already in use. > This doesn't mean the host is connected. > ---- > unmanageStorageServer > ===================== > Synopsis: > unmanageStorageServer(connectionID): > > Parameters: > connectionID - string with any char except "/". > > Descriptions: > Tells VDSM to stop managing the connection. VDSM will try and > disconnect for the storage target if this is the last CID referencing > the storage connection. > > Returns: > Success code if VDSM was able to unmanage the connection. > It will return an error if the CID is not registered with VDSM. > Disconnect failures are not reported. Active unmanaged connections can > be tracked with getStorageServerList() > ---- > getStorageServerList > ==================== > Synopsis: > getStorageServerList() > > Description: > Will return list of all managed and unmanaged connections. Unmanaged > connections have temporary IDs and are not guaranteed to be consistent > across calls. > > Results: > A mapping between CIDs and the status. > example return value (Actual key names may differ) > > {'conA': {'connected': True, 'managed': True, 'lastError': 0, > 'connectionInfo': { > 'remotePath': 'server:/export > 'retrans': 3 > 'version': 4 > }} > 'iscsi_session_34': {'connected': False, 'managed': False, > 'lastError': 339, 'connectionIfno': { > 'hostname': 'dandylopn' > 'portal': 1}} > } > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel