Re: [camp] implementation question - modifying a "live" plan resource

[Alex Heneveld <alex.heneveld@cloudsoftcorp.com>]

brooklyn's analogous behaviour is (2) fail, unless you:
* specify a "force" option, or
* specify a different version number for the plan

this seems to work well.  maintaining versions of plans is very useful 
(as derek has said -- and we use semver with osgi isoloation under the 
covers) but also confusing as the plan version is different to the 
software version of the components it references, not to mention the 
version(s) of the camp spec it conforms to (which we've not implemented).

--a


On 17/12/2014 17:13, Anish Karmarkar 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