HistoryViewLinks to this page 2013 October 17 | 12:27 pm

index / Automation Meetings / This page

Time: 11:00AM Eastern US (Currently 4pm UTC)

Agenda

Chair: Umberto

Actions from last meeting

Person Action Due
Martin [in agenda] Remove versioning from primer 17th Oct
Martin & Umberto [in agenda] Plan schedule/deadlines required for getting v2.1 into finalisation by the end of the year 17th Oct
Umberto [in agenda] Update draft V.next spec with Template changes. Flag “This is new for 2.1” at beginning of new section. 17th Oct
Steve S [in agenda] Feed back on Actions. Discuss with CM workgroup. Feed back 17th Oct
Charles [in agenda] E-mail about thoughts & problems how existing spec can be used for orchestration scenarios (with view to writing non-spec companion doc) Feed back 17th Oct

Actions carried over/not yet due:

Person Action Due

Minutes

Attending: Umberto, Martin, Steve S, John Arwe, Mike F

  • Documents
    • Primer - versioning removed
      • Moved to OSLC Automation Primer
      • Removed version number, and this/previous/latest version links from top
      • Status line now refers to the version of the latest main spec that it refers to, rather than its own version
      • Updated old URL OSLC Automation Primer 2.0 to redirect to new page
  • Timeline for PostV2
    • Convergence by 1st Dec
    • Finalization by 14th Jan?
      • If we have enough people trying implementing it by then
      • TODO: Detail who will be the first ‘trial’ implementors, and determine when they can try implementing it.
  • Template creation
    • New section in 2.1 spec
    • New oslc:usage URI for template creation dialogs
      • TODO: Needs to go into vocab document when we go into finalization
      • #templateCreation should be #TemplateCreation
    • “The resource MAY be temporary and the consumer SHOULD get it within a limited time and SHOULD NOT assume that it is available after the first time it has been requested.”
    • “The resource MAY not be persisted and therefore MAY not be able to be queried. Consumers that want to be interoperable SHOULD presume that the resource is not persisted and cannot be queried.”
  • CM discussion on Actions is complete, as a result of previous discussions on Automation and CM WGs.
    • Action spec can fit into CM work group - CM to decide whether to keep things in their namespace and provide information on how to infer Action triples, or whether to use Action triples explicitly, but nothing more to feed back to Automation/Core on design of Actions.
  • Orchestration
    • Problem is tying outputs from one Plan to inputs to another.
    • Green Hat has a couple of scenarios that could be used to demonstrate this sort of problem, but we’re not asking for an OSLC solution.
    • Tivoli (Workload Scheduler?) has a similar problem - requires a manual wiring step.
    • Concensus seems to be to leave on back burner until someone needs it and would want to implement it.
  • Actions
    • Terminology email - Impl type vs profile
      • “Profile” is casual term
      • Impl type would be in core spec (possibly copied in Auto, depends on making Auto spec readable)
      • Core spec also to refer to CM’s usage of Actions - so readers of Core have existing examples to reuse or copy
        • Useful to see a draft
        • Depends on CM draft spec. Doesn’t have a hard date.
        • CM will look at Auto’s example.
    • Terminology email - “future actions”/”actions without context”
      • Discussion about similarity between AutoRequest templates and “future actions”.
      • Will continue discussion by email
    • TODO: getting proposal more spec-ready

Actions resulting from this meeting

Person Action Due
… (TODO)