OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Draft Minutes 25th September 2013


Minutes 24th September 2013

Meeting Attendees

US Department of Defense (DoD)	Michael Behrens			Voting Member
Software AG, Inc.					Bhaskar Reddy Byreddy	Voting Member
Oracle							Mark Carlson			Voting Member
Fujitsu Limited					Jacques Durand			Voting Member
Cloudsoft Corporation Limited		Alex Heneveld			Voting Member
Oracle							Ashok Malhotra			Voting Member
Rackspace Hosting, Inc.			Adrian Otto				Secretary
Vnomic							Derek Palma				Voting Member
Oracle							Gilbert Pilz				Voting Member
Red Hat							Krishna Raman			Voting Member
Fujitsu Limited					Tom Rutt				Voting Member
Software AG, Inc.					Prasad Yendluri			Voting Member

Intro:
 
  Scribe: Gilbert Pilz
  Roll: Attendees listed above. 12 of 14 voting members present. Meeting is quorate.
  Draft agenda accepted: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201309/msg00149.html
 
Topic: Draft Minutes
 
   18th  September 2013: 
	https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201309/msg00099.html
	Motion: m: Gil, s: Ashok
	No objections minutes approved

Action Items:

	Jacques Durand: Coordinate Editing team meeting to discuss the challenges document referenced in CAMP-83.
	Gilbert Pilz: Get input from Martin (email) on what publications he thinks we should release between our PRs.

Topic: Timeline 
	https://www.oasis-open.org/apps/org/workgroup/camp/document.php?document_id=50034
	Gil: Should we release a CSD before starting the second PR? Decision: Revisit next week. -> Action Item to consult Martin for input.

	Jacques: TA document needs purely editorial stuff (correct front page, etc.), technical content is good to go
        
Editing Team Update:

	WD24: 
	https://www.oasis-open.org/apps/org/workgroup/camp/download.php/50751/camp-spec-v1.1-wd24.doc
	Gil summarizes the changes. "Include resolutions for 51 and 112. Miscellaneous editorial cleanups."

	Transcript:
		Gil Pilz (Oracle): Gil: are we going to do any interim CDs between now and the next PR?
		Gil Pilz (Oracle): Adrian: we haven't discussed this at all
		Gil Pilz (Oracle): ? we need to figure out how much work we have to do to address the PRs
		Gil Pilz (Oracle): ? this could be a rather tedious process
		Gil Pilz (Oracle): Gil: experience has taught us that it isn't a good idea to build up too many issues in the "Resolved" state
		Gil Pilz (Oracle): ? each of these has to be cross-checked to make sure it is actually in the draft
		Gil Pilz (Oracle): ? publishing a CD takes the pressure off
		Gil Pilz (Oracle): Adrian: take this up when Martin is back (Action item)

New Issues:

	PR comments:  CAMP-113 through CAMP-141

	Transcript:
		Gil Pilz (Oracle): Adrian: we have a number of PR issues
		Gil Pilz (Oracle): ? last time we were in this spot we processed these in a single motion
		Gil Pilz (Oracle): Gil: there was one issue that I thought you didn't want to open?
		Gil Pilz (Oracle): ? we could just open it now, and close it later
		Gil Pilz (Oracle): Adrian: we should review these quickly so people get an idea of what is in them
		Gil Pilz (Oracle): (reviews issue)
		Gil Pilz (Oracle): Adrian: CAMP-126 is problematic as we have specific reasons for not using YAML 1.2

	Motion: m: Gil s: Adrian Move to close CAMP-126 with no action and inform reporter of our reasoning
	No Discussion
	No Objections
	Resolution: CAMP-126 closed

	Motion: m: Gil s: Jacques open issues CAMP-113 to CAMP-125, and CAMP-127 to CAMP-141 as P2 issues
	No Discussion
	No Objections
	Resolution: open issues CAMP-113 to CAMP-125, and CAMP-127 to CAMP-141 as P2 issues

