Open Stack

On 29/01/14 10:17 -0800, Georgy Okrokvertskhov wrote:
>Hi Angus,
>
>Let me share my view on this. I think we need to distinguish implementation
>and semantics. Context means that you provide an information for method but
>method will not keep or store this information. Method does not own context
>but can modify it.  Context does not explicitly define what information
>will be used by method. Context usually used when you keep some state and
>this state is shared between methods.

I agree with the definitions. 

>
>Parameters in contrary are part of method definition and strictly define
>that method requires them.
>
>So semantically there is a difference between context and parameters, while
>implementation can be the same.
>
>Lets take this example:
>https://review.openstack.org/#/c/69308/5/solum/objects/plan.py
>
>There is a class Plan which defines a model for specific entity. The method
>definition "def create(self, context):" shows us that there is no required
>parameters but method result might be affected by context and the context
>itself might be affected by this method. It does not say what will be the
>behavior and what will be a resulting plan, but even with empty context it
>will return something meaningful. Also it will be reasonable to expect that
>I will have mostly the same result for different contexts like
>RequestContext in API call and ExecutionContext in a working code when
>worker executes this plan.
>
>Now I am reading test
>https://review.openstack.org/#/c/69308/5/solum/tests/objects/test_plan.pytest
>case test_check_data. From what I see here I can figure out is that
>Plan actually stores all values from context inside plan object as its
>attributes and just adds additional attribute id.

Not really, the current pattern is:
obj = Plan()
obj.<db column> = "new value"
obj.create(ctx)
# does nothing currently with the context
# if the object exists already:
obj = Plan.get_by_id(ctx, the_id)
# also does nothing with ctx, but could check to make sure you
# actually own the plan (filter by user_id, project_id)
obj.<db column> = "new value"
obj.save()


>There is a question: Is plan just a copy of Context with id? Why do we need
>it? What are the functions of plan and what it consist of?
>
see above.

>If plan needs parameters and context its really just a container for
>parameters, lets use **kwargs or something more meaningful which clearly
>defines how to use Plan and what are its methods.
>We want to define a data model for a Plan entity. Lets clearly express what
>data is mandatory for a plan object like Plan.create(project_id, user_id,
>raw_data, context).

I'd be happy with requiring project_id, user_id in the create (we
could also set nullable=False in the db). Tho' raw_data *could* be
empty. So we could say the constructor and columns with nullable=False
should match up.

I think the current approach is Plan() returns a new row in the db
you then fill in the attributes and call .create() or .save()

But I agree context *could* be removed here (unless Clayton can come
up with a good reason for this). 

>Let's keep data model clear and well defined instead of blur it with
>meaningless "contexts".
>

sure, I have no issues with that. 

-Angus

>
>
>On Tue, Jan 28, 2014 at 3:26 PM, Angus Salkeld
><angus.salkeld at rackspace.com>wrote:
>
>> 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
>>>
>>
>>
>> _______________________________________________
>> 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