On 10/06/2011 02:06 PM, Joseph VLcek wrote:
> On Thu, 2011-10-06 at 10:21 -0400, Bryan Kearney wrote:
>> On 10/06/2011 10:04 AM, Greg Blomquist wrote:
>>> On 10/06/2011 07:52 AM, Bryan Kearney wrote:
>>>> On 10/06/2011 07:45 AM, jrd(a)redhat.com wrote:
>>>>>> From: Bryan Kearney<bkearney(a)redhat.com>
>>>>>> Date: Wed, 05 Oct 2011 15:52:55 -0400
>>>>>>
>>>>>>
>>>>>> Better yet, if you guys could write a json file to
>>>>>>
>>>>>> /etc/rhsm/facts/aeolus.facts
>>>>>>
>>>>>> it will JustWork(tm)
>>>>>>
>>>>>> would that be possible?
>>>>>>
>>>>>
>>>>> It's all software, anything is possible :-)
>>>>>
>>>>> I like the idea of spec'cing and publishing The One True Place
where
>>>>> these kind of launch/boot time params get stashed. Or maybe another
>>>>> one, because there are lots of One True Places :-( A few questions
and
>>>>> observations:
>>>>>
>>>>> At various times when thinking about that sort of thing, we've
>>>>> speculated that it might make more sense, rather than one big
>>>>> json/xml/text/yaml/whatever file, to structure such a place by
>>>>> services^H^H^H^H^H^H^H^Hfunctional areas, so that the individual
>>>>> consumers of that data aren't required to converge on and parse a
big
>>>>> datastructure. IOW, perhaps a bunch of files, or a tree of
>>>>> directories with factoids, etc. I think you can argue that issue
>>>>> multiple ways, but I think it's worth hammering through some use
cases
>>>>> before we decide on a representation. Yes, this point pre-supposes
>>>>> that there will be config/start scenarios which don't rely on
>>>>> rendezvous with a mother ship. If we converge on schemes where no
>>>>> config is ever done other than through puppet/chef/whatever, then
this
>>>>> issue goes away, I think.
>>>>>
>>>>> I expect that, no matter what we define, there will be call for some
>>>>> kind of transformation into something else. Ie "Cool! I want
a
>>>>> plugin which will morph those tree factoids into the init script for
>>>>> my daemon!". And more complicated variations on that theme.
One
>>>>> completely plausible way of accomplishing that would be via puppet
or
>>>>> one of the other similar tools, and if we end up making the
statement
>>>>> "We support this landing place for facts, it's up to
somebody else to
>>>>> consume them", that's pretty plausible. In that case, I
advocate that
>>>>> we work through some sufficiently detailed scenarios with those
tools,
>>>>> so that (a) we understand them, and (b) we can explain them to our
>>>>> users.
>>>>>
>>>>> Is /etc really the right place to put that stuff? I'm not
arguing for
>>>>> anyplace else, it's just that I keep hearing conflicting theories
on
>>>>> where the most correct place is for such data to live these days.
>>>>> Somebody also asked about /var; I don't envision this kind of
data
>>>>> being something which is flux, I see it as getting settled at start
>>>>> time, then living for the life of the instance. But I think you can
>>>>> argue that one diffrerent ways as well, for instance what about bare
>>>>> metal machines which change configuration over time? So I don't
>>>>> know. This, to me, is not a huge deal, but IWBNI we could settle on
a
>>>>> manifesto or something describing what we're putting where.
>>>>
>>>>
>>>> This is way too complicated for what we need. Drop the ids on the file
>>>> system. For me, the ideal place is:
>>>>
>>>>
>>>> /etc/rhsm/facts/aeolus.facts
>>>
>>> Just to be clear, we're talking about two different things in this
>>> thread now, correct?
>>>
>>> On one side, we have the various IDs (image ID, instance ID) that would
>>> get stored in /etc/sysconfig/aeolus/facts/$name-uuid, where each file
>>> contains a single value of the ID corresponding to the filename.
>>>
>>> On the other side, we're talking about config information distributed by
>>> config server to the instance that would get stored in
>>> /etc/rhsm/facts/aeolus.facts.
>>>
>>> Am I reading this right? Or, are you suggesting that the IDs we've been
>>> discussing in this thread should be in /etc/rhsm/facts instead of
>>> /etc/sysconfig/aeolus/facts?
>>
>>
>> I think it is the same. If you do not care where they go.. put them as
>> json into /etc/rhsm/facts/aeolus.facts and we will pick them up. It
>> will "just work".
>>
>> If that bugs you, tell me where you will put them and I will collect
>> them from there.
>>
>> -- bk
>> _______________________________________________
>> aeolus-devel mailing list
>> aeolus-devel(a)lists.fedorahosted.org
>>
https://fedorahosted.org/mailman/listinfo/aeolus-devel
>
> Bryan,
>
> To confirm my understanding.
>
> There are 2 proposals for sharing IDS, 1. simple files 2. json facts
> file
>
> Option 1: simple files:
> -----------------------
>
> The Audrey Agent running in the instance would create the files:
>
> /etc/sysconfig/aeolus/facts/instance_uuid
> /etc/sysconfig/aeolus/facts/image_uuid
>
> The content of these files would be of the form:
> "value1"
>
> e.g.:
> % cat /etc/sysconfig/aeolus/facts/instance_uuid
> 7634fa9a-f042-11e0-80e0-52540020e3d1
>
> % cat /etc/sysconfig/aeolus/facts/image_uuid
> a70fc2a0-8a5a-46ec-bed9-c069d3ce439
>
>
> Option 2: One json facts file:
> ------------------------------
>
> I'm not familiar with json facts however in looking at:
>
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deploym...
>
> I think what is needed is for the Audrey Agent running in the instance
> to create the file:
> /etc/rhsm/facts/aeolus.facts
>
> With the content of the form:
> {"fact1": "value1","fact2": "value2"}
>
> e.g.:
> % cat /etc/rhsm/facts/aeolus.facts
>
{"instance_uuid":"7634fa9a-f042-11e0-80e0-52540020e3d1","image_uuid":"a70fc2a0-8a5a-46ec-bed9-c069d3ce4399"}
>
> Is my understanding correct?
yes, 100%
>
> The instance_uuid is already available to the Audrey Agent.
> The image_uuid is not yet.
>
> Earlier in the thread you had written:
>
>> if the image uuid is also known, it could be dropped into:
>>
>> /etc/sysconfig/aeolus/facts/image_uuid
>
> Which makes me wonder how important is it to have the image_uuid and is
> that a necessity for 1.0 ?
The image id is not important for v1. My goal is if we do this that there is a means for
later on passing additional data between the two. Either approach solves that. So, if we
pick one approach and get the instance ID in there we have met the v1 goals.
-- bk
I will polish it up and add some redmine tasks for impacted components tomorrow.
Input/feedback welcome.
Thank you.
Joe