Re: [openstack-dev] [oslo][nova] Anyone interested in writing a policy generator sphinx extension?

[Matt Riedemann]

On 9/26/2016 8:48 AM, Stephen Finucane wrote:

On Wed, 2016-09-21 at 11:16 -0400, Doug Hellmann wrote:

Excerpts from Matt Riedemann's message of 2016-09-21 09:49:29 -0500:


Nova has policy defaults in code now and we can generate the
sample
using oslopolicy-sample-generator but we'd like to get the default
policy sample in the Nova developer documentation also, like we
have for
nova.conf.sample.

I see we use the sphinxconfiggen extension for building the
nova.conf.sample in our docs, but I don't see anything like that
for
generating docs for a sample policy file.

Has anyone already started working on that, or is interested in
working
on that? I've never written a sphinx extension before but I'm
guessing
it could be borrowed a bit from how sphinxconfiggen was written in
oslo.config.



I don't have time to do it myself, but I can help get someone else
started and work with them on code reviews in oslo.policy.


I can take a look at this, though I'll only persue a "sphinxpolicygen"
module for now (we don't use oslo_config's "sphinxext" module yet).

Stephen

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Just to circle back on progress here, Stephen got things done and 
results can be seen here:


http://docs.openstack.org/developer/nova/sample_policy.html

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][nova] Anyone interested in writing a policy generator sphinx extension?

[Stephen Finucane]

On Wed, 2016-09-21 at 11:16 -0400, Doug Hellmann wrote:
> Excerpts from Matt Riedemann's message of 2016-09-21 09:49:29 -0500:
> > 
> > Nova has policy defaults in code now and we can generate the
> > sample 
> > using oslopolicy-sample-generator but we'd like to get the default 
> > policy sample in the Nova developer documentation also, like we
> > have for 
> > nova.conf.sample.
> > 
> > I see we use the sphinxconfiggen extension for building the 
> > nova.conf.sample in our docs, but I don't see anything like that
> > for 
> > generating docs for a sample policy file.
> > 
> > Has anyone already started working on that, or is interested in
> > working 
> > on that? I've never written a sphinx extension before but I'm
> > guessing 
> > it could be borrowed a bit from how sphinxconfiggen was written in 
> > oslo.config.
> > 
> 
> I don't have time to do it myself, but I can help get someone else
> started and work with them on code reviews in oslo.policy.

I can take a look at this, though I'll only persue a "sphinxpolicygen"
module for now (we don't use oslo_config's "sphinxext" module yet).

Stephen

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][nova] Anyone interested in writing a policy generator sphinx extension?

[Alexander Makarov]

Andrew,

the idea is to shift existing RBAC implementation:
currently policy is enforced in the service (Nova, for instance)
against the result of token validation, which is, in general, an access 
check;

I'm thinking about performing policy enforcement along with access check
in a single operation and only if necessary -
not every operation is protected and requires token validation,
though now keystone middleware validates a token on every request.

AFAIK Nova is using some custom logic to change local policies at run-time,
so I assume there may be a benefit in dynamic centralized storage 
managed via API,

so that Horizon can even provide a UI for that.

There are many questions in the matter, and my main is:
if we do RBAC in OpenStack the best way?


On 21.09.2016 20:16, Andrew Laski wrote:


On Wed, Sep 21, 2016, at 12:02 PM, Joshua Harlow wrote:

Andrew Laski wrote:

However, I have asked twice now on the review what the benefit of doing
this is and haven't received a response so I'll ask here. The proposal
would add additional latency to nearly every API operation in a service
and in return what do they get? Now that it's possible to register sane
policy defaults within a project most operators do not even need to
think about policy for projects that do that. And any policy changes
that are necessary are easily handled by a config management system.

I would expect to see a pretty significant benefit in exchange for
moving policy control out of Nova, and so far it's not clear to me what
that would be.

One way to do this is to setup something like etc.d or zookeeper and
have policy files be placed into certain 'keys' in there by keystone,
then consuming projects would 'watch' those keys for being changed (and
get notified when they are changed); the project would then reload its
policy when the other service (keystone) write a new key/policy.

https://coreos.com/etcd/docs/latest/api.html#waiting-for-a-change