Topic:  Issue Discussion

	Jacques: would like to review CAMP-83
	Adrian: we made a decision to have the editors process that (Action Item for Jacques to organize Editor's meeting)

	CAMP-31 - State change mechanism is unclear
	https://tools.oasis-open.org/issues/browse/CAMP-31
	Proposal In Jira (https://www.oasis-open.org/apps/org/workgroup/camp/download.php/50819/camp-spec-v1.1-issue-31-v1.doc)

	Transcript:

	Gil Pilz (Oracle): Jacques: what about the state of the Assembly?
	Gil Pilz (Oracle): Gil: CAMP doesn't know anything about that. It's a matter of application semantics. One application could be fine if some of its components are not running, whereas another application may not. What is the state of an Assembly in which some of its components are RUNNING and others are STOPPED.
	Gil Pilz (Oracle): Jacques: People are going to expect to see the "state" at the Assembly level.
	Gil Pilz (Oracle): Adrian: Assemblies should have some form of state. We may need more values for Assembly than for *Component.
	Gil Pilz (Oracle): Alex: I kind of understand the motivation for wanting state values. But if we say that Providers assign the semantics and can extend these values, we are defeating the purpose of having state in the first place. We have to ask ourselves what we are trying to enable.
	Gil Pilz (Oracle): ? I think we are trying to allow the Consumer to detect the "happy path" in which everything is working. Anything other than that gets into semantics. We need to attach state to Assembly and use a simple boolean "is it running or not?".
	Adrian Otto (Rackspace): I suggest that state is used for giving a Consumer (Client) an indication of when an application is ready to begin servicing its clients
	Gil Pilz (Oracle): ? Alternatively we could just pass and have implementations handle this in an extension.
	Gil Pilz (Oracle): Ashok: If we want to be stricly RESTful, we shouldn't use operation URIs and only change the state of the resource by changing the value of an attribute.
	Gil Pilz (Oracle): Adrian: HTTP PATCH?
	Gil Pilz (Oracle): Ashok: Yes.
	Gil Pilz (Oracle): Adrian: Mostly we are trying to convey to Consumers what the status of their application is. It seems unlikely that a Consumer will want to change the status of the application - more likely is that the system will change the status.
	Gil Pilz (Oracle): Ashok: We have operation URIs. Using them alters the status, right?
	Gil Pilz (Oracle): Adrian: They may (e.g. suspend/resume). If you create a new application, you would wait until its status became "READY".
	Gil Pilz (Oracle): Adrian: Most of the operations in a cloud APIs are asynchronous. Generally you get back an response immediately and poll the resource to see when the operation has taken effect.
	Gil Pilz (Oracle): Tom: Gil said we don't want to mix operations and setting status. Do we have any standard operations?
	Gil Pilz (Oracle): Alex: We deliberately did not propose specific operations.
	Gil Pilz (Oracle): Alex: Hard to define a set of operations that every component must support. That gets into defining specific component types.
	Gil Pilz (Oracle): Mark: I think we have an interoperable way of doing this by updating the state value.
	Alex Heneveld: Ashok - POSTing to an operation endpoint is a valid REST way to do things as it is how you create (kick off) an operation
	Gil Pilz (Oracle): Mark: Text has a lot of "cans" - would like to see SHALL, SHOULD, or MUST
	Alex Heneveld: PUT/PATCH to a field is also a valid REST way to do things but more common for CRUD activities, not potentially long-running operations
	Gil Pilz (Oracle): Ashok: I assumed that you had to use operations.
	Gil Pilz (Oracle): Gil: Ashok understand my proposal correctly.
	Gil Pilz (Oracle): (general discussion)
	Alex Heneveld: PUT/PATCH is a very poor way to talk about operations which commonly will take parameters
	Gil Pilz (Oracle): Mark: Combine new state values with existing 6.13
	Alex Heneveld: we already have interoperable create (start) and delete (stop)
	Gil Pilz (Oracle): Alex: It sounds like you are trying to introduce interoperability where it is not needed.
	Gil Pilz (Oracle): ? We already have a way of interoperably starting and stopping components.
	Gil Pilz (Oracle): ? After that things get fuzzy very quickly.
	Gil Pilz (Oracle): ? It all depends on the semantics of the component that is being managed.
	Gil Pilz (Oracle): ? Hopefully we will see some operations reach consensus and we can fold them into the next version of the spec.
	Adrian Otto (Rackspace): you could use READY to indicate both RUNNING and COMPLETED
	Gil Pilz (Oracle): Mark: Would like to see an interoperable way of stopping a component, but leave it around (i.e. don't stop by deleting)
	Alex Heneveld: Mark what should this "interoperable stop" do?  snapshot or kill process or kill -9 or undeploy an appserver or pause an appserver ... ?  it quickly stops being interoperable in my experience.
	Gil Pilz (Oracle): Jacques: I've never had much sympathy for the state change mechanism in 6.13. Seems like we are shoehorning the REST religion into complex cases that it was never meant to handle.
	Gil Pilz (Oracle): ? For example, what if I try to change the state to "COMPLETED" for components that don't support that state?
	Alex Heneveld: only things which are relatively uncontroversial are "start" and "destroy"
	Gil Pilz (Oracle): Ashok: Mark, you would get into a COMPLETED state when it either ends or it has an error and stops.
	Gil Pilz (Oracle): ? The Platform will change the state of the component behind the scenes.
	Gil Pilz (Oracle): ? Alex, how do you stop and start?
	Gil Pilz (Oracle): Alex: If you POST to an AssemblyTemplet, that will start the app.
	Gil Pilz (Oracle): ? DELETE on an Assembly will stop the app.
	Jacques (Fujitsu): The new-state way to operate CAMP resources (6.13) seems not very appropriate to complex resources such as apps.
	Gil Pilz (Oracle): Gil: Alex, do you concede the need to interoperably stop an app but leave it around.
	Gil Pilz (Oracle): Alex: It's tricky one to solve. Say I'm a git repository, how do you do this interoperable stop? What if I'm a deployed WAR file? Does "stop and leave around" mean, "stop and leave deployed on the app server" or "stop, remove from the app server, but surface the relevant log entries" ?
	Gil Pilz (Oracle): Mark: If you want to get rid of the STOPPED state, since we don't allow you to get there, that would be fine. Let's not define any states that we don't provide an interoperable way of getting to.
	Gil Pilz (Oracle): Adrian: We may anticipate some states that components could get into.
	Gil Pilz (Oracle): Mark: ERROR is okay.
	Gil Pilz (Oracle): (misc. discussion)
	Gil Pilz (Oracle): Adrian: Not defining things like "STOPPED" will lead to less interoperability. We may not know how a particular component gets into STOPPED, but its good to have a common one for people to use - even if the semantics differ from component to component.
	Alex Heneveld: how about no STATE attribute
	Alex Heneveld: just a boolean READY attribute which is TRUE iff the component is ready for folks to use (started correctly, no additional stop operations, and no serious errors)
	Gil Pilz (Oracle): Gil: If the operations that get you into a state are an extension, why shouldn't the name of that state be an extension?
	Michael Behrens: fyi: has a service provider defined status (not state) been considered?  A free text field for implementors to use.  Extensions?
	Alex Heneveld: @Michael - good use case for extension in my view
	Ashok Malhotra (Oracle): +1
	Alex Heneveld: @Gil - your comment about not knowing whether an Assembly is READY is a good point; i am wondering whether we need root / assembly-level characteristics in the PDP to be able to specify such things
	Gil Pilz (Oracle): Michael: The CAMP client can collect the state of the various components in an Assembly and present that.
	Adrian Otto (Rackspace): Two states: READY and ERROR. Seems to be what Mark and Alex both support as the first approach here
	Alex Heneveld: @Gil - how about boolean attribute(s) rather than a single state ?
	Gil Pilz (Oracle): @Alex - where do I put the extension values?
	Gil Pilz (Oracle): Making the provider define a new attribute to contain those seems like a bit of a pain.
	Alex Heneveld: @Gil any elaboration on these is a _new_ state attribute
	Gil Pilz (Oracle): Jacques: Would like to see "state" at the Assembly level.
	Gil Pilz (Oracle): Jacques: There might be more to the state of an application than just the sum of the states of its components.
	Gil Pilz (Oracle): ? I dissociate the ideas of managing state and representing state.
	Gil Pilz (Oracle): Mark: We should be careful about putting stuff in our spec that requires you to instrument your application specifically for CAMP.
	Gil Pilz (Oracle): ? "state" should be a reflection of what the platform knows about the component, not what the component thinks about itself.
	Gil Pilz (Oracle): ? should get rid of STOPPED and COMPLETED
	Gil Pilz (Oracle): +1 to Mark
	Adrian Otto (Rackspace): +1
	Gil Pilz (Oracle): Alex: It's hard for the CAMP impl to look at an Assembly and tell whether it is READY or not. It's hard to do this even on a individual component level. The only way to solve that is to put hooks into the DP that tells the Platform what the "readiness evaluator" is.
	Gil Pilz (Oracle): ? Calling what the platform sees "state" is going to confuse people.
	Gil Pilz (Oracle): ? Jacques use case is the correct one.
	Gil Pilz (Oracle): ? Stay silent on this matter for now and let this sort itself out in the initial implementations.
	Gil Pilz (Oracle): ? The solution we have now is a hack
	Gil Pilz (Oracle): Adrian: Why did the TC come to the consensus that we need to represent state?
	Jacques (Fujitsu): PDP-defined(or DP) "readiness" for Assemblies might be something to investigate.
	Gil Pilz (Oracle): Mark: Maybe the attribute on Assembly just means "the platform has completed its work - as far as I know this thing is ready to run"
	Gil Pilz (Oracle): Alex: I'm sure about having a new attribute to represent whether something is in the process of being completed.
	Gil Pilz (Oracle): ? More generally, "is the platform doing anything to this resource at this time".
	Gil Pilz (Oracle): ? Another way would be to list any active operations.
	Gil Pilz (Oracle): Jacques: If "state" is platform meaningful only, maybe we should call it "status"?
	Gil Pilz (Oracle): ? This leaves the door open for someone to extend Assembly with "state".
	Gil Pilz (Oracle): ?  s/state/status/
	Jacques (Fujitsu): In favor of calling what is discussed in CAMP-31 "status" and not "state", because later on we may need to add an application-meaningful "state" attribute to Assemblies (or components) even if its semantics is app-specific.

Topic: CAMP-118
	https://tools.oasis-open.org/issues/browse/CAMP-118
	Gil to update. Assigned Jira issue to Gil for editorial wording refinements.

	Transcript:

	Gil Pilz (Oracle): Gil: (reviews)
	Gil Pilz (Oracle): Adrian: Is this actionable?
	Gil Pilz (Oracle): Gil: Maybe s/in the PDP/described by the DP/
	Gil Pilz (Oracle): ? There's no specific reason to discuss the PDP in a discussion of the DP. The DP is a stand-alone entity.

Issues with Comments (Not Reviewed):
	https://tools.oasis-open.org/issues/browse/CAMP-126
	https://tools.oasis-open.org/issues/browse/CAMP-131
	https://tools.oasis-open.org/issues/browse/CAMP-135
	https://tools.oasis-open.org/issues/browse/CAMP-136

AOB:

	Stragglers Michael Behrens, Derek Palma. 

Meeting adjourned



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]