<div dir="ltr">Hi Angus,<div><br></div><div>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. </div>
<div><br></div><div>Parameters in contrary are part of method definition and strictly define that method requires them.</div><div><br></div><div>So semantically there is a difference between context and parameters, while implementation can be the same. </div>
<div><br></div><div>Lets take this example: <a href="https://review.openstack.org/#/c/69308/5/solum/objects/plan.py">https://review.openstack.org/#/c/69308/5/solum/objects/plan.py</a></div><div><br></div><div>There is a class Plan which defines a model for specific entity. The method definition "<span class="" style="color:rgb(0,0,102);font-weight:bold;font-family:'Lucida Console','Lucida Sans Typewriter',Monaco,monospace;font-size:11px;white-space:pre">def</span><span class="" style="color:rgb(0,0,0);font-family:'Lucida Console','Lucida Sans Typewriter',Monaco,monospace;font-size:11px;white-space:pre"> create</span><span class="" style="color:rgb(68,68,0);font-family:'Lucida Console','Lucida Sans Typewriter',Monaco,monospace;font-size:11px;white-space:pre">(</span><span class="" style="color:rgb(0,0,0);font-family:'Lucida Console','Lucida Sans Typewriter',Monaco,monospace;font-size:11px;white-space:pre">self</span><span class="" style="color:rgb(68,68,0);font-family:'Lucida Console','Lucida Sans Typewriter',Monaco,monospace;font-size:11px;white-space:pre">,</span><span class="" style="color:rgb(0,0,0);font-family:'Lucida Console','Lucida Sans Typewriter',Monaco,monospace;font-size:11px;white-space:pre"> context</span><span class="" style="color:rgb(68,68,0);font-family:'Lucida Console','Lucida Sans Typewriter',Monaco,monospace;font-size:11px;white-space:pre">):" </span>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.</div>
<div><br></div><div>Now I am reading test <a href="https://review.openstack.org/#/c/69308/5/solum/tests/objects/test_plan.py">https://review.openstack.org/#/c/69308/5/solum/tests/objects/test_plan.py</a> test 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. </div>
<div>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?</div><div><br></div><div>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. </div>
<div>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).</div><div>Let's keep data model clear and well defined instead of blur it with meaningless "contexts".</div>
<div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 28, 2014 at 3:26 PM, Angus Salkeld <span dir="ltr"><<a href="mailto:angus.salkeld@rackspace.com" target="_blank">angus.salkeld@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 28/01/14 07:13 -0800, Georgy Okrokvertskhov wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
>From my experience context is usually bigger then just a storage for user<br>
credentials and specifics of request. Context usually defines an area<br>
within the called method should act. Probably the class name RequestContext<br>
is a bit confusing. The actual goal of the context should be defined by a<br>
service design. If you have a lot of independent components you will<br>
probably will ned to pass a lot of parameters to specify specifics of work,<br>
so it is just more convenient to have dictionary like object which carry<br>
all necessary information about contextual information. This context can be<br>
used to pass information between different components of the service.<br>
</blockquote>
<br></div>
I think we should be using the nova style objects for passing data<br>
between solum services (they can be serialized for rpc). But you hit<br>
on a point - this "context" needs to be called something else, it is<br>
not a RequestContext (we need the RequestContext regardless).<br>
I'd also suggest we don't build it until we know we<br>
need it (I am just suspicious as the other openstack services I<br>
have worked on don't have such a thing). Normally we just pass<br>
arguments to methods.<br>
<br>
How about we keep things simple and don't get<br>
into designing a boeing, we can always add these things later if<br>
they are really needed. I get the feeling we are being distracted from<br>
our core problem of getting this service functional by "nice to<br>
haves".<span class="HOEnZb"><font color="#888888"><br>
<br>
-Angus</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
On Mon, Jan 27, 2014 at 4:27 PM, Angus Salkeld<br>
<<a href="mailto:angus.salkeld@rackspace.com" target="_blank">angus.salkeld@rackspace.com</a>><u></u>wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 27/01/14 22:53 +0000, Adrian Otto wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Jan 27, 2014, at 2:39 PM, Paul Montgomery <<br>
<a href="mailto:paul.montgomery@RACKSPACE.COM" target="_blank">paul.montgomery@RACKSPACE.COM</a>><br>
wrote:<br>
<br>
Solum community,<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I created several different approaches for community consideration<br>
regarding Solum context, logging and data confidentiality. Two of these<br>
approaches are documented here:<br>
<br>
<a href="https://wiki.openstack.org/wiki/Solum/Logging" target="_blank">https://wiki.openstack.org/<u></u>wiki/Solum/Logging</a><br>
<br>
A) Plain Oslo Log/Config/Context is in the "Example of Oslo Log and Oslo<br>
Context" section.<br>
<br>
B) A hybrid Oslo Log/Config/Context but SecurityContext inherits the<br>
RequestContext class and adds some confidentiality functions is in the<br>
"Example of Oslo Log and Oslo Context Combined with SecurityContext"<br>
section.<br>
<br>
None of this code is production ready or tested by any means. Please<br>
just<br>
examine the general architecture before I polish too much.<br>
<br>
I hope that this is enough information for us to agree on a path A or B.<br>
I honestly am not tied to either path very tightly but it is time that we<br>
reach a final decision on this topic IMO.<br>
<br>
Thoughts?<br>
<br>
</blockquote>
<br>
I have a strong preference for using the SecurityContext approach. The<br>
main reason for my preference is outlined in the Pro/Con sections of the<br>
Wiki page. With the "A" approach, leakage of confidential information mint<br>
happen with *any* future addition of a logging call, a discipline which may<br>
be forgotten, or overlooked during future code reviews. The "B" approach<br>
handles the classification of data not when logging, but when placing the<br>
data into the SecurityContext. This is much safer from a long term<br>
maintenance perspective.<br>
<br>
</blockquote>
<br>
I think we seperate this out into:<br>
<br>
1) we need to be security aware whenever we log information handed to<br>
us by the user. (I totally agree with this general statement)<br>
<br>
2) should we log structured data, non structured data or use the<br>
notification mechanism (which is structured)<br>
There have been some talks at summit about the potential merging of<br>
the logging and notification api, I honestly don't know what<br>
happened to that but have no problem with structured logging. We<br>
should use the notification system so that ceilometer can take<br>
advantage of the events.<br>
<br>
3) should we use a RequestContext in the spirit of the olso-incubator<br>
(and inherited from it too). OR one different from all other<br>
projects.<br>
<br>
IMHO we should just use oslo-incubator RequestContext. Remember the<br>
context is not a generic dumping ground for "I want to log stuff so<br>
lets put it into the context". It is for user credentials and things<br>
directly associated with the request (like the request_id). I don't<br>
see why we need a generic dict style approach, this is more likely<br>
to result in programming error context.set_priv('userid', bla)<br>
instead of:<br>
context.set_priv('user_id', bla)<br>
<br>
I think my point is: We should very quickly zero in on the<br>
attributes we need in the context and they will seldom change.<br>
<br>
As far as security goes Paul has shown a good example of how to<br>
change the logging_context_format_string to achieve structured and<br>
secure logging of the context. oslo log module does not log whatever<br>
is in the context but only what is configured in the solum.conf (via<br>
logging_context_format_string)<u></u>. So I don't believe that the<br>
new/different RequestContext provides any improved security.<br>
<br>
<br>
<br>
-Angus<br>
<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Adrian<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</blockquote>
<br>
<br>
<br>
-- <br>
Georgy Okrokvertskhov<br>
Architect,<br>
OpenStack Platform Products,<br>
Mirantis<br>
<a href="http://www.mirantis.com" target="_blank">http://www.mirantis.com</a><br>
Tel. <a href="tel:%2B1%20650%20963%209828" value="+16509639828" target="_blank">+1 650 963 9828</a><br>
Mob. <a href="tel:%2B1%20650%20996%203284" value="+16509963284" target="_blank">+1 650 996 3284</a><br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><font color="#999999"><span style="background-color:rgb(255,255,255)">Georgy Okrokvertskhov<br>
Architect,<br><span style="font-family:arial;font-size:small">OpenStack Platform Products,</span><br>
Mirantis</span><br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. +1 650 963 9828<br>
Mob. +1 650 996 3284</font><br></div>
</div>