or
https://zookeeper.apache.org/doc/r3.4.5/zookeeperProgrammers.html#ch_zkWatches

or (pretty sure consul has something similar),

This is pretty standard stuff folks :-/ and it's how afaik things like
https://github.com/skynetservices/skydns work (and more), and it would
avoid that 'additional latency' (unless the other service is adjusting
the policy key every millisecond, which seems sorta unreasonable).

Sure. Or have Keystone be a frontend for ansible/puppet/chef/ What's
not clear to me in any of this is what's the benefit to having Keystone
as a fronted to policy configuration/changes, or be involved in any real
way with authorization decisions? What issue is being solved by getting
Keystone involved?



-Josh

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][nova] Anyone interested in writing a policy generator sphinx extension?

[Mathieu Gagné]

Hi,

On Wed, Sep 21, 2016 at 10:49 AM, Matt Riedemann
 wrote:
> Nova has policy defaults in code now and we can generate the sample using
> oslopolicy-sample-generator but we'd like to get the default policy sample
> in the Nova developer documentation also, like we have for nova.conf.sample.
>
> I see we use the sphinxconfiggen extension for building the nova.conf.sample
> in our docs, but I don't see anything like that for generating docs for a
> sample policy file.
>
> Has anyone already started working on that, or is interested in working on
> that? I've never written a sphinx extension before but I'm guessing it could
> be borrowed a bit from how sphinxconfiggen was written in oslo.config.

I'm not a developer. I'm one of the operator that asked about
documentation now that policy defaults got moved in code.
I'm happy to see a proper follow up on this request, I really appreciate it. +1
I hope this thread can stay on topic so a proper documentation
solution is found.

Thanks

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][nova] Anyone interested in writing a policy generator sphinx extension?

[Andrew Laski]

On Wed, Sep 21, 2016, at 04:18 PM, Joshua Harlow wrote:
> Andrew Laski wrote:
> >
> > On Wed, Sep 21, 2016, at 03:18 PM, Joshua Harlow wrote:
> >> Andrew Laski wrote:
> >>> On Wed, Sep 21, 2016, at 12:02 PM, Joshua Harlow wrote:
>  Andrew Laski wrote:
> > However, I have asked twice now on the review what the benefit of doing
> > this is and haven't received a response so I'll ask here. The proposal
> > would add additional latency to nearly every API operation in a service
> > and in return what do they get? Now that it's possible to register sane
> > policy defaults within a project most operators do not even need to
> > think about policy for projects that do that. And any policy changes
> > that are necessary are easily handled by a config management system.
> >
> > I would expect to see a pretty significant benefit in exchange for
> > moving policy control out of Nova, and so far it's not clear to me what
> > that would be.
>  One way to do this is to setup something like etc.d or zookeeper and
>  have policy files be placed into certain 'keys' in there by keystone,
>  then consuming projects would 'watch' those keys for being changed (and
>  get notified when they are changed); the project would then reload its
>  policy when the other service (keystone) write a new key/policy.
> 
>  https://coreos.com/etcd/docs/latest/api.html#waiting-for-a-change
> 
>  or
>  https://zookeeper.apache.org/doc/r3.4.5/zookeeperProgrammers.html#ch_zkWatches
> 
>  or (pretty sure consul has something similar),
> 
>  This is pretty standard stuff folks :-/ and it's how afaik things like
>  https://github.com/skynetservices/skydns work (and more), and it would
>  avoid that 'additional latency' (unless the other service is adjusting
>  the policy key every millisecond, which seems sorta unreasonable).
> >>> Sure. Or have Keystone be a frontend for ansible/puppet/chef/ What's
> >>> not clear to me in any of this is what's the benefit to having Keystone
> >>> as a fronted to policy configuration/changes, or be involved in any real
> >>> way with authorization decisions? What issue is being solved by getting
> >>> Keystone involved?
> >>>
> >> I don't understand the puppet/chef connection, can u clarify.
> >>
> >> If I'm interpreting it right, I would assume it's the same reason that
> >> something like 'skydns' exists over etcd; to provide a useful API that
> >> focuses on the dns particulars that etcd will of course not have any
> >> idea about. So I guess the keystone API could(?)/would(?) then focus on
> >> policy particulars as its value-add.
> >>
> >> Maybe now I understand what u mean by puppet/chef, in that you are
> >> asking why isn't skydns (for example) just letting/invoking
> >> puppet/chef/ansible to distribute/send-out dns (dnsmasq) files? Is that
> >> your equivalent question?
> >
> > I'm focused on Nova/Keystone/OpenStack here, I'm sure skydns has good
> > reasons for their technical choices and I'm in no place to question
> > them.
> >
> > I'm trying to understand the value-add that Keystone could provide here.
> > Policy configuration is fairly static so I'm not understanding the
> > desire to put an API on top of it. But perhaps I'm missing the use case
> > here which is why I've been asking.
> >
> > My ansible/puppet/chef comparison was just that those are ways to
> > distribute static files and would work just as well as something built
> > on top of etcd/zookeeper. I'm not really concerned about how it's
> > implemented though. I'm just trying to understand if the desire is to
> > have Keystone handle this so that deployers don't need to work with
> > their configuration management system to configure policy files, or is
> > there something more here?
> >
> >
> 
> Gotcha, thanks for explaining.
> 
> I'll let others comment, but my semi-useful/semi-baked thoughts around 
> this are as a user I would want to:
> 
> #1 Can I query keystone (or perhaps I should ask nova) to show me what 
> (all the) APIs in nova I'm allowed to call (without actually having to 
> perform those same calls to figure it out); ie, tell me how my known 
> role/user/tenant in  maps to the policy stored (somewhere in 
> some project) so I can make smart decisions around which APIs I can be 
> calling.

So we are actually looking at implementing this in Nova, and Cinder is
looking at something similar. However a key difference is that what you
as a user are allowed to do is dependent on more than just policy. So
"capabilities" (what we're calling it in Nova) will return what you're
allowed to do based on policy, hypervisor versions, flavor used, etc...

A challenge with doing this in Keystone is that there's no way for
Keystone to map the policies to the API calls in Nova. Frankly we don't
have a way to do that in Nova either :) But we do have a tool for
exposing the list of policies that you will pass

Re: [openstack-dev] [oslo][nova] Anyone interested in writing a policy generator sphinx extension?

[Joshua Harlow]

Andrew Laski wrote:


On Wed, Sep 21, 2016, at 03:18 PM, Joshua Harlow wrote:

Andrew Laski wrote:

On Wed, Sep 21, 2016, at 12:02 PM, Joshua Harlow wrote:

Andrew Laski wrote:

However, I have asked twice now on the review what the benefit of doing
this is and haven't received a response so I'll ask here. The proposal
would add additional latency to nearly every API operation in a service
and in return what do they get? Now that it's possible to register sane
policy defaults within a project most operators do not even need to
think about policy for projects that do that. And any policy changes
that are necessary are easily handled by a config management system.

I would expect to see a pretty significant benefit in exchange for
moving policy control out of Nova, and so far it's not clear to me what
that would be.

One way to do this is to setup something like etc.d or zookeeper and
have policy files be placed into certain 'keys' in there by keystone,
then consuming projects would 'watch' those keys for being changed (and
get notified when they are changed); the project would then reload its
policy when the other service (keystone) write a new key/policy.

https://coreos.com/etcd/docs/latest/api.html#waiting-for-a-change

or
https://zookeeper.apache.org/doc/r3.4.5/zookeeperProgrammers.html#ch_zkWatches

or (pretty sure consul has something similar),

This is pretty standard stuff folks :-/ and it's how afaik things like
https://github.com/skynetservices/skydns work (and more), and it would
avoid that 'additional latency' (unless the other service is adjusting
the policy key every millisecond, which seems sorta unreasonable).

Sure. Or have Keystone be a frontend for ansible/puppet/chef/ What's
not clear to me in any of this is what's the benefit to having Keystone
as a fronted to policy configuration/changes, or be involved in any real
way with authorization decisions? What issue is being solved by getting
Keystone involved?


I don't understand the puppet/chef connection, can u clarify.

If I'm interpreting it right, I would assume it's the same reason that
something like 'skydns' exists over etcd; to provide a useful API that
focuses on the dns particulars that etcd will of course not have any
idea about. So I guess the keystone API could(?)/would(?) then focus on
policy particulars as its value-add.

Maybe now I understand what u mean by puppet/chef, in that you are
asking why isn't skydns (for example) just letting/invoking
puppet/chef/ansible to distribute/send-out dns (dnsmasq) files? Is that
your equivalent question?


I'm focused on Nova/Keystone/OpenStack here, I'm sure skydns has good
reasons for their technical choices and I'm in no place to question
them.

I'm trying to understand the value-add that Keystone could provide here.
Policy configuration is fairly static so I'm not understanding the
desire to put an API on top of it. But perhaps I'm missing the use case
here which is why I've been asking.

My ansible/puppet/chef comparison was just that those are ways to
distribute static files and would work just as well as something built
on top of etcd/zookeeper. I'm not really concerned about how it's
implemented though. I'm just trying to understand if the desire is to
have Keystone handle this so that deployers don't need to work with
their configuration management system to configure policy files, or is
there something more here?




Gotcha, thanks for explaining.

I'll let others comment, but my semi-useful/semi-baked thoughts around 
this are as a user I would want to:


#1 Can I query keystone (or perhaps I should ask nova) to show me what 
(all the) APIs in nova I'm allowed to call (without actually having to 
perform those same calls to figure it out); ie, tell me how my known 
role/user/tenant in  maps to the policy stored (somewhere in 
some project) so I can make smart decisions around which APIs I can be 
calling.


#2 Can I go to one place (the same place that has my roles and tenants 
and such?) and ensure that by changing roles or such that dependent 
systems that may have meanings for those roles are not adversely 
affected (or say makes a policy being used become invalid, ie similar to 
a error saying 'the change you have requested violates the rules defined 
in 'nova policy' and therefore is invalid and can't be applied').


The #1 kind of use-case of course would be really easy if keystone has 
the knowledge of each projects 'policy.json' (or equivalent data 
structure); and since keystone already has the role/user/tenant 
information it would be straightforward to solve #2 there as well 
(because keystone could reject a role change or tenancy change or user 
change or ... if it negatively/violates affects some projects policy).


Of course if u distribute the policy information then each project would 
have to implement #1 and there would need to be some 2 way mechanism to 
ensure #2 happens correctly (because if keystone just blindly does 
role/user/tenant changes it 

Re: [openstack-dev] [oslo][nova] Anyone interested in writing a policy generator sphinx extension?

[Andrew Laski]

On Wed, Sep 21, 2016, at 03:18 PM, Joshua Harlow wrote:
> Andrew Laski wrote:
> >
> > On Wed, Sep 21, 2016, at 12:02 PM, Joshua Harlow wrote:
> >> Andrew Laski wrote:
> >>> However, I have asked twice now on the review what the benefit of doing
> >>> this is and haven't received a response so I'll ask here. The proposal
> >>> would add additional latency to nearly every API operation in a service
> >>> and in return what do they get? Now that it's possible to register sane
> >>> policy defaults within a project most operators do not even need to
> >>> think about policy for projects that do that. And any policy changes
> >>> that are necessary are easily handled by a config management system.
> >>>
> >>> I would expect to see a pretty significant benefit in exchange for
> >>> moving policy control out of Nova, and so far it's not clear to me what
> >>> that would be.
> >> One way to do this is to setup something like etc.d or zookeeper and
> >> have policy files be placed into certain 'keys' in there by keystone,
> >> then consuming projects would 'watch' those keys for being changed (and
> >> get notified when they are changed); the project would then reload its
> >> policy when the other service (keystone) write a new key/policy.
> >>
> >> https://coreos.com/etcd/docs/latest/api.html#waiting-for-a-change
> >>
> >> or
> >> https://zookeeper.apache.org/doc/r3.4.5/zookeeperProgrammers.html#ch_zkWatches
> >>
> >> or (pretty sure consul has something similar),
> >>
> >> This is pretty standard stuff folks :-/ and it's how afaik things like
> >> https://github.com/skynetservices/skydns work (and more), and it would
> >> avoid that 'additional latency' (unless the other service is adjusting
> >> the policy key every millisecond, which seems sorta unreasonable).
> >
> > Sure. Or have Keystone be a frontend for ansible/puppet/chef/ What's
> > not clear to me in any of this is what's the benefit to having Keystone
> > as a fronted to policy configuration/changes, or be involved in any real
> > way with authorization decisions? What issue is being solved by getting
> > Keystone involved?
> >
> 
> I don't understand the puppet/chef connection, can u clarify.
> 
> If I'm interpreting it right, I would assume it's the same reason that 
> something like 'skydns' exists over etcd; to provide a useful API that 
> focuses on the dns particulars that etcd will of course not have any 
> idea about. So I guess the keystone API could(?)/would(?) then focus on 
> policy particulars as its value-add.
> 
> Maybe now I understand what u mean by puppet/chef, in that you are 
> asking why isn't skydns (for example) just letting/invoking 
> puppet/chef/ansible to distribute/send-out dns (dnsmasq) files? Is that 
> your equivalent question?

I'm focused on Nova/Keystone/OpenStack here, I'm sure skydns has good
reasons for their technical choices and I'm in no place to question
them.

I'm trying to understand the value-add that Keystone could provide here.
Policy configuration is fairly static so I'm not understanding the
desire to put an API on top of it. But perhaps I'm missing the use case
here which is why I've been asking.

My ansible/puppet/chef comparison was just that those are ways to
distribute static files and would work just as well as something built
on top of etcd/zookeeper. I'm not really concerned about how it's
implemented though. I'm just trying to understand if the desire is to
have Keystone handle this so that deployers don't need to work with
their configuration management system to configure policy files, or is
there something more here?


> 
> -Josh
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][nova] Anyone interested in writing a policy generator sphinx extension?

[Joshua Harlow]

Andrew Laski wrote:


On Wed, Sep 21, 2016, at 12:02 PM, Joshua Harlow wrote:

Andrew Laski wrote:

However, I have asked twice now on the review what the benefit of doing
this is and haven't received a response so I'll ask here. The proposal
would add additional latency to nearly every API operation in a service
and in return what do they get? Now that it's possible to register sane
policy defaults within a project most operators do not even need to
think about policy for projects that do that. And any policy changes
that are necessary are easily handled by a config management system.

I would expect to see a pretty significant benefit in exchange for
moving policy control out of Nova, and so far it's not clear to me what
that would be.

One way to do this is to setup something like etc.d or zookeeper and
have policy files be placed into certain 'keys' in there by keystone,
then consuming projects would 'watch' those keys for being changed (and
get notified when they are changed); the project would then reload its
policy when the other service (keystone) write a new key/policy.

https://coreos.com/etcd/docs/latest/api.html#waiting-for-a-change

or
https://zookeeper.apache.org/doc/r3.4.5/zookeeperProgrammers.html#ch_zkWatches

or (pretty sure consul has something similar),

This is pretty standard stuff folks :-/ and it's how afaik things like
https://github.com/skynetservices/skydns work (and more), and it would
avoid that 'additional latency' (unless the other service is adjusting
the policy key every millisecond, which seems sorta unreasonable).


Sure. Or have Keystone be a frontend for ansible/puppet/chef/ What's
not clear to me in any of this is what's the benefit to having Keystone
as a fronted to policy configuration/changes, or be involved in any real
way with authorization decisions? What issue is being solved by getting
Keystone involved?



I don't understand the puppet/chef connection, can u clarify.

If I'm interpreting it right, I would assume it's the same reason that 
something like 'skydns' exists over etcd; to provide a useful API that 
focuses on the dns particulars that etcd will of course not have any 
idea about. So I guess the keystone API could(?)/would(?) then focus on 
policy particulars as its value-add.


Maybe now I understand what u mean by puppet/chef, in that you are 
asking why isn't skydns (for example) just letting/invoking 
puppet/chef/ansible to distribute/send-out dns (dnsmasq) files? Is that 
your equivalent question?


-Josh

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][nova] Anyone interested in writing a policy generator sphinx extension?

[Andrew Laski]

