On 07/12/2011 02:16 PM, Adam Stokes wrote:
On Tue, 12 Jul 2011 13:04:22 -0400
Perry Myers<pmyers(a)redhat.com> wrote:
>> design api:
>>
>> is_configured - A Matahari property provided from the agent to
>> determine whether a system has been configured or not.
>
> What is the semantic for determining the value of is_configured?
> (basically at a high level what will is_configured do/check)
>
>> mh_configure ( URI, TYPE) :
>> - The URI should be able to translate properly given any number of
>> protocols:
>> - HTTP|HTTPS|FILE|PUPPET|KS
>
> What is meant by puppet/ks wrt 'protocol'. Is there a puppet style
> URI for talking to a puppet master?
>
>> - The protocols will be defined by TYPE:
>> - KICKSTART, PUPPET, HTTP, FTP
>
> If ftp, are we assuming anonymous access (otherwise we need more
> params for password)? I'd almost say skip ftp since it is a major
> pita. Maybe tftp instead?
tftp, as these protocols weren't set in stone I was just throwing out
there what I knew. Puppet and KS do not have a URI syntax but that
doesn't mean we can't translate puppet://node/configs/site.pp into
something retrievable. The type is there to help guide the path we
should take when activating the configuration, assuming we are
supporting more than puppet and registry edits.
As I mentioned, I think you're mixing file type and transport where they
don't need to be.
It seems cleaner to have the URI define the transport via http://,
file:// etc while the type parameter defines the way the file will be
processed. If we use something like puppet:// in the URI, how do we
differentiate between puppet files that are retrieved via http vs. tftp?
Valid URIs we could handle would be like: http. tftp, file
Valid types would be: puppet (for now)
>
> Also, what is puppet/kickstart protocol? Those define the type of
> file, but not the transport. It seems that with ks, puppet, http,
> ftp you're mixing the notions of transport and config file type
> together.
>
>> - The agent message content should be able to retrieve configs in
>> several ways
>> - Directly from a QPID message.
>> The message should contain some metadata describing
>> the config as well as the configuration itself.
>> Some things to note, the configuration must be
>> transferred unaltered in case third party
>> applications require correct syntax (INI, YAML)
>
> If passing a file vs. a URI to a file, what parameter is used? Using
> URI here would seem incorrect. Should we have two API calls:
>
> mh_configure(URI, Type)
> mh_configure(file, Type)
That or we could set the file to be something like file:///node/configs
and convert the path locally.
I think you're missing my point... In the above 2nd API call, file is a
blob (XML, ini, yaml) not a URI. Using file:///node/configs doesn't as
the value of 'file' doesn't transfer content, only a reference.
>> - Once configuration is obtained the ability to initiate the
>> configuration or verify a third party will initiate
>> configuration is needed.
>
> Right, our first pass will be the puppet client tool to process
> puppet files on the host.
>
> What other config mechanisms are we considering? You mentioned
> kickstart, but that's for system installation. Is there a way to
> process a kickstart file as part of an 'after install' process?
The ones I know of are Puppet and CFEngine and then possibly reading a
yaml/ini file and placing a script in the initialization process to
handle the config on a reboot.
Ok, that doesn't answer the question of: what is using a kickstart here?
>
> Also, where are the more generic 'config' APIs that expose augeas
> functionality? That is all part of the sysconfig agent, no?
>
Yes, we should get input from the brno guys to see if any progress was
made wrt augeas. If not, now would be the time to discuss what routines
we'd like to have.
Talk to them to get their api, and then resubmit this RFC with their api
included. The rfc should cover the entire scope of sysconfig, not just
the puppet parts.
Of course, all of this could become moot if we can't secure this
agent :)
It's not moot, the agent will be secured via auth mechanisms provided by
QMF/qpid. It just won't be selinux contained, which is not ideal but as
dwalsh points out is inevitable for an agent with this sort of scope.
So I don't see this as a blocker.
Perry