On Sep 16, 2010, at 1:24 PM, Paul Berry wrote: > On Wed, Sep 15, 2010 at 11:35 AM, Luke Kanies <[email protected]> wrote: > Shouldn't 'none' be a valid state? Or maybe 'unknown'? I would think that's > different from 'invalid'. > > Do you mean if the user requests information about a host for which there is > neither a certificate request nor a certificate? I think I would prefer to > use a JSON "null" value for this case (equivalent to Ruby's "nil"). That > would be more consistent with the existing REST API's and with the semantics > of "certificate_statuses".
I'm inparticular about the actual term, just that we have something for hosts with no information at all. >> To cause the master to discard certificate information for a given >> host, issue a DELETE request to >> https://<master>/<environment>/certificate_status/<hostname>. >> >> This takes the place of the "puppet cert" option "--clean". > > This is essentially a superset of cert deletion and csr deletion (I don't > actually know if 'clean' removes a host from the CRL). Not a problem, but > worth noting that that behavior can be had already, albeit not as cleanly. > > Yes, good point. > > >> certificate and certificate_request >> ----------------------------------- >> >> The existing REST APIs for >> https://<master>/<environment>/certificate/<hostname> and >> https://<master>/<environment>/certificate_request/<hostname> (which >> are already used internally for exchanging certificates and requests >> between master and agent) are extended to support a human-readable >> text format. This format is only supported for reading. This takes >> the place of the "puppet cert" option "--print", and uses the same >> format. > > This seems less than ideal because it probably violates the principle of > least surprise for most people. There's a very standard text format for > certs - PEM-encoding. I'd recommend either having separate formats -- maybe > there's an existing MIME type for PEM? -- or stick to plain PEM encoding in a > text format, and then let the client decide how to deal with it. Anyone with > an ssl lib can convert from one to the other. OTOH, I expect that certs are > currently passed down as PEM-encoded text, so maybe this is me being crazy. > > You're right that anyone with an ssl lib can convert between the two formats. > Can we count on clients of the REST API to have access to an ssl lib? If > so, I'd be happy to drop this feature. > > If we decide to keep it, I agree that we should have separate formats > distinguished by MIME type. The "human readable text" format would be solely > for the benefit of REST API clients that didn't have easy access to an ssl > lib, and all other clients (including puppet itself) would continue to use > the PEM-encoded format that's already implemented today. I think it's a useful but not critical feature, I just think it's important to clarify that it's all text. -- We must believe in luck. For how else can we explain the success of those we don't like? -- Jean Cocteau --------------------------------------------------------------------- Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
