[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [camp] implementation question - modifying a "live" plan resource
-Anish -- On 12/17/14, 9:27 AM, Gilbert Pilz wrote:
I confess I hadn’t thought that modifying a plan resource might change a running application. My assumption has always been that, if you wanted to change a running application, you should operate on the tree of resources rooted in the assembly resource for that application. For example, if you wanted to move a web application to a different container, you would modify the appropriate “related_links” Link in the component resource corresponding to that web application. If a provider doesn’t allow you to do this sort of thing, it would indicate this with some 4** error code and an appropriate message. I’m a bit uncomfortable with the notion that modifying a plan might affect any running applications that are based on that plan. ~ gp On Dec 17, 2014, at 12:13 PM, Anish Karmarkar <anish.karmarkar@oracle.com> wrote:I think this should be left to the implementation. At most we can figure out and include an interoperable way to convey to the client what the implementation does via metadata. The reason I think it is implementation dependent is the following: Consider two implementations A and B. A has the ability to change the config of a running application on the fly, B cannot. In case of B, you have to stop the application, reconfig and restart. A can successfully process such a request to change the plan resource, change the running app, and respond with 2xx, keeping the running app and the plan always in sync. B might reject it asking you to stop the app first. As to the issue of plan cloning we have that issue regardless of the scenario that is outlined in Gil's email. Assembly resource has a pointer to the plan resource, keeping them out of sync doesn't make much sense. So, if you want to create two assemblies that have different (but similar) config they must point to different plan resources. This is independent of whether there is currently a running application (and therefore an assembly resource) or not. Cloning shouldn't be that difficult. Once you have the plan file (if you don't, you can always extract an existing plan resource via GET), you can modify the plan file locally and create a new plan resource OR you can post the unmodified plan file, creating a new plan resource and then modify it. -Anish -- On 12/17/14, 7:20 AM, Gilbert Pilz wrote:I was curious what members of the TC thought about the following question. Suppose that, one way or another, you have created a plan resource and assembly resource that refers to the plan resource (i.e. there is a running application based on a particular plan). Now you try to modify some attributes of the plan resource using either PUT + select_attr or PATCH. What should the provider do? It seems to me that there are three reasonable choices: 1.) Process the request as per usual. 2.) Fail the request with an HTTP 409 (Conflict). 3.) Clone the plan, process the request on this new plan, and return a reference to the new plan. (3) is a little far-fetched and, in any case, can be done manually by the user. The problem with (1) is that it undermines the ability to determine the exact plan that created an application. Even if you don’t remember modifying the plan you can't be certain that nobody else modified the plan (in situations where multiple people are allowed to work on the same resource) or that you didn’t modify the plan then forget that you did that. Basically it becomes a lot more difficult (and, in some pathological situations, impossible) to determine the exact plan that created an application. The problem with (2) is that it makes creating multiple, differently configured, applications from the same plan resource more cumbersome. You have to manually execute (3) from the user tool. So what to people think? Is preserving the guarantee of the assembly —> plan relationship worth the burden of requiring users to manually clone plan resources if they want to create multiple applications with slightly different configurations? ~ gp --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]