On Wed, Sep 21, 2016, at 12:02 PM, Joshua Harlow wrote:
> Andrew Laski wrote:
> > However, I have asked twice now on the review what the benefit of doing
> > this is and haven't received a response so I'll ask here. The proposal
> > would add additional latency to nearly every API operation in a service
> > and in return what do they get? Now that it's possible to register sane
> > policy defaults within a project most operators do not even need to
> > think about policy for projects that do that. And any policy changes
> > that are necessary are easily handled by a config management system.
> >
> > I would expect to see a pretty significant benefit in exchange for
> > moving policy control out of Nova, and so far it's not clear to me what
> > that would be.
> 
> One way to do this is to setup something like etc.d or zookeeper and 
> have policy files be placed into certain 'keys' in there by keystone, 
> then consuming projects would 'watch' those keys for being changed (and 
> get notified when they are changed); the project would then reload its 
> policy when the other service (keystone) write a new key/policy.
> 
> https://coreos.com/etcd/docs/latest/api.html#waiting-for-a-change
> 
> or 
> https://zookeeper.apache.org/doc/r3.4.5/zookeeperProgrammers.html#ch_zkWatches
> 
> or (pretty sure consul has something similar),
> 
> This is pretty standard stuff folks :-/ and it's how afaik things like 
> https://github.com/skynetservices/skydns work (and more), and it would 
> avoid that 'additional latency' (unless the other service is adjusting 
> the policy key every millisecond, which seems sorta unreasonable).

Sure. Or have Keystone be a frontend for ansible/puppet/chef/ What's
not clear to me in any of this is what's the benefit to having Keystone
as a fronted to policy configuration/changes, or be involved in any real
way with authorization decisions? What issue is being solved by getting
Keystone involved?


> 
> -Josh
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][nova] Anyone interested in writing a policy generator sphinx extension?

[Joshua Harlow]

Andrew Laski wrote:

However, I have asked twice now on the review what the benefit of doing
this is and haven't received a response so I'll ask here. The proposal
would add additional latency to nearly every API operation in a service
and in return what do they get? Now that it's possible to register sane
policy defaults within a project most operators do not even need to
think about policy for projects that do that. And any policy changes
that are necessary are easily handled by a config management system.

I would expect to see a pretty significant benefit in exchange for
moving policy control out of Nova, and so far it's not clear to me what
that would be.


One way to do this is to setup something like etc.d or zookeeper and 
have policy files be placed into certain 'keys' in there by keystone, 
then consuming projects would 'watch' those keys for being changed (and 
get notified when they are changed); the project would then reload its 
policy when the other service (keystone) write a new key/policy.


https://coreos.com/etcd/docs/latest/api.html#waiting-for-a-change

or 
https://zookeeper.apache.org/doc/r3.4.5/zookeeperProgrammers.html#ch_zkWatches


or (pretty sure consul has something similar),

This is pretty standard stuff folks :-/ and it's how afaik things like 
https://github.com/skynetservices/skydns work (and more), and it would 
avoid that 'additional latency' (unless the other service is adjusting 
the policy key every millisecond, which seems sorta unreasonable).


-Josh

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][nova] Anyone interested in writing a policy generator sphinx extension?

[Andrew Laski]

On Wed, Sep 21, 2016, at 11:05 AM, Alexander Makarov wrote:
> What if policy will be manageable using RESTful API?
> I'd like to validate the idea to handle policies in keystone or 
> affiliated service: https://review.openstack.org/#/c/325326/

As Matt said, that's unrelated to what he's asking about.

However, I have asked twice now on the review what the benefit of doing
this is and haven't received a response so I'll ask here. The proposal
would add additional latency to nearly every API operation in a service
and in return what do they get? Now that it's possible to register sane
policy defaults within a project most operators do not even need to
think about policy for projects that do that. And any policy changes
that are necessary are easily handled by a config management system.

I would expect to see a pretty significant benefit in exchange for
moving policy control out of Nova, and so far it's not clear to me what
that would be.


