[openstack-dev] [release][kolla] Announcing release of Kolla Mitaka rc3

[Steven Dake (stdake)]

Hey folks,

We did a bangup job in the last 7 days fixing 25 bugs in Kolla.  Our weekly 
capacity to solve bugs as a community is 25-30 bugs.  Our final deadline is 
April 8th.

Targeted for 2.0.0 (April 8tih) are currently 22 bugs.  Many of these don't 
have owners, so if you want to contribute, please help by assigning yourself a 
bug and fixing it.

https://launchpad.net/kolla/+milestone/2.0.0

Note we are following the standard OpenStack backport process for Newton bugs 
also in Mitaka, so please don't be concerned about backports, we will have the 
core reviewer team handling those unless there is a merge conflict.

Regards
-steve

__
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] Announcing release of Kolla Mitaka rc3

[Steven Dake (stdake)]

Hey folks,

We did a bangup job in the last 7 days fixing 25 bugs in Kolla.  Our weekly 
capacity to solve bugs as a community is 25-30 bugs.  Our final deadline is 
April 8th.

Targeted for 2.0.0 (April 8tih) are currently 22 bugs.  Many of these don't 
have owners, so if you want to contribute, please help by assigning yourself a 
bug and fixing it.

https://launchpad.net/kolla/+milestone/2.0.0

Note we are following the standard OpenStack backport process for Newton bugs 
also in Mitaka, so please don't be concerned about backports, we will have the 
core reviewer team handling those unless there is a merge conflict.

Regards
-steve

__
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] [TripleO] FreeIPA integration

[Adam Young]

I finally have enough understanding of what is going on with Tripleo to 
reasonably discuss how to implement solutions for some of the main 
security needs of a deployment.



FreeIPA is an identity management solution that can provide support for:

1. TLS on all network communications:
   A. HTTPS for web services
   B. TLS for the message bus
   C. TLS for communication with the Database.
2. Identity for all Actors in the system:
  A.  API services
  B.  Message producers and consumers
  C.  Database consumers
  D.  Keystone service users
3. Secure  DNS DNSSEC
4. Federation Support
5. SSH Access control to Hosts for both undercloud and overcloud
6. SUDO management
7. Single Sign On for Applications running in the overcloud.


The main pieces of FreeIPA are
1. LDAP (the 389 Directory Server)
2. Kerberos
3. DNS (BIND)
4. Certificate Authority (CA) server (Dogtag)
5. WebUI/Web Service Management Interface (HTTPD)

Of these, the CA is the most critical.  Without a centralized CA, we 
have no reasonable way to do certificate management.


Now, I know a lot of people have an allergic reaction to some, maybe 
all, of these technologies. They should not be required to be running in 
a development or testbed setup.  But we need to make it possible to 
secure an end deployment, and FreeIPA was designed explicitly for these 
kinds of distributed applications.  Here is what I would like to implement.


Assuming that the Undercloud is installed on a physical machine, we want 
to treat the FreeIPA server as a managed service of the undercloud that 
is then consumed by the rest of the overcloud. Right now, there are 
conflicts for some ports (8080 used by both swift and Dogtag) that 
prevent a drop-in run of the server on the undercloud controller.  Even 
if we could deconflict, there is a possible battle between Keystone and 
the FreeIPA server on the undercloud.  So, while I would like to see the 
ability to run the FreeIPA server on the Undercloud machine eventuall, I 
think a more realistic deployment is to build a separate virtual 
machine, parallel to the overcloud controller, and install FreeIPA 
there. I've been able to modify Tripleo Quickstart to provision this VM.


I was also able to run FreeIPA in a container on the undercloud machine, 
but this is, I think, not how we want to migrate to a container based 
strategy. It should be more deliberate.



While the ideal setup would be to install the IPA layer first, and 
create service users in there, this produces a different install path 
between with-FreeIPA and without-FreeIPA. Thus, I suspect the right 
approach is to run the overcloud deploy, then "harden" the deployment 
with the FreeIPA steps.



The IdM team did just this last summer in preparing for the Tokyo 
summit, using Ansible and Packstack.  The Rippowam project 
https://github.com/admiyo/rippowam was able to fully lock down a 
Packstack based install.  I'd like to reuse as much of Rippowam as 
possible, but called from Heat Templates as part of an overcloud 
deploy.  I do not really want to re implement Rippowam in Puppet.


So, big question: is Heat->ansible (instead of Puppet) for an overcloud 
deployment an acceptable path?  We are talking Ansible 1.0 Playbooks, 
which should be relatively straightforward ports to 2.0 when the time comes.


Thus, the sequence would be:

1. Run existing overcloud deploy steps.
2. Install IPA server on the allocated VM
3. Register the compute nodes and the controller as IPA clients
4. Convert service users over to LDAP backed services, complete with 
necessary kerberos steps to do password-less authentication.
5. Register all web services with IPA and allocate X509 certificates for 
HTTPS.
6. Set up Host based access control (HBAC) rules for SSH access to 
overcloud machines.



When we did the Rippowam demo, we used the Proton driver and Kerberos 
for securing the message broker.  Since Rabbit seems to be the tool of 
choice,  we would use X509 authentication and TLS for encryption.  ACLs, 
for now, would stay in the flat file format.  In the future, we might 
chose to use the LDAP backed ACLs for Rabbit, as they seem far more 
flexible.  Rabbit does not currently support Kerberos for either 
authentication or encryption, but we can engage the upstream team to 
implement it if desired in the future, or we can shift to a Proton based 
deployment if Kerberos is essential for a deployment.



