Open Stack

On 28/01/14 07:13 -0800, Georgy Okrokvertskhov wrote:
>Hi,
>
>From my experience context is usually bigger then just a storage for user
>credentials and specifics of request. Context usually defines an area
>within the called method should act. Probably the class name RequestContext
>is a bit confusing. The actual goal of the context should be defined by a
>service design. If you have a lot of independent components you will
>probably will ned to pass a lot of parameters to specify specifics of work,
>so it is just more convenient to have dictionary like object which carry
>all necessary information about contextual information. This context can be
>used to pass information between different components of the service.

I think we should be using the nova style objects for passing data
between solum services (they can be serialized for rpc). But you hit
on a point - this "context" needs to be called something else, it is
not a RequestContext (we need the RequestContext regardless).
I'd also suggest we don't build it until we know we
need it (I am just suspicious as the other openstack services I
have worked on don't have such a thing). Normally we just pass
arguments to methods.

How about we keep things simple and don't get
into designing a boeing, we can always add these things later if
they are really needed. I get the feeling we are being distracted from
our core problem of getting this service functional by "nice to
haves".

-Angus

>
>
>
>On Mon, Jan 27, 2014 at 4:27 PM, Angus Salkeld
><angus.salkeld at rackspace.com>wrote:
>
>> On 27/01/14 22:53 +0000, Adrian Otto wrote:
>>
>>> On Jan 27, 2014, at 2:39 PM, Paul Montgomery <
>>> paul.montgomery at RACKSPACE.COM>
>>> wrote:
>>>
>>>  Solum community,
>>>>
>>>> I created several different approaches for community consideration
>>>> regarding Solum context, logging and data confidentiality.  Two of these
>>>> approaches are documented here:
>>>>
>>>> https://wiki.openstack.org/wiki/Solum/Logging
>>>>
>>>> A) Plain Oslo Log/Config/Context is in the "Example of Oslo Log and Oslo
>>>> Context" section.
>>>>
>>>> B) A hybrid Oslo Log/Config/Context but SecurityContext inherits the
>>>> RequestContext class and adds some confidentiality functions is in the
>>>> "Example of Oslo Log and Oslo Context Combined with SecurityContext"
>>>> section.
>>>>
>>>> None of this code is production ready or tested by any means.  Please
>>>> just
>>>> examine the general architecture before I polish too much.
>>>>
>>>> I hope that this is enough information for us to agree on a path A or B.
>>>> I honestly am not tied to either path very tightly but it is time that we
>>>> reach a final decision on this topic IMO.
>>>>
>>>> Thoughts?
>>>>
>>>
>>> I have a strong preference for using the SecurityContext approach. The
>>> main reason for my preference is outlined in the Pro/Con sections of the
>>> Wiki page. With the "A" approach, leakage of confidential information mint
>>> happen with *any* future addition of a logging call, a discipline which may
>>> be forgotten, or overlooked during future code reviews. The "B" approach
>>> handles the classification of data not when logging, but when placing the
>>> data into the SecurityContext. This is much safer from a long term
>>> maintenance perspective.
>>>
>>
>> I think we seperate this out into:
>>
>> 1) we need to be security aware whenever we log information handed to
>>    us by the user. (I totally agree with this general statement)
>>
>> 2) should we log structured data, non structured data or use the
>> notification mechanism (which is structured)
>>    There have been some talks at summit about the potential merging of
>>    the logging and notification api, I honestly don't know what
>>    happened to that but have no problem with structured logging. We
>>    should use the notification system so that ceilometer can take
>>    advantage of the events.
>>
>> 3) should we use a RequestContext in the spirit of the olso-incubator
>>   (and inherited from it too). OR one different from all other
>>   projects.
>>
>>   IMHO we should just use oslo-incubator RequestContext. Remember the
>>   context is not a generic dumping ground for "I want to log stuff so
>>   lets put it into the context". It is for user credentials and things
>>   directly associated with the request (like the request_id). I don't
>>   see why we need a generic dict style approach, this is more likely
>>   to result in programming error     context.set_priv('userid', bla)
>>   instead of:
>>   context.set_priv('user_id', bla)
>>
>>   I think my point is: We should very quickly zero in on the
>>   attributes we need in the context and they will seldom change.
>>
>>   As far as security goes Paul has shown a good example of how to
>>   change the logging_context_format_string to achieve structured and
>>   secure logging of the context. oslo log module does not log whatever
>>   is in the context but only what is configured in the solum.conf (via
>>   logging_context_format_string). So I don't believe that the
>>   new/different RequestContext provides any improved security.
>>
>>
>>
>> -Angus
>>
>>
>>
>>
>>> Adrian
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
>-- 
>Georgy Okrokvertskhov
>Architect,
>OpenStack Platform Products,
>Mirantis
>http://www.mirantis.com
>Tel. +1 650 963 9828
>Mob. +1 650 996 3284

>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev