pCard Overview
jamesurquhart
http://news.cnet.com/8301-19413_3-10440799-240.html
What are your thoughts? I'll try to find time to elaborate in the next
day or two, but what are your first impressions?
James
Rodos
a pCard response?"
In thinking of the description of the pCard its important to think
about the response or return information as well. There is no point
describing it if it goes into a black hole. The response might be as
little as an ack of receipt however the purpose of creating it is to
get a result back. What should that result look like? What will it
contain and how will it be different to the pCard?
Anyway see the other thread, I probably express it better there.
Rodos
Mike Kelly
elements that need addressing.
In order to be sustainable - this type of system has to be open,
distributed, and evolveable. Personally, I think the best way to
achieve this is by leveraging the web and linked data - something
along the same lines as OCCI.
Is this the right forum for exploring that specific approach?
- Mike
jamesurquhart
Can you explain more about what you are proposing to get everyone up
to speed?
James
jamesurquhart
quality at this point, not set in stone in any way):
- The contents of the three main body sections of the pCard should be
line item requests, each item consisting of:
- An adverb for type of requirement (e.g. "MUST", "CAN", "SHOULD",
etc.)
- Some form of statement of what is needed (the form of which it
TBD, IMHO)
- The contents of a response should usually include:
- Responses to each line item, which can include:
- "UNKNOWN" if provider doesn't know how to handle
- "ACCEPTED" if provider can meet request as is
- "REJECTED" if provider cannot handle request
- "MAP_TO" if provider can handle request, but requires some
adjustments in the application packaging/configuration
- The generator of the request (the client) should also be able to
handle multiple responses from multiple providers, and assemble a
working solution from the responses if necessary/possible.
There is a lot more needed here, and the detail of each line item type
is not clear to me, but this is what I've been starting with.
James
Glenn
I really like the concept (and defined categories) in the pCard.
One small nit is that I wouldn't call the first category "metadata" -
I think that term evokes thoughts of all the data that isn't the
actual "bits in the runtime stack" (maybe that's an OVF bias showing
through). Since the category seems to be a minor point compared to the
others, maybe just "Format/Version"?
Also really like the feedback that suggests that clouds provide a
similar descriptor - maybe we call that one the cCard?
-Glenn
Rodos
Rodos
http://rodos.haywood.org/
Rodos
For the response do you see it being injected into the original card
that is returned, so you don't need the original card to interpret it.
Does anyone know of any comparable information exchange mechanisms
which have already developed a lot of this structure?
I prefer VALID to ACCEPTED.
<geography>
<value>AU</value>
<requirement>MUST</requirement>
<response>VALID</response>
</geography>
Of course the appropriate XML schema would need to be developed.
Rodos
Dustin Amrhein
nice, but I'm
not sure injecting the response into the request seems like the right
thing. It may
make responses unnecessarily large.
I could see two other potential ways:
1) Make it the responsibility of the client to cache or otherwise
store the request
2) Establish a field in the response that is a link to the pCard
request. Of course
this mandates the request is actually stored somewhere and probably by
the provider.
Not to argue anything too nitpicky, but in my opinion think ACCEPTED
is more
appropriate than VALID in this scenario. The client is expressing it's
requirements of
a provider with the pCard request. The provider can accept the request
or reject it
based on its ability to fulfill what the client is asking for. To me
the validity of a
request is independent of whether a provider can fulfill said request.
Just my two cents...
David
I have been calling this Profile Match instead of pCard. The
challenge is to find a way to make it fast enough that you get a
branch path type operation from a transparency perspective with the
serious latency limits you will be dealing with compared to most
current systems that make sure of that type of model.
The profile exploration has to end early enough if there is no real
hope of a match so that things are not slowed down to the point of
system instability.
I assume using the Accepted, Rejected, Unknown model you will populate
a cache of sorts that will direct future queries in a faster manner
such that if someone has served you previously and has not changed
substantially you will not rewalk the tree.
Valid and Invalid could still work because an unknown state is no
better than Invalid more than likely for the purpose of what you do
with the answer more than likely.
Valid/Invalid Request/Response = Accepted or Rejected pCard/profile
match
In the end speed may matters even more than perfect matches so there
has to be some wiggle room within the parameters. Where speed does
not matter, you could then require a much tighter set of match
criteria. UDP/TCP analogies etc...
James, you are calling it a Payload Card but yet it will be used to
set up a great number of things that may or may not be related to
payloads in the traditional sense right?
I also do not think it will be the provider accepting or rejecting
more than likely. Once you advertise what you have and a client
accepts of rejects it, the provider should not have the ability to
kill it without misuse etc. by the accepting client. This also gets
back into a concept of some type of veiling and non-repudiation of
both ends such that a requirement of the pCard would be a level of
trust that cannot currently be achieved in any system today.
More later..just ideas..thanks for bringing this up James.
--David
David O'Berry CSSLP, CISSP-ISSAP, ISSMP, MCNE, CSPM
Director of ITSS
SC Dept. of Probation, Parole, and Pardon Services
Rodos
There will certainly be some effort in processing the requests, I see
brokers playing a part here, filtering down where requests need to be
sent based on what they know about the providers. Thats why I think
there is a need for providers to have a cCard or something like that
which has some from of expiration. That way a broker (or the consumer
could do this too) can eliminate a whole set of providers if they know
they can not been a certain criteria right off the bad, for example
geographical location.
I don't see the pCard negotiation as where the actually acceptance and/
or rejection occurs or where any contract or agreement takes place. I
see that occurring where the actual payload itself gets processed. You
mention trust. By keeping the pCard at the enquiry and negotiation
stage we can keep security and trust requirements low. We only want to
share so much. Then if we need to go further we can move to a higher
level of trust and share more details, and I see this portion occuring
with the actual payload or a subset of it (after the pCard negotiation
has confirmed that we can work together at that level and in that
format or dialogue type).
Hope some of that makes sense, its been a long day and I think I am
starting to ramble.
Welcome to the discussion.
Rodos
David
Thanks for the welcome and good to run into you again.
I think the aspect of sharing can be and maybe needs to be as full of
information as possible just without a known identity but with non-
repudiation.
There is a concept of Veiled Certificates that I have been working
with some University of South Carolina professors on re: applications
in the health care field. It, or something like it, might fit here.
The interesting thing about the expiration piece you mention is that a
framework that managed those types of IDs is also based on
certificates. I hate to bring certificates up because people have a
certain pre-conceived notion of them. Having said that, this version
would need to use a number of the extensible attributes in order to be
used in some interesting ways to create the more limited set of
choices.
I am not sure we can wait until the processing of the payload though
to make a complete decision. I need to think about that. It's almost
like there needs to again be two models, one more just in time and one
more stateful so that you choose your risk tolerance and the cost is
of course variable to the model chosen. ATM might have some good
models to think about in this vein...CBR, VBR, ABR, UBR to coincide
with connection oriented and connection-less at the higher levels of
the stack.
Long day already for me for a Monday so like you, I worry that I am
rambling..
Then again sharing the ideas, right or wrong, is the only way to
square this up longer term.
--David
Rodos
> Yah that does make sense Rodos. I do remember..San Fran right?
Good memory.
> I think the aspect of sharing can be and maybe needs to be as full of
> information as possible just without a known identity but with non-
> repudiation.
Um, I still struggle with this but it may be a matter of
interpretation. Yes, want to give as much info about my requirements,
but I don't want to reveal to much about reality. For example my pCard
will say, I need 20 internal private IP addresses for the workloads to
communicate with each other and I want to choose them myself (rather
than being allocated from a provider pool to avoid overlap). But I
don't want to tell you those addresses yet, thats actual config data
that will go with the payload later on.
> I am not sure we can wait until the processing of the payload though
> to make a complete decision. I need to think about that.
I think you need to be able to make the "decision" based on the pCard
and response. But its when you process the actual workload that you
form the agreement and raise you levels of trust. I read you pCard and
respond, Yes, I can take your load, yes I support those things, and I
support certain formats of the workload packaging (vApp, OVF, AWS,
Ruby, Hadoop, Spring) you can deliver it to me as. We then move to
second base and you pass me your workload in the optimal format (I may
have many different types of clouds) and we are now in business.
> Then again sharing the ideas, right or wrong, is the only way to
> square this up longer term.
Exactly, throwing things out there is the way to progress. If we had
all the answers already we would not need to be here discussing
things.
Dustin Amrhein
pCard, we know the providers are going to need to produce something
that can be negotiated against a cCard. I'm not sure if it adds an
unnecessary layer of complexity, but I was thinking it may be helpful
to have registries of these cCards (or whatever they are called). The
providers could either publish to these registries or the registries
could periodically send requests to providers for their cCard-like
information at intervals based on expiry times mentioned above.
With registries included as part of the overall pCard request flow, I
had something like I've mocked up here in my head:
http://docs.google.com/leaf?id=0B0bzuZchxt66MGFhYTQ2Y2UtMmQwYy00ODJmLWE1NWYtNTZiNDJmOThmNTI5&hl=en
This is extremely simplistic and may be way off base, but in any case
I thought it may be good for us to start producing images of some of
the flows we were thinking about.
Rich Miller
of throwing the conversation off track temporarily:
I'd like to suggest that the notion of a 'card' ... whether it's a
pCard or cCard ... may be clouding our vision (sorry... couldn't
resist) regarding solutions to the problem at hand. Dustin starts to
address the issue with the introduction of registries. The group as a
whole seems to resonate with the notion of a 'marketplace' in which
brokers act as trusted third parties to match up requirements and
capabilities, subject to constraints established by the prospective
customer.
The fundamental notion with which I take issue is a 'card'. pCard
seems to be conceived of as a static document that (as a potential
consumer of cloud services) I prepare to describe my requirements and
constraints... almost a structured request for a structured proposal
response document. Or, cCard as a pre-printed menu or catalog that is
distributed in an effort to get attention from a populace of potential
customers.
It seems that an alternative approach can be accomplished through the
judicious use of metadata publish/subscribe and simple registries.
For those of you who know that I'm presently hip-deep in a project to
think through cloud service registries and a general solution of
metadata dissemination in the Inter-cloud, you'll know where some of
this is going.
I'm positing that the dissemination of operational metadata among
cloud service providers using a combination of pub/sub and less
structured search is also a viable basis on which pCard and cCard
mechanism could be based, for the appropriate discovery or matching of
requirements, recipient (subscriber) controlled dissemination of
timely information and initiation of service contract negotiation.
Starting with the 'cCard' issue:
As a service provider, what I'd be more willing to do is place an
authoritative description of the kinds of services I offer, and
specific requirements I can meet, on a billboard, visible to all
potential customers. (The image I have is one of driving past a
service station and seeing a sign advertising the availability of
grades of gasoline/petrol and the current price per unit of measure.)
If, as a cloud service provider, I want to limit the population that
can view this publication of offers, I can do this by establishing
access control based on some form of authentication.
That service provider's operational metadata should be authoritative
and under cloud service provider's direct, realtime control. Included
and associated with specific aspects of the advertised capabilities,
the service provider would include the commercial terms and a clear
statement of the time period or other constraints on the validity of
the offer. (This is in contrast to issuing a document that is
diseminated, with a TTL or 'this offer good only in Nevada until June
15'.)
Because this is a pub/sub approach, potential customers can
'subscribe' if they wish to have a standing request to see changes in
the offer, or only those changes that are relevant. This is
'subscriber' controlled, and therefore isn't an unmanageable,
uncontrolled stream of cCard spam.
If, as a subscriber, a recipient is unhappy with the subscription --
too much, too often, not detailed enough, etc. -- that subscriber has
the ability to modify the standing request for information. (Returning
to the service station scenario, rather than actually visiting the
service station ... i.e., polling to get the latest information ... a
potential customer ... or competitor! ... or a broker ... is notified
whenever a specific aspect of the advertised offer is changed. The
recipient is NOT placed on an undifferentiated mailing list that
results in junk mail every time the service station changes the offer
of motor oil by one penny.)
If a potential customer (or broker) can get (enough of) a match on a
pCard from this information, it would then strike me as the
appropriate time to:
- engage in a more detailed inquiry. Can the cloud service provider
meet my needs for a specific set of pre-built LAMP stacks? Are they
enabled with the right Chef recipes for dependencies and patch
management? Can the provider accomodate my requirements for a virtual
network, a fenced address space which allows customer-provided DNS/IP
address management?...
- establish (mutually) an agreement regarding the non-disclosure of
information... If assurances are needed by the parties to this
dialogue regarding information about to be disclosed ... either a
potential customer's details about a workload or a cloud service
provider's capabilities and most favored commercial terms ... everyone
engaged in the process has to be comfortable
Moving to pCards:
Given the complexity, detail and the security issues that @Rodos has
raised, it occurs to me that the pCard could quickly morph into
- a full scale service discovery, matching, and commercial negotiation
dialog, complete with successive levels of mutual assurance of
credentials, authentication and non-disclosures leading to a cloud
service contract ...
or
- the opening presentation or organization of a search or a
subscription request... the basis on which a potential customer or a
broker would enter into a more detailed, but probably less formal and
less structured, description of requirements and capabilities with a
cloud service provider.
The secret to success or failure of the pCard concept is likely to be
how 'liberal' the approach is with respect to a data scheme. If pCard
is based on a highly elaborate, extremely deep data scheme, amenable
to structured queries, I fear that it will fail.
What's necessary in the effort is that the search of operational
metadata (as opposed to a structured query) be made available, and
that the pCard embody the first (or first layers) of that search
request.
---
I'm sorry I don't have the time at this moment to put this into better
organized thoughts and words. I also realize that I'm operating with
a reasonably full picture of what is required for cloud service
providers to disseminate operational metadata, and that those of you
who are not familiar with the Lighthouse project I'm working on in the
context of the Infrastructure 2.0 Working Group are going to be a bit
puzzled. My apologies.
I hope to generate a blog post later today or tomorrow on this train
of though. I'd welcome any suggestions and reactions that will help
me clarify the notions.
= Rich
Rich Miller
Twitter: @rhm2k
Web: http://telematique.typepad.com/
On Feb 1, 7:59 pm, Dustin Amrhein <dustin.amrh...@gmail.com> wrote:
> Whether we call it a cCard or it's simply a provider flavor of the
> pCard, we know the providers are going to need to produce something
> that can be negotiated against a cCard. I'm not sure if it adds an
> unnecessary layer of complexity, but I was thinking it may be helpful
> to have registries of these cCards (or whatever they are called). The
> providers could either publish to these registries or the registries
> could periodically send requests to providers for their cCard-like
> information at intervals based on expiry times mentioned above.
>
> With registries included as part of the overall pCard request flow, I
> had something like I've mocked up here in my head:
>
> http://docs.google.com/leaf?id=0B0bzuZchxt66MGFhYTQ2Y2UtMmQwYy00ODJmL...
Lori MacVittie
thought here. As far as matching responses with request it may be
valuable to examine the SOAP request/response message pairing. Rather
than injecting the entire request the response can include the
appropriately matched response:
If the request is:
<geographyRequest>
<value>AU</value>
<requirement>MUST</requirement>
</geographyRequest>
The response might be:
<geographyResponse>
<response>VALID</response>
</geographyResponse>
Unfortunately the need to correlate with a request is not something
I'm seeing an answer to at the moment as I assume a (very)
asynchronous model, though I do think the client should likely take
responsibility for that.
Lori