> 
> On 21.09.2016 17:49, Matt Riedemann wrote:
> > Nova has policy defaults in code now and we can generate the sample 
> > using oslopolicy-sample-generator but we'd like to get the default 
> > policy sample in the Nova developer documentation also, like we have 
> > for nova.conf.sample.
> >
> > I see we use the sphinxconfiggen extension for building the 
> > nova.conf.sample in our docs, but I don't see anything like that for 
> > generating docs for a sample policy file.
> >
> > Has anyone already started working on that, or is interested in 
> > working on that? I've never written a sphinx extension before but I'm 
> > guessing it could be borrowed a bit from how sphinxconfiggen was 
> > written in oslo.config.
> >
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][nova] Anyone interested in writing a policy generator sphinx extension?

[Doug Hellmann]

Excerpts from Matt Riedemann's message of 2016-09-21 09:49:29 -0500:
> Nova has policy defaults in code now and we can generate the sample 
> using oslopolicy-sample-generator but we'd like to get the default 
> policy sample in the Nova developer documentation also, like we have for 
> nova.conf.sample.
> 
> I see we use the sphinxconfiggen extension for building the 
> nova.conf.sample in our docs, but I don't see anything like that for 
> generating docs for a sample policy file.
> 
> Has anyone already started working on that, or is interested in working 
> on that? I've never written a sphinx extension before but I'm guessing 
> it could be borrowed a bit from how sphinxconfiggen was written in 
> oslo.config.
> 

I don't have time to do it myself, but I can help get someone else
started and work with them on code reviews in oslo.policy.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][nova] Anyone interested in writing a policy generator sphinx extension?

[Matt Riedemann]

On 9/21/2016 10:05 AM, Alexander Makarov wrote:

What if policy will be manageable using RESTful API?
I'd like to validate the idea to handle policies in keystone or
affiliated service: https://review.openstack.org/#/c/325326/

On 21.09.2016 17:49, Matt Riedemann wrote:

Nova has policy defaults in code now and we can generate the sample
using oslopolicy-sample-generator but we'd like to get the default
policy sample in the Nova developer documentation also, like we have
for nova.conf.sample.

I see we use the sphinxconfiggen extension for building the
nova.conf.sample in our docs, but I don't see anything like that for
generating docs for a sample policy file.

Has anyone already started working on that, or is interested in
working on that? I've never written a sphinx extension before but I'm
guessing it could be borrowed a bit from how sphinxconfiggen was
written in oslo.config.




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



I'm not sure how that's related to what I'm asking for here. We have 
policy defaults in code, and we want to generate those defaults into a 
sample policy file and have that in the docs. Sure the policy can be 
changed and customized later, but this isn't about that (or how that is 
done), it's just about documenting the default policy since the 
policy.json that ships in the nova tree now is empty. So we want to 
document the defaults, same as nova.conf.sample.


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][nova] Anyone interested in writing a policy generator sphinx extension?

[Alexander Makarov]

What if policy will be manageable using RESTful API?
I'd like to validate the idea to handle policies in keystone or 
affiliated service: https://review.openstack.org/#/c/325326/


On 21.09.2016 17:49, Matt Riedemann wrote:
Nova has policy defaults in code now and we can generate the sample 
using oslopolicy-sample-generator but we'd like to get the default 
policy sample in the Nova developer documentation also, like we have 
for nova.conf.sample.


I see we use the sphinxconfiggen extension for building the 
nova.conf.sample in our docs, but I don't see anything like that for 
generating docs for a sample policy file.


Has anyone already started working on that, or is interested in 
working on that? I've never written a sphinx extension before but I'm 
guessing it could be borrowed a bit from how sphinxconfiggen was 
written in oslo.config.





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [oslo][nova] Anyone interested in writing a policy generator sphinx extension?

[Matt Riedemann]

Nova has policy defaults in code now and we can generate the sample 
using oslopolicy-sample-generator but we'd like to get the default 
policy sample in the Nova developer documentation also, like we have for 
nova.conf.sample.


I see we use the sphinxconfiggen extension for building the 
nova.conf.sample in our docs, but I don't see anything like that for 
generating docs for a sample policy file.


Has anyone already started working on that, or is interested in working 
on that? I've never written a sphinx extension before but I'm guessing 
it could be borrowed a bit from how sphinxconfiggen was written in 
oslo.config.


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev