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.salk...@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.salk...@rackspace.com>wrote:

 On 27/01/14 22:53 +0000, Adrian Otto wrote:

 On Jan 27, 2014, at 2:39 PM, Paul Montgomery <
paul.montgom...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Reply via email to