There are a couple ongoing efforts that will tie in with this:

1. Designate should be able to use the DNS from FreeIPA.  That was the 
original implementation.


2.  Juan Antonio Osorio  has been working on TLS everywhere.  The issue 
thus far has been Certificate management.  This provides a Dogtag server 
for Certs.


3. Rob Crittenden has been working on auto-registration of virtual 
machines with an Identity Provider upon launch.  This gives that efforts 
an IdM to use.


4. Keystone can make use of the Identity store for administrative users 
in their own domain.


5. 

Re: [openstack-dev] [tc][kolla] Change to kolla's release model to gain access to release's website marketing

[Steven Dake (stdake)]

On 4/2/16, 1:08 PM, "Doug Hellmann"  wrote:

>
>> On Apr 2, 2016, at 1:20 PM, Steven Dake (stdake) 
>>wrote:
>> 
>> A big correction to this thread below.
>> 
>> On 4/2/16, 10:05 AM, "Steven Dake (stdake)"  wrote:
>> 
>>> 
>>> 
>>> On 4/2/16, 10:01 AM, "Jeremy Stanley"  wrote:
>>> 
 On 2016-04-02 16:13:28 + (+), Steven Dake (stdake) wrote:
 [...]
> I feel as though we are not permitted to participate in the
> marketing that takes place on the releases website
 [...]
 
 I'll refrain from commenting on the rest since I'm not a member of
 the release team, but I *seriously* hope we've not created a
 "marketing" portal simply by way of tracking version numbers,
 changelogs and release schedules. I have a feeling few (if any) of
 the release team wants to get into the marketing business and I'm
 happy to help do whatever is in my power to neuter the "marketing
 potential" for releases.openstack.org so it can be viewed simply as
 a source of _objective_ technical data.
 --
>>> 
>>> It is objective technical data, but atm we are excluded, and people
>>>look
>>> at that objective technical data (like marketing and sales folks) to
>>>make
>>> decisions, so it is by its very nature a marketing resource as well.
>>>If
>>> we are excluded, sales and marketing folks that make decisions about
>>> OpenStack deployments may come along and say "not on the website, not
>>> legitimate".
>> 
>> release:independent projects are rendered on this website [1], and ttx's
>> review comment was more to put kolla in releases:independent of the
>> releases repo rather then the mitaka location [1].  I misunderstood
>>ttx's
>> comments to mean we were completely excluded which is not the case.
>
>Right, we just need it filed under the right directory.

Note I submitted a change [1] to clarify this - since it wasn't
documented.  But I'm glad dims was able to reach out to me on irc to
clarify the situation.  Thanks dims!

>
>> 
>> That said, release:cycle-with-milestones is still what we want :)
>
>The model change can be approved and applied to Newton. During Newton
>we¹ll figure out how to communicate about projects that have changed
>their tags ‹ we don¹t want to rewrite history for old releases but we
>don¹t want it to be hard for users to find full project history. I have
>some ideas to handle it but I¹m waiting until after the summit to
>implement them.

Sounds good.  I understand now is not the optimal time to request such
changes to how the releases repository works.  I hope the outcome is that
projects that were really following release:cycle-with* have an
opportunity to be marked in the appropriate place even if it does mean
rewriting history, since our intent with our big tent application wasn't
for our projects to be marked as "independent" on the releases website.  I
believe the intent of the project is what matters most and we clearly
followed the release cycle pretty closely in Liberty and Mitaka (with the
exception of a dental medical emergency which almost killed me :(which
made our tagging late for one milestone).

At the time of our big tent application there was no releases website, or
we would have definitely chosen release-with-intermeditary.  Unfortunately
that warning wasn¹t there at the time and we can't fix the past, so Newton
it is :)

You can see from my PTL candidacy for Mitaka [2] that I was keen to have
the release:managed tag back then, and that applies even more so now.

Regards,
-steve

[1] https://review.openstack.org/300823
[2] 
https://github.com/openstack/election/blob/master/candidates/mitaka/Kolla/S
teven_Dake.txt#L35
Regards
-steve

>
>Doug
>
>> 
>> I'd ask people cut me a little slack on this, I am new to the
>> openstack/releases repository ;)
>> 
>> [1] http://releases.openstack.org/independent.html
>> [2] https://review.openstack.org/#/c/297976/
>>> 
>>> Regards
>>> -steve
>>> 
 
 Jeremy Stanley
 
 
___
__
 _
 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] Acknowledging Jim Blair's work on the TC

[Doug Hellmann]

> On Apr 1, 2016, at 3:06 PM, Anita Kuno  wrote:
> 
> Jim is an incumbent on the TC this election and he didn't run. I'm
> posting this to express my thanks to Jim for his work and dedication on
> the TC.
> 
> Jim, I think your commitment to open source, spanning many years before
> OpenStack, and your dedication to governance process, are qualities I
> admire very much and I'm grateful you were able to voice your opinions
> on the TC from October 2013 until now.
> 
> Thank you for taking your turn and thank you as well for allowing others
> a chance to take theirs.
> 
> Thank you, Jim,
> Anita.

Nicely put. I also appreciate that Jim’s perspective is often different from my 
own initial reaction to a situation. As a result, I’ve learned a lot by serving 
on the TC with him.

Thanks, Jim!

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] [tc][kolla] Change to kolla's release model to gain access to release's website marketing

[Doug Hellmann]

> On Apr 2, 2016, at 1:20 PM, Steven Dake (stdake)  wrote:
> 
> A big correction to this thread below.
> 
> On 4/2/16, 10:05 AM, "Steven Dake (stdake)"  wrote:
> 
>> 
>> 
>> On 4/2/16, 10:01 AM, "Jeremy Stanley"  wrote:
>> 
>>> On 2016-04-02 16:13:28 + (+), Steven Dake (stdake) wrote:
>>> [...]
 I feel as though we are not permitted to participate in the
 marketing that takes place on the releases website
>>> [...]
>>> 
>>> I'll refrain from commenting on the rest since I'm not a member of
>>> the release team, but I *seriously* hope we've not created a
>>> "marketing" portal simply by way of tracking version numbers,
>>> changelogs and release schedules. I have a feeling few (if any) of
>>> the release team wants to get into the marketing business and I'm
>>> happy to help do whatever is in my power to neuter the "marketing
>>> potential" for releases.openstack.org so it can be viewed simply as
>>> a source of _objective_ technical data.
>>> --
>> 
>> It is objective technical data, but atm we are excluded, and people look
>> at that objective technical data (like marketing and sales folks) to make
>> decisions, so it is by its very nature a marketing resource as well.  If
>> we are excluded, sales and marketing folks that make decisions about
>> OpenStack deployments may come along and say "not on the website, not
>> legitimate".
> 
> release:independent projects are rendered on this website [1], and ttx's
> review comment was more to put kolla in releases:independent of the
> releases repo rather then the mitaka location [1].  I misunderstood ttx's
> comments to mean we were completely excluded which is not the case.

Right, we just need it filed under the right directory.

> 
> That said, release:cycle-with-milestones is still what we want :)

The model change can be approved and applied to Newton. During Newton we’ll 
figure out how to communicate about projects that have changed their tags — we 
don’t want to rewrite history for old releases but we don’t want it to be hard 
for users to find full project history. I have some ideas to handle it but I’m 
waiting until after the summit to implement them.

Doug

> 
> I'd ask people cut me a little slack on this, I am new to the
> openstack/releases repository ;)
> 
> [1] http://releases.openstack.org/independent.html
> [2] https://review.openstack.org/#/c/297976/
>> 
>> Regards
>> -steve
>> 
>>> 
>>> Jeremy Stanley
>>> 
>>> _
>>> _
>>> 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


__
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] [tc][kolla] Change to kolla's release model to gain access to release's website marketing

[Doug Hellmann]

> On Apr 2, 2016, at 1:01 PM, Jeremy Stanley  wrote:
> 
> On 2016-04-02 16:13:28 + (+), Steven Dake (stdake) wrote:
> [...]
>> I feel as though we are not permitted to participate in the
>> marketing that takes place on the releases website
> [...]
> 
> I'll refrain from commenting on the rest since I'm not a member of
> the release team, but I *seriously* hope we've not created a
> "marketing" portal simply by way of tracking version numbers,
> changelogs and release schedules. I have a feeling few (if any) of
> the release team wants to get into the marketing business and I'm
> happy to help do whatever is in my power to neuter the "marketing
> potential" for releases.openstack.org so it can be viewed simply as
> a source of _objective_ technical data.

That’s the idea, though there will be some inevitable marketing side-effects.

We have been trying to be strict with having projects declare their release 
tags early in the cycle [1] so that we can point to the releases site as 
clearly communicating a team’s intent so that users know what to expect. This 
was the first cycle where there were any real ramifications to choosing the 
“wrong” release model, and we’ve had discussions with a few teams throughout 
the cycle and more recently I proposed a warning to the documentation for the 
independent model tag specifically about that [2].

The situation is similar to the projects we’ve had that didn’t actually build a 
release artifact. Since we can’t point to a release, it’s not clear to end 
users that they *did* release.

Anyway, this is all relatively new, so we expected some issues. We’re dealing 
with them on a case-by-case basis, trying to be flexible but at the same time 
trying to ensure we’re not watering down any of the declarations and all with 
the understanding that if a team is unhappy with the outcome for Mitaka it can 
be fixed for Newton (hint: teams that want to change their release model for 
Newton should submit the governance patch to do that now).

Doug

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-January/083726.html
[2] https://review.openstack.org/#/c/299309/
__
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] [tc][kolla] Change to kolla's release model to gain access to release's website marketing

[Steven Dake (stdake)]

A big correction to this thread below.

On 4/2/16, 10:05 AM, "Steven Dake (stdake)"  wrote:

>
>
>On 4/2/16, 10:01 AM, "Jeremy Stanley"  wrote:
>
>>On 2016-04-02 16:13:28 + (+), Steven Dake (stdake) wrote:
>>[...]
>>> I feel as though we are not permitted to participate in the
>>> marketing that takes place on the releases website
>>[...]
>>
>>I'll refrain from commenting on the rest since I'm not a member of
>>the release team, but I *seriously* hope we've not created a
>>"marketing" portal simply by way of tracking version numbers,
>>changelogs and release schedules. I have a feeling few (if any) of
>>the release team wants to get into the marketing business and I'm
>>happy to help do whatever is in my power to neuter the "marketing
>>potential" for releases.openstack.org so it can be viewed simply as
>>a source of _objective_ technical data.
>>--
>
>It is objective technical data, but atm we are excluded, and people look
>at that objective technical data (like marketing and sales folks) to make
>decisions, so it is by its very nature a marketing resource as well.  If
>we are excluded, sales and marketing folks that make decisions about
>OpenStack deployments may come along and say "not on the website, not
>legitimate".

release:independent projects are rendered on this website [1], and ttx's
review comment was more to put kolla in releases:independent of the
releases repo rather then the mitaka location [1].  I misunderstood ttx's
comments to mean we were completely excluded which is not the case.

That said, release:cycle-with-milestones is still what we want :)

I'd ask people cut me a little slack on this, I am new to the
openstack/releases repository ;)

[1] http://releases.openstack.org/independent.html
[2] https://review.openstack.org/#/c/297976/
>
>Regards
>-steve
>
>> 
>>Jeremy Stanley
>>
>>_
>>_
>>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] [tc][kolla] Change to kolla's release model to gain access to release's website marketing

[Steven Dake (stdake)]

On 4/2/16, 10:01 AM, "Jeremy Stanley"  wrote:

>On 2016-04-02 16:13:28 + (+), Steven Dake (stdake) wrote:
>[...]
>> I feel as though we are not permitted to participate in the
>> marketing that takes place on the releases website
>[...]
>
>I'll refrain from commenting on the rest since I'm not a member of
>the release team, but I *seriously* hope we've not created a
>"marketing" portal simply by way of tracking version numbers,
>changelogs and release schedules. I have a feeling few (if any) of
>the release team wants to get into the marketing business and I'm
>happy to help do whatever is in my power to neuter the "marketing
>potential" for releases.openstack.org so it can be viewed simply as
>a source of _objective_ technical data.
>--

It is objective technical data, but atm we are excluded, and people look
at that objective technical data (like marketing and sales folks) to make
decisions, so it is by its very nature a marketing resource as well.  If
we are excluded, sales and marketing folks that make decisions about
OpenStack deployments may come along and say "not on the website, not
legitimate".

Regards
-steve

> 
>Jeremy Stanley
>
>__
>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] [tc][kolla] Change to kolla's release model to gain access to release's website marketing

[Jeremy Stanley]

On 2016-04-02 16:13:28 + (+), Steven Dake (stdake) wrote:
[...]
> I feel as though we are not permitted to participate in the
> marketing that takes place on the releases website
[...]

I'll refrain from commenting on the rest since I'm not a member of
the release team, but I *seriously* hope we've not created a
"marketing" portal simply by way of tracking version numbers,
changelogs and release schedules. I have a feeling few (if any) of
the release team wants to get into the marketing business and I'm
happy to help do whatever is in my power to neuter the "marketing
potential" for releases.openstack.org so it can be viewed simply as
a source of _objective_ technical data.
-- 
Jeremy Stanley

__
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] [tc][kolla] Change to kolla's release model to gain access to release's website marketing

[Steven Dake (stdake)]

Technical Committee,

Please accept my change prior to our April 8th deadline for tagging Mitaka 
2.0.0 of Kolla.  To be clear, this is a clunky workaround but I feel as though 
we are not permitted to participate in the marketing that takes place on the 
releases website, and this is the lesser of that evil.

The review is here:

https://review.openstack.org/300752


I'd like to do it right, and remove the red tape surrounding deployment 
projects first, but from what I've gathered on the mailing list (sorry no 
references) and in various reviews I've been involved with, solving the red 
tape related to deployment projects won't happen in time to apply this tag to 
our repository as this tag operates on a 7 day lazy consensus model, which 
means Kolla can still possibly gain access to the marketing resources of the 
releases project team's website.


Regards

-steve
__
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] 答复: [Heat] Re-evaluate conditions specification

[Qiming Teng]

 
> parameters:
>   env:
>type: string
>default: prod
> 
>   is_prod:
> type: boolean
> default: {equals: {get_param, env}}
> 
> From an interface standpoint this seems much cleaner and more intuitive than
> the other solutions discussed IMHO, but I suspect it's potentially harder to
> implement.
> 
> Your original example gets much cleaner too if we allow all intrinsic function
> (except get_attr) in the scope of parameters:
> 
> parameters:
>   host:
> type: string
>   port:
> type: string
>   endpoint:
> type: string
> default:
>   str_replace:
> template:
>http://HOSTORT/
> params:
>HOST: {get_param: host}
>PORT: {get_param: port}
> 
> Steve

+1 to restricting the variable evaluation into the 'parameters' section
which we can treat as the 'static' part of a template. Maybe that is one
of the reasons why aws has a 'conditions' section to avoid getting into
the lazy evaluation mess?

Regards,
  Qiming


__
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] [ptl] [security][tc] Tidy up language in section 5 of the vulnerability:managed tag

[Steven Dake (stdake)]

Apologies for not copying the [ptl] tag, since this change affects mostly the 
PTLs and the projects for which they facilitate.

Note PTL's the purpose of this change is to make your lives easier and 
streamline the VMT application process, but keep the spirit of the original 
requirement in place.  Given that this change is to help make he lives of the 
PTL and security team easier, if both could weigh in ion the review, I'd 
appreciate it.  I'd like to get the language correct so we don't have to keep 
changing section 5 of this tag or special case it to death since that is an 
anti-pattern in the governance repository.

If PTLs, project partiicipants, or anyone else for that matter have any wording 
changes, feel free to propose them - IANAL and writing these things correctly 
is hard to do properly ); involving the community around the pain points of the 
tagging process is what I'm after.

Regards
-steve

From: Steven Dake >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, April 1, 2016 at 5:04 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [security][tc] Tidy up language in section 5 of the 
vulnerability:managed tag

Please see my review here as requested in this thread [1]:

https://review.openstack.org/300698


The purpose of this review is two fold:

  1.  Permit sponsoring companies of single vendor projects or projects with 
low company affiliation diversity to allow their own security experts to sign 
off on a threat analysis, acting as a third party..
  2.  Enable scaling of the OSSA and VMT processes by permitting projects to 
self-audit, self-review, or self-threat analyze with the condition that an 
impartial third party take responsibility for approving the audit, review, or 
threat analysis.

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-March/091075.html
__
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] [magnum] Proposing Eli Qiao for Magnum core reviewer team

[Kai Qiang Wu]

+ 1 for Eli :)


Thanks

Best Wishes,

Kai Qiang Wu (吴开强  Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
 No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
100193

Follow your heart. You are miracle!



From:   Hongbin Lu 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   01/04/2016 02:20 am
Subject:[openstack-dev] [magnum] Proposing Eli Qiao for Magnum core
reviewer team



Hi all,

Eli Qiao has been consistently contributed to Magnum for a while. His
contribution started from about 10 months ago. Along the way, he
implemented several important blueprints and fixed a lot of bugs. His
contribution covers various aspects (i.e. APIs, conductor, unit/functional
tests, all the COE templates, etc.), which shows that he has a good
understanding of almost every pieces of the system. The feature set he
contributed to is proven to be beneficial to the project. For example, the
gate testing framework he heavily contributed to is what we rely on every
days. His code reviews are also consistent and useful.

I am happy to propose Eli Qiao to be a core reviewer of Magnum team.
According to the OpenStack Governance process [1], we require a minimum of
4 +1 votes within a 1 week voting window (consider this proposal as a +1
vote from me). A vote of -1 is a veto. If we cannot get enough votes or
there is a veto vote prior to the end of the voting window, Eli is not able
to join the core team and needs to wait 30 days to reapply.

The voting is open until Thursday April 7st.

[1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess

Best regards,
Hongbin

 __
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] Acknowledging Jim Blair's work on the TC

[Morgan Fainberg]

On Fri, Apr 1, 2016 at 12:06 PM, Anita Kuno  wrote:

> Jim is an incumbent on the TC this election and he didn't run. I'm
> posting this to express my thanks to Jim for his work and dedication on
> the TC.
>
> Jim, I think your commitment to open source, spanning many years before
> OpenStack, and your dedication to governance process, are qualities I
> admire very much and I'm grateful you were able to voice your opinions
> on the TC from October 2013 until now.
>
> Thank you for taking your turn and thank you as well for allowing others
> a chance to take theirs.
>
> Thank you, Jim,
> Anita.
>
>
>
Well said and 100% agree! Thank you Jim!
__
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] [Neutron][python-neutronclient] Adding new options to the existing Neutron CLIs

[Akihiro Motoki]

2016-03-18 12:06 GMT+09:00 reedip banerjee :
> Dear All Neutron Developers and Reviewers,
>
> I have a query/concern related to the parsing of options in
> python-neutronclient.
> I would like to bring this up, as it "may" also impact the transition of the
> CLIs to the openstack client as well.
>
> NeutronClient is pretty special in its behavior, and has one pretty powerful
> feature of parsing extra options. This feature states that, if the CLI does
> not support an option but the API does, and the user passes a value for this
> option, then the "unsupported" CLI option is parsed , and forwarded to the
> Neutron Server for processing.
>
> Example:
> Currently "neutron net-create" does not support --router:external. If you
> see the output of "neutron net-create -h" you would not find
> "--router-external". However, this option is supported in the API since Juno
> [2]. So therefore , if a user executes the following CLI
> " neutron net-create TestNetwork --router-external"
>
> then [1] would be observed as an output.

We can use "--router:external" since the initial support of neutron
router (Folsom).
You are talking about the situation that it is not described in the
help message.
It is better to have it in the help message.

> Now the query/concern comes next
> Any option which is not supported by the CLI is open to the above parsing.
> Therefore , for net-create and net-update, all the following are possible:
>
> neutron net-create --router:external=True TESTNetwork --(A)
> neutron net-create --router:external TESTNetwork  --(B)
> neutron net-create TESTNetwork --router:external --(C)
> neutron net-create TESTNetwork --router:external=True --(D)
> neutron net-create TESTNetwork --router:external True --(E)
>
> However, user is not aware of the --router:external option because it is not
> visible in the HELP section ( this is true for other CLI options as well).
>
> In order to demonstrate these options to the User, we have to update
> add_known_arguments function to display them. And once they are known to the
> CLI, the parsing changes, and some of the options from (A) to (E) may not be
> supported ( Please see [3] for an ongoing, though now dormant, discussion ).
>
> Note that this discussion is not limited only to net-create, but possibly
> other CLIs as well which do not completely expose the Options which the API
> can support.I am , however, taking the net-create example as a case-study.
>
> I would like to know how we can move forward in this regards:
>
> -- Should NeutronClient continue to support all options from (A) to (E), but
> deprecate some of them in Openstack Client?

As Richard said, we don't plan to support the extra arguments in
openstackclient,
so this is not a problem in the openstackclient migration.
In OpenStack Client, we should follow OpenStack client option convention.
I don't think it is a DEPRECATION of some options. It is a DERECATION
of neutronclient CLI itself.

> -- Should we deprecate them in NeutronClient itself, so that the users are
> comfortable with the options when the migration to Openstack Client occurs?

My vote is to keep the current behavior.
On the other hand I don't think we need to show all available patterns.

Akihiro


>
> -- Any other suggestions
>
> [1]: http://paste.openstack.org/show/491032/
>
> [2]:
> http://docs.openstack.org/juno/install-guide/install/apt/content/neutron_initial-external-network.html
>
> [3]: https://review.openstack.org/#/c/137279/
>
> --
> Thanks and Regards,
> Reedip Banerjee
> IRC: reedip
>
>
>
>
>
> __
> 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] [bifrost][ironic][release] missing build artifacts

[Doug Hellmann]

Excerpts from Julia Kreger's message of 2016-04-01 18:21:24 -0400:
> On Fri, Apr 1, 2016 at 4:48 PM, Doug Hellmann  wrote:
> 
> > Excerpts from Doug Hellmann's message of 2016-04-01 16:25:07 -0400:
> > > Ironic/Bifrost team,
> > >
> 
> >
> > > It would be good to understand what your intent is for builds. Can
> > > you follow up here on this thread with some details?
> > >
> >
> 
> First time partial user of the deliverables release tagging and didn't
> realize that we were
> missing the configuration necessary to push a tag up to tarballs.o.o. Would
> landing
> 300646 and then reverting it after 300474 has landed result in the
> artifacts being built
> and pushed to tarballs.o.o?

The tarball job is triggered when a new tag is added, so no. Now that
the correct jobs are in place you could apply a new tag to produce an
artifact, though. If you re-tag the same SHA as 1.0.0 with version
1.0.1, we will at least have that. We can decide what to do about the
missing artifacts separately (either remove them from the record or
disable the links to those versions).

You can either tag directly and then record the results in the releases
repo, or you can submit a release request and  let the release team
process it.

Doug

> 
> >
> > I forgot to mention that https://review.openstack.org/#/c/300474
> > includes some changes to add the simple server publishing jobs. If you
> > want to use those, please +1 the patch.

__
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] [monasca][release] missing build artifacts

[Doug Hellmann]

Excerpts from Hochmuth, Roland M's message of 2016-04-02 01:35:35 +:
> Hi Doug, You had mentioned issues with three repos:
> 
> 1. monasca-ceilometer
> 2. monasca-log-api
> 3. monasca-thresh
> 
> All the repos that have Python code I believe are in reasonable shape with 
> respect to the Python deliverables except for the following two repos:
> 
> 1. monasca-ceilometer
> 2. monasca-log-api
> 
> I'm not sure we should attempt to resolve these two repos for the Mitaka 
> release, but we can try. It might be too late. They aren't in heavy usage and 
> are relatively new.

I think for those you were missing the "venv" environment in tox.ini
that the jobs use to run arbitrary commands. Have a look at some of the
other repos for an example of how to set that up, or ask the infra team
(I'm not sure where it's documented, unfortunately, or I would direct
you there).

> 
> 
> monasca-thresh is a pure Java component.
> 
> In the process of looking at monasca-thresh it looks like there is a general 
> issue with all the Java deliverables. All the Java jars are built and 
> uploaded in their respective folders such as, 
> http://tarballs.openstack.org/ci/monasca-thresh/. Note the "ci". However, we 
> don't move the jars that are in this directory up a level to 
> http://tarballs.openstack.org/monasca-thresh/. It looks like that needs to 
> get resolved.
> 
> 
> A proposal that I think would resolve this is as follows:
> 
> 1. Update versions of Java jars in the pom.xml for each project to something 
> like 2.0 on the stable/mitaka branch. This will result in a new jar file 
> being created with a nice version and name. Note, this step isn't necessary, 
> but if we did this we would have a nice version for Mitaka.

If the artifacts exist but are in the "wrong" place, maybe someone
from the infra team can copy them into place for you. Then if you
give us an example of what the filenames are, the release team can
update the tools in the releases repo to generate links to them (I
assume, for example, they are not .tar.gz files).

> 2. Figure out how to copy the jars over to their respective folders in 
> http://tarballs.openstak.org. For Python I think the script that does this is 
> publish-to-pypi, but for Java code, not sure exactly what needs to be done.

Yes, you need to work with infra to set up the necessary build scripts.
It's probably not realistic to do this in the next week, but if you get
the existing files copied into place then you can work on updating the
job before the Newton-1 milestone tagging deadline.

Doug

> 
> I think the two steps above would get us in compliance again for 
> monasca-thresh and all the Java code in the other repos.
> 
> Does that seem like a reasonable plan at this point?
> 
> Regards --Roland
> 
> On 4/1/16, 2:36 PM, "Doug Hellmann"  wrote:
> 
> >Excerpts from Hochmuth, Roland M's message of 2016-04-01 20:06:28 +:
> >> Hi Doug, Sorry, this is our first release and we want to do the right 
> >> thing.
> >> 
> >> monasca-ceilometer is the code that plugs into the Ceilometer publisher 
> >> and Ceilometer storage driver to allow Ceilometer to send metrics to the 
> >> Monasca API and use Monasca as a storage backend. We don't create a pypi 
> >> for this component.
> >
> >How do you users receive that code and install it? We at least need
> >a tarball built. If you don't want to publish to pypi, you can use
> >the job definitions that the Python server projects use to build
> >artifacts.
> >
> >> monasca-log-api is probably not set up completely, but it should be 
> >> similar to the monasca-api.
> >> 
> >> monasca-thresh remains purely Java code. There is a build, but it isn't a 
> >> Python build so there isn't a tox.ini. Not sure how to deliver this, but 
> >> the current java build overwrites the jar each time it builds so it sounds 
> >> like that would need to be fixed.
> >
> >Are those JAR files going somewhere we could link to?
> >
> >> 
> >> I guess, judging by the issues, I don't quite understand what 
> >> "deliverables" are. I was thinking it was the tagged code, but obviously 
> >> it includes the build too. It sounds like we have more work ahead of us.
> >
> >Most of our distributors want a tarball or sdist or other artifact they
> >can use to build a package from. For the Python-based apps, we have
> >templates you can use in the zuul/layout.yaml file to introduce those
> >jobs into the right zuul queues. The release or infra teams can help you
> >identify the right template to use.
> >
> >> Let me know how you want to proceed.
> >
> >We only want to be linking to things we're actually publishing. The
> >first patch I mentioned removes the links so the Monasca projects
> >that don't have builds. The second patch removes the projects
> >entirely, but if we can update the page to link to a downloadable
> >artifact (rather than just a git repo tag) then we can keep the
> >projects in the list. We can get downloadable artifacts by having
> 

Re: [openstack-dev] [congress][release] missing build artifacts

[Doug Hellmann]

Excerpts from Tim Hinrichs's message of 2016-04-01 22:46:59 +:
> Hi Doug,
> 
> Thanks for letting us know.  Here's what we're intending...
> - We'd like to release the server code for Mitaka.
> - We release the client to Pypi, so that's already taken care of.
> - We haven't moved our docs off of readthedocs yet, so we're taking care of
> that as well.
> 
> I gave a +1 to your patch for adding openstack-server-release-jobs to zuul.
> I also pushed a congress-only patch for the same, thinking that's probably
> what you actually wanted us to do.
> https://review.openstack.org/#/c/300682/

Now that the jobs are in place, we should tag new release candidates
using new versions and the same SHAs as the last candidate to get the
artifacts built properly. You can submit the request for that using the
releases repo, or you can tag yourself and submit the info after the
fact. We will decide what to do about the old artifacts you have on
launchpad separately.

> 
> I gave a -1 to your patch that removes all the Congress deliverables from
> openstack/releases, thinking that we can have this sorted out quickly.  The
> job we're missing just produces a tarball and uploads it, right?  We've
> been manually doing releases up to this point, which is why we didn't have
> the job in place.
> https://review.openstack.org/300644
> 
> I didn't touch your change on the artifact-link-mode, since it seems like a
> short-term solution that may go in before we get everything sorted.
> https://review.openstack.org/300457

Yes, we'll merge that as a short-term fix until we have the rest of it
worked out.

Doug

> 
> Tim
> 
> On Fri, Apr 1, 2016 at 1:23 PM Doug Hellmann  wrote:
> 
> > Congress team,
> >
> > We noticed in our audit of the links on
> > http://releases.openstack.org/mitaka/index.html that the links to
> > the build artifacts for congress point to missing files. The
> > repository doesn't seem to have any real build jobs configured in
> > openstack-infra/project-config/zuul/layout.yaml, so it's not clear
> > how tagging is producing a release for you.
> >
> > For now, we are disabling links to the artifacts for those repos
> > via https://review.openstack.org/300457 but we're also planning to
> > remove them from the official Mitaka page since there don't
> > appear to be any actual related deliverables
> > (https://review.openstack.org/300644).
> >
> > It would be good to understand what your intent is for builds. Can
> > you follow up here on this thread with some details?
> >
> > Thanks,
> > 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
> >

__
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] [magnum] Split k8s-client in separate python package

[Davanum Srinivas]

Hongbin,

Here's what i came up with based on your feedback:
https://review.openstack.org/#/c/300729/

Thanks,
Dims

On Fri, Apr 1, 2016 at 6:19 PM, Hongbin Lu  wrote:
> Dims,
>
> Thanks for splitting the k8sclient code out. Below is my answer to your 
> question.
>
> - Should this be a new openstack/ repo?
> Yes, I think so. We need it in openstack namespace in order to leverage the 
> openstack infra for testing and packaging.
>
> - Would the Magnum team own the repo and use the new python package?
> If this library is mainly used by Magnum, I think Magnum team has no problem 
> to own it. If it is also used by other projects, I am afraid Magnum team 
> won't have enough bandwidth to support it. In such case, it is better to have 
> other teams to share the ownership.
>
> Best regards,
> Hongbin
>
> -Original Message-
> From: Davanum Srinivas [mailto:dava...@gmail.com]
> Sent: April-01-16 3:36 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [magnum] Split k8s-client in separate python package
>
> Team,
>
> I've been meaning to do this for a while. Short version, see repo:
> https://github.com/dims/python-k8sclient/
>
> Long version:
> - Started from the magnum repo.
> - pulled out just ./magnum/common/pythonk8sclient
> - preserved entire history in case we had to go back
> - reorganized directory structure
> - ran openstack cookie cutter and added generated files
> - added a test that actually works against a live k8s :)
>   
> https://github.com/dims/python-k8sclient/blob/master/k8sclient/tests/test_k8sclient.py
>
> Question:
> - Should this be a new openstack/ repo?
> - Would the Magnum team own the repo and use the new python package?
>
> Thanks,
> Dims
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [searchlight] Add Nova Keypair Plugin

[Hiroyuki Eguchi]

Hi Travis,

Thank you for valuable information.
I've added a bp in nova for now.
(https://blueprints.launchpad.net/nova/+spec/keypair-notification)
I'm going to create a nova-spec based on information you taught me.

Thanks
Hiroyuki


差出人: Tripp, Travis S [travis.tr...@hpe.com]
送信日時: 2016年4月1日 12:53
宛先: OpenStack Development Mailing List (not for usage questions)
件名: Re: [openstack-dev] [searchlight] Add Nova Keypair Plugin

Hiroyuki,

Thanks for the update. That sounds like the best course of action. As FYI, Li 
Yingjun also has a spec up on Nova to get notifications on hypervisors [0], 
which we briefly discussed in the IRC meeting this morning [1]. The two of you 
might be able to work together in getting nova specs and patches up. For most 
simple plugins to searchlight, we don’t need to do a full spec on the 
searchlight side in addition to the launchpad blueprint. But, if you could add 
a couple of bullet points on key pairs the etherpad below [2], it would be 
helpful. We are just trying to get a quick inventory started on that status of 
various notifications in OpenStack and may use that at the summit for 
discussions. Later, we may move this to wiki in table form, but I’m just hoping 
to get the basic info captured for now.

[0] https://review.openstack.org/#/c/299807/
[1] 
http://eavesdrop.openstack.org/meetings/openstack_search/2016/openstack_search.2016-03-31-15.01.log.html
[2] https://etherpad.openstack.org/p/search-team-meeting-agenda

Thanks,
Travis




On 3/31/16, 8:05 PM, "Hiroyuki Eguchi"  wrote:

>Hi Steve
>
>Thank you for your advice.
>Currently It's impossible to sync keystone information between DB and 
>ElasticeSearch.
>And no useful notification will be send for kaypair state change.(only 
>key_name)
>So, I try to propose improving keypair notifications against nova-specs.
>
>Thanks.
>Hiroyuki
>
>
>差出人: McLellan, Steven [steve.mclel...@hpe.com]
>送信日時: 2016年3月31日 5:49
>宛先: OpenStack Development Mailing List (not for usage questions)
>件名: Re: [openstack-dev] [searchlight] Add Nova Keypair Plugin
>
>Hi Hiroyuki,
>
>It would be worth being certain about what access we have to keypairs before 
>committing to a plugin; if we cannot retrieve the initial list or receive 
>notifications on new keypairs, we likely can't index them at all. If we have 
>partial access we may be able to make a decision on whether it will be good 
>enough. Please feel free to get in touch in IRC (#openstack-searchlight) if 
>that would be useful.
>
>Steve
>
>From: Hiroyuki Eguchi >
>Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>>
>Date: Tuesday, March 29, 2016 at 7:13 PM
>To: "OpenStack Development Mailing List (not for usage questions)" 
>>
>Subject: [openstack-dev] [searchlight] Add Nova Keypair Plugin
>
>Hi Lakshmi,
>
>Thank you for your advice.
>I'm trying to index the public keys.
>I'm gonna try to discuss in searchlight-specs before starting development.
>
>Thanks
>Hiroyuki.
>
>
>
>差出人: Sampath, Lakshmi [lakshmi.samp...@hpe.com]
>送信日時: 2016年3月29日 2:03
>宛先: OpenStack Development Mailing List (not for usage questions)
>件名: Re: [openstack-dev] [searchlight] Add Nova Keypair Plugin
>
>Hi Hiroyuki,
>
>For this plugin what data are you indexing in Elasticsearch. I mean what do 
>you expect users to search on and retrieve? Are you trying to index the public 
>keys?
>Talking directly to DB is not advisable, but before that we need to discuss 
>what data is being indexed and the security implication of it (RBAC) to users 
>who can/cannot access it.
>
>I would suggest start a spec in openstack/searchlight-specs under newton for 
>reviewing/feedback.
>https://github.com/openstack/searchlight-specs.git
>
>
>Thanks
>Lakshmi.
>
>From: Hiroyuki Eguchi [mailto:h-egu...@az.jp.nec.com]
>Sent: Sunday, March 27, 2016 10:26 PM
>To: OpenStack Development Mailing List (not for usage questions) 
>[openstack-dev@lists.openstack.org] 
>>
>Subject: [openstack-dev] [searchlight] Add Nova Keypair Plugin
>
>Hi.
>
>I am developing this plugin.
>https://blueprints.launchpad.net/searchlight/+spec/nova-keypair-plugin
>
>However I faced the problem that a admin user can not retrieve a keypair 
>information created by another user.
>So it is impossible to sync the keypair between OpenStack DB and 
>Elasticsearch, unless connect to OpenStack DB directly.
>Is there any suggestions to resolve it ?
>
>thanks.
>
>__
>OpenStack Development Mailing List (not for