[Oslc-Automation] Doodle results and Re: Agenda for 4th April meeting? Also, follow on from tear down scenarios
Michael F Fiedler
fiedler at us.ibm.com
Tue Apr 2 14:50:25 EDT 2013
See http://www.doodle.com/tduny65a7vruy6qd for the results. The winning
time (and best time for current scenario owners) is Thursdays at 11AM
Eastern US time. Thursday at 9AM and Thursday at 12Noon came in second
but are not as good of a match for scenario owners.
So, unless someone has a strenuous objection, I move we meet weekly at 11AM
Eastern US. The alternative would be to go back to our alternating
schedule, but our colleague from China (David Liu) has indicated this time
is ok, so I think we go ahead with it.
For this week I had intended to continue our discussion on the teardown
scenario. If Martin is unavailable, I believe our options are
1. continue this week and try to discuss other scenarios
2. reschedule this week's meeting to the new time - I fear this would be
short notice
3. cancel this week and start the new weekly schedule next Thursday.
Reply if you have a preference for 1, 2 or 3. If there is no preference,
we will default to option 1 and have a shorter meeting if need be.
Regards,
Mike
Michael Fiedler
IBM Rational Software
fiedler at us.ibm.com
919-254-4170
"Oslc-Automation" <oslc-automation-bounces at open-services.net> wrote on
04/02/2013 10:59:17 AM:
> Martin P Pain <martinpain at uk.ibm.com>
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
>
> 04/02/2013 10:59 AM
>
> To
>
> oslc-automation at open-services.net,
>
> cc
>
> Subject
>
> [Oslc-Automation] Agenda for 4th April meeting? Also, follow on from
> tear down scenarios
>
> Do we have an agenda for the 4th April meeting?
>
> (The time's not particularly convenient for me this week, but I can
> make it at a squeeze - depending on what ends up on the agenda.)
>
> Following on from last week's discussion on temporary deployment &
> tear down scenarios, something we need to follow up on is
> identifying the wider scenarios and which ones we want to support.
> Negligent clients (who do not deregister their interest when done).
> This is partially addressed at the end of this scenario's page on the
wiki.
> Are there any further scenarios that could use a "Client" resource
> on the service provider?
> Scenarios using composed automation requests - where one request
> simply kicks off other requests (possible on other providers).
> This scenario could cause particular problems when a third party
> registers interest in one of those "child" deployed resources, as then:
> We don't want to tear down that particular resource when the parent
> one finishes - we want to wait for the third party to finish.
> We don't want to tear down any deployed resources that that
> particular one depends on.
> This leads us into: dependency modelling (using the Common IT
> Resource Type Vocabulary), and the scenarios that would use it.
> Also worth considering provider-to-provider relations, as we need to
> be able to look up "dependsOn" relationships from other providers to
> the resources in this provider. I believe that there is work in the
> core WG about this sort of thing.
>
> So something we could do is:
> Identify scenarios in these areas
> Decide which ones we want to support/consider
> Flesh the scenarios out
>
> (I'm not sure of the order of the last two.)
>
> Some of this should probably be done on the mailing list, rather
> than in the meeting.
>
> Martin
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
> _______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
>
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130402/080bf1ef/attachment-0003.html>
More information about the Oslc-Automation
mailing list