[openstack-dev] [acceleration]Cyborg Team Weekly Meeting 2018.01.03

[Zhipeng Huang]

Happy New Year !

Let's resume our weekly team meeting today as usual starting from UTC1500
at #openstack-cyborg. We are now in release countdown mode so we will
mostly focus on Queens delivery development.

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] containers-multinode is broken, what's our plan

[Emilien Macchi]

Mistral broke us with https://review.openstack.org/#/c/506185/ and we
had a promotion yesterday so now our CI deploy Mistral with this
patch.
It breaks some Mistral actions, including the ones needed by
config-download (in featureset010).

Steve has a fix: https://review.openstack.org/#/c/530781 but there is
no core review yet so we decided to proceed this way:

1) Carry Steve's patch in Mistral distgit:
https://review.rdoproject.org/r/#/c/11140/ - DONE
2) Remove featureset010 from promotion requirements - DONE
3) Once we have a promotion, we'll be able to land
https://review.openstack.org/#/c/530783/ - IN PROGRESS
4) Once https://review.openstack.org/#/c/530783/ is landed, and the
upstream patch is landed, revert
https://review.rdoproject.org/r/#/c/11140/ (otherwise RDO will become
inconsistent) and failing to build on master)
5) Re-add featureset010 in promotion requirements (revert
https://review.rdoproject.org/r/#/c/11142) so we'll catch the issue
next time.

Thanks,
-- 
Emilien Macchi

__
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] [neutron]Why neutron-vpnaas support transport vpn mode?

[270162781]

HI , Neutron guys:


Currently, I found the neutron vpn service which is ipsec vpn support transport 
mode. And the current data model is that a vpn service must be associated with 
a Router instance. AFAIK, transport mode can not pass through a Router with NAT 
and usually used by P-to-P VPN not for the current site-to-site type.


Just a question about it, is that we just support as the configuration/vpn 
backend support? What the usecase towards Openstack env?


Thanks,


Best Regards,__
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] [all] [tc] Policy in code gotcha

[Lance Bragstad]

Today in office hours someone reported a bug where keystone wasn't
producing policy files based on the overrides on disk and the defaults
in code [0]. After doing some digging, I found that keystone missed a
step while moving policy into code. I have a patch [1] up that follows
an approach from nova.

With all of the policy in code work happening this release, I wanted to
send a note in case folks were seeing this with their projects. Or just
a reminder to test for it if you're unsure if your project will be affected.

Let me know if you have any questions and I'll be happy to chip in if
your project is experiencing issues.

Lance

[0] https://bugs.launchpad.net/keystone/+bug/1740951
[1] https://review.openstack.org/#/c/530828/



signature.asc
Description: OpenPGP digital signature
__
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] Proposing Luka Peschke (peschk_l) as core for cloudkitty

[Jiong Liu]

> Hello developers mailing list folks,

> I'd like to propose that we add Luka Peschke (peschk_l) as an OpenStack 
> cloudkitty core reviewer.

> He has been a member of our community for years, contributing very 
> seriously in cloudkitty. He also provided many reviews on the project as 
> you can see in his activity logs

> http://stackalytics.com/report/contribution/cloudkitty/60

> His willing to help whenever it is need has been really appreciated !

> Current Cloudkitty cores, please respond with +1 or explain your 
> opinion if voting against... If there are no objection in the next 5 
> days I'll add him.

+1, welcome Luka!



__
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] [FEMDC] Wed. 3 Jan - IRC Meeting Cancelled - Next meeting Wed.17.

[lebre . adrien]

Dear all, 

Due to the Christmas/new year period, the meeting is cancelled. 
Next meeting is scheduled on Wed, the 17th. 

ad_ri3n_

__
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] [Zun] Containers in privileged mode

[Hongbin Lu]

Please find my reply inline.

Best regards,
Hongbin

On Tue, Jan 2, 2018 at 2:06 PM, João Paulo Sá da Silva <
joao-sa-si...@alticelabs.com> wrote:

> Thanks for your answer, Hongbin, it is very appreciated.
>
>
>
> The use case is to use Virtualized Network Functions in containers instead
> of virtual machines. The rational for using containers instead of VMs is
> better VNF density in resource constrained hosts.
>
> The goal is to have several VNFs (DHCP, FW, etc) running on severely
> resource constrained Openstack compute node.  But without NET_ADMIN cap I
> can’t even start dnsmasq.
>
Make sense. Would you help writing a blueprint for this feature:
https://blueprints.launchpad.net/zun ? We use blueprint to track all
requested features.


>
>
> Is it possible to use clear container with zun/openstack?
>
Yes, it is possible. We are adding documentation about that:
https://review.openstack.org/#/c/527611/ .

>
>
> From checking gerrit it seems that this point was already address and
> dropped? Regarding the security concerns I disagree, if users choose to
> allow such situation they should be allowed.
>
> It is the user responsibility to recognize the dangers and act
> accordingly.
>
>
>
> In Neutron you can go as far as fully disabling  port security, this was
> implemented again with VNFs in mind.
>
Make sense as well. IMHO, we should disallow privilege escalation by
default, but I am open to introduce a configurable option to allow it. I
can see this is necessary for some use cases. Cloud administrators should
be reminded the security implication of doing that.


>
>
> Kind regards,
>
> João
>
>
>
>
>
> >Hi Joao,
>
> >
>
> >Right now, it is impossible to create containers with escalated
> privileged,
>
> >such as setting privileged mode or adding additional caps. This is
>
> >intentional for security reasons. Basically, what Zun currently provides
> is
>
> >"serverless" containers, which means Zun is not using VMs to isolate
>
> >containers (for people who wanted strong isolation as VMs, they can choose
>
> >secure container runtime such as Clear Container). Therefore, it is
>
> >insecure to give users control of any kind of privilege escalation.
>
> >However, if you want this feature, I would love to learn more about the
> use
>
> >cases.
>
> >
>
> >Best regards,
>
> >Hongbin
>
> >
>
> >On Tue, Jan 2, 2018 at 10:20 AM, João Paulo Sá da Silva <
>
> >joao-sa-silva at alticelabs.com> wrote:
>
> >
>
> >> Hello!
>
> >>
>
> >> Is it possible to create containers in privileged mode or to add caps as
>
> >> NET_ADMIN?
>
> >>
>
> >>
>
> >>
>
> >> Kind regards,
>
> >>
>
> >> João
>
> >>
>
> >>
>
> >>
>
> >> ____
> __
>
> >> OpenStack Development Mailing List (not for usage questions)
>
> >> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
>
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> >>
>
> >>
>
> -- next part --
>
> An HTML attachment was scrubbed...
>
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20180102/e1ecb71a/attachment.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
>
>
__
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] [nova] seeking your kind support and assistance regarding securing hypervisor and virtual machines against security attacks or threats

[Matt Riedemann]

On 12/24/2017 8:45 AM, Darshan Tank wrote:
How to secure hypervisor and virtual machine against security threats in 
OpenStack? What are the methods, techniques or algorithms, OpenStack 
community/developers followed to make openstack as secure cloud environment?


Have you started by reading the Security Guide [1]?

[1] https://docs.openstack.org/security-guide/

--

Thanks,

Matt

__
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] [Zun] Containers in privileged mode

[João Paulo Sá da Silva]

Thanks for your answer, Hongbin, it is very appreciated.

The use case is to use Virtualized Network Functions in containers instead of 
virtual machines. The rational for using containers instead of VMs is better 
VNF density in resource constrained hosts.
The goal is to have several VNFs (DHCP, FW, etc) running on severely resource 
constrained Openstack compute node.  But without NET_ADMIN cap I can't even 
start dnsmasq.

Is it possible to use clear container with zun/openstack?

>From checking gerrit it seems that this point was already address and dropped? 
>Regarding the security concerns I disagree, if users choose to allow such 
>situation they should be allowed.
It is the user responsibility to recognize the dangers and act accordingly.

In Neutron you can go as far as fully disabling  port security, this was 
implemented again with VNFs in mind.

Kind regards,
João


>Hi Joao,
>
>Right now, it is impossible to create containers with escalated privileged,
>such as setting privileged mode or adding additional caps. This is
>intentional for security reasons. Basically, what Zun currently provides is
>"serverless" containers, which means Zun is not using VMs to isolate
>containers (for people who wanted strong isolation as VMs, they can choose
>secure container runtime such as Clear Container). Therefore, it is
>insecure to give users control of any kind of privilege escalation.
>However, if you want this feature, I would love to learn more about the use
>cases.
>
>Best regards,
>Hongbin
>
>On Tue, Jan 2, 2018 at 10:20 AM, João Paulo Sá da Silva <
>joao-sa-silva at alticelabs.com> wrote:
>
>> Hello!
>>
>> Is it possible to create containers in privileged mode or to add caps as
>> NET_ADMIN?
>>
>>
>>
>> Kind regards,
>>
>> João
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openstack.org/pipermail/openstack-dev/attachments/20180102/e1ecb71a/attachment.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] [Zun] Containers in privileged mode

[Hongbin Lu]

Hi Joao,

Right now, it is impossible to create containers with escalated privileged,
such as setting privileged mode or adding additional caps. This is
intentional for security reasons. Basically, what Zun currently provides is
"serverless" containers, which means Zun is not using VMs to isolate
containers (for people who wanted strong isolation as VMs, they can choose
secure container runtime such as Clear Container). Therefore, it is
insecure to give users control of any kind of privilege escalation.
However, if you want this feature, I would love to learn more about the use
cases.

Best regards,
Hongbin

On Tue, Jan 2, 2018 at 10:20 AM, João Paulo Sá da Silva <
joao-sa-si...@alticelabs.com> wrote:

> Hello!
>
> Is it possible to create containers in privileged mode or to add caps as
> NET_ADMIN?
>
>
>
> Kind regards,
>
> João
>
>
>
> __
> 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-dev] [tripleo] tripleo-upgrade pike branch

[Marius Cornea]

Hi everyone and Happy New Year!

As the migration of tripleo-upgrade repo to the openstack namespace is
now complete I think it's the time to create a Pike branch to capture
the current state so we can use it for Pike testing and keep the
master branch for Queens changes. The update/upgrade steps are
changing between versions and the aim of branching the repo is to keep
the update/upgrade steps clean per branch to avoid using conditionals
based on release. Also tripleo-upgrade should be compatible with
different tools used for deployment(tripleo-quickstart, infrared,
manual deployments) which use different vars for the version release
so in case of using conditionals we would need extra steps to
normalize these variables.

I wanted to bring this topic up for discussion to see if branching is
the proper thing to do here.

Thanks,
Marius

__
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] [kayobe][kolla] Kayobe IRC channel

[Mark Goddard]

Hi,

I've registered the #openstack-kayobe channel for developer and operator
discussion of kayobe [1]. Jump on if you're using kayobe or interested in
doing so.

Mark

[1] https://github.com/stackhpc/kayobe
__
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] [tripleo] CI promotion blockers

[Julie Pichon]

On 2 January 2018 at 16:30, Alex Schultz  wrote:
> On Tue, Jan 2, 2018 at 9:08 AM, Julie Pichon  wrote:
>> Hi!
>>
>> On 27 December 2017 at 16:48, Emilien Macchi  wrote:
>>> - Keystone removed _member_ role management, so we stopped using it
>>> (only Member is enough): https://review.openstack.org/#/c/529849/
>>
>> There's been so many issues with the default member role and Horizon
>> over the years, that one got my attention. I can see that
>> puppet-horizon still expects '_member_' for role management [1].
>> However trying to understand the Keystone patch linked to in the
>> commit, it looks like there's total freedom in which role name to use
>> so we can't just change the default in puppet-horizon to use 'Member'
>> as other consumers may expect and settle on '_member_' in their
>> environment. (Right?)
>>
>> In this case, the proper way to fix this for TripleO deployments may
>> be to make the change in instack-undercloud (I presume in [2]) so that
>> the default role is explicitly set to 'Member' for us? Does that sound
>> like the correct approach to get to a working Horizon?
>>
>
> We probably should at least change _member_ to Member in
> puppet-horizon. That fixes both projects for the default case.

Oh, I thought there was no longer a default and that TripleO was
creating the 'Member' role by itself? Fixing it directly in
puppet-horizon sounds ideal in general, if changing the default value
isn't expected to cause other issues.

Thanks,

Julie

>
> Thanks,
> -Alex
>
>> Julie
>>
>> [1] 
>> https://github.com/openstack/puppet-horizon/blob/master/manifests/init.pp#L458
>> [2] 
>> https://github.com/openstack/instack-undercloud/blob/master/elements/puppet-stack-config/puppet-stack-config.yaml.template#L622

__
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] [tripleo] CI promotion blockers

[Alex Schultz]

On Tue, Jan 2, 2018 at 9:08 AM, Julie Pichon  wrote:
> Hi!
>
> On 27 December 2017 at 16:48, Emilien Macchi  wrote:
>> - Keystone removed _member_ role management, so we stopped using it
>> (only Member is enough): https://review.openstack.org/#/c/529849/
>
> There's been so many issues with the default member role and Horizon
> over the years, that one got my attention. I can see that
> puppet-horizon still expects '_member_' for role management [1].
> However trying to understand the Keystone patch linked to in the
> commit, it looks like there's total freedom in which role name to use
> so we can't just change the default in puppet-horizon to use 'Member'
> as other consumers may expect and settle on '_member_' in their
> environment. (Right?)
>
> In this case, the proper way to fix this for TripleO deployments may
> be to make the change in instack-undercloud (I presume in [2]) so that
> the default role is explicitly set to 'Member' for us? Does that sound
> like the correct approach to get to a working Horizon?
>

We probably should at least change _member_ to Member in
puppet-horizon. That fixes both projects for the default case.

Thanks,
-Alex

> Julie
>
> [1] 
> https://github.com/openstack/puppet-horizon/blob/master/manifests/init.pp#L458
> [2] 
> https://github.com/openstack/instack-undercloud/blob/master/elements/puppet-stack-config/puppet-stack-config.yaml.template#L622
>
> __
> 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] [tripleo] CI promotion blockers

[Julie Pichon]

Hi!

On 27 December 2017 at 16:48, Emilien Macchi  wrote:
> - Keystone removed _member_ role management, so we stopped using it
> (only Member is enough): https://review.openstack.org/#/c/529849/

There's been so many issues with the default member role and Horizon
over the years, that one got my attention. I can see that
puppet-horizon still expects '_member_' for role management [1].
However trying to understand the Keystone patch linked to in the
commit, it looks like there's total freedom in which role name to use
so we can't just change the default in puppet-horizon to use 'Member'
as other consumers may expect and settle on '_member_' in their
environment. (Right?)

In this case, the proper way to fix this for TripleO deployments may
be to make the change in instack-undercloud (I presume in [2]) so that
the default role is explicitly set to 'Member' for us? Does that sound
like the correct approach to get to a working Horizon?

Julie

[1] 
https://github.com/openstack/puppet-horizon/blob/master/manifests/init.pp#L458
[2] 
https://github.com/openstack/instack-undercloud/blob/master/elements/puppet-stack-config/puppet-stack-config.yaml.template#L622

__
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] Tempest plugin for Neutron Stadium projects

[Miguel Lavalle]

Hi Neutron community,

During the last Neutron drivers meeting, we discussed whether all the
Neutron Stadium projects should have their Tempest code in
https://github.com/openstack/neutron-tempest-plugin/. It was decided to
allow Stadium projects to get their tests in the consolidated plugin but it
will not be a requirement. The assumption is that many projects might be
stretched in resources and we don't want to create more work for them.

Best regards

Miguel
__
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] performance issue between virtual networks

[Brian Haley]

On 12/27/2017 08:39 AM, Kim-Norman Sahm wrote:

Hi,

i've detected a performance issue by accessing an floating ip in a
different openstack network (same tenant).

example:
i have one tenant with two internal networks.
each network has its own vrouter which is connectet to the extnet.
the physical network infrastructure is 10Gbit/s.

          networkA
    VM1 --|   extnet
  ||vrouter1||
    VM2 --|  |
 |---ext
  networkB   |
    VM3 --|  |
  ||vrouter2||
    VM4 --|

VM1 -> VM2   ~8,6Gbit/s
VM3 -> VM4   ~8,6GBit/s
VM1 -> vrouter1  ~8.6GBit/s
VM4 -> vrouter2 ~8,6GBit/s
vrouter1 -> vrouter2 ~8,6Gbits
VM1 -> VM4   ~2,5GBit/s
VM1 -> vrouter2 ~2,5Gbit/s


I could only guess that vrouter1 and vrouter2 are on different nodes, so 
you're losing some performance going from virtual to physical and back 
(eg GSO).  Have you tried this for reference:


VM1 -> system on extnet
VM4 -> system on extnet

Also, are you sure when packets from VM1 -> VM4 leave the vrouter1 
interface they are still at the higher MTU?


-Brian




detected with iperf3
it's an openstack newton environment with openvswitch 2.6.1
VXLAN mtu is 8950 and 9000 for physical interfaces

does anybody has an idea what could be the cause of the performance
issue?

Best regards
Kim

__
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] Oslo team updates

[Ben Nemec]

A regretful +1.

On 01/01/2018 09:53 PM, ChangBo Guo wrote:
In last two cycles some people's situation changed, can't focus on Oslo 
code review, so I propose  some changes in Oslo team.  Remove following 
people, thanks their past hard wok to make Oslo well, and welcome them 
back if they want to join the team again. please +1/-1 for the change


Generalist Code Reviewers:
  Brant Knudson

Specialist API Maintainers:
oslo-cache-core:  Brant Kundson  David Stanek
oslo-db-core: Viktor Serhieiev
oslo-messaging-core:Dmitriy Ukhlov Oleksii Zamiatin Viktor Serhieiev
oslo-policy-core: Brant Kundson  David Stanek guang-yee
oslo-service-core: Marian Horban

We welcome anyone join the team or contribution in Oslo. The Oslo 
program brings together generalist code reviewers and specialist API 
maintainers They share a common interest in tackling copy-and-paste 
technical debt across the OpenStack project. For more information please 
refer to wiki [1].


[1] https://wiki.openstack.org/wiki/Oslo
--
ChangBo Guo(gcb)
Community Director @EasyStack


__
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] [castellan] Removing Keystoneauth Dependency in Castellan Discussion

[Doug Hellmann]

Excerpts from Gage Hugo's message of 2017-12-19 11:14:18 -0600:
> On Tue, Dec 12, 2017 at 5:34 PM, Doug Hellmann 
> wrote:
> 
> > Excerpts from Dave McCowan (dmccowan)'s message of 2017-12-12 21:36:51
> > +:
> > >
> > > On 12/12/17, 3:15 PM, "Doug Hellmann"  wrote:
> > >
> > > >Excerpts from Dave McCowan (dmccowan)'s message of 2017-12-12 19:56:49
> > > >+:
> > > >>
> > > >> On 12/12/17, 10:38 AM, "Doug Hellmann"  wrote:
> > > >>
> > > >> >
> > > >> >> On Dec 12, 2017, at 9:42 AM, Paul Bourke 
> > > >>wrote:
> > > >> >>
> > > >> >> From my understanding it would be a cleanup operation - which to be
> > > >> >>honest, would be very much welcomed. I recently did a little work
> > with
> > > >> >>Castellan to integrate it with Murano and found the auth code to be
> > > >>very
> > > >> >>messy, and flat out broken in some cases. If it's possible to let
> > the
> > > >> >>barbican client take care of this that sounds good to me.
> > > >> >>
> > > >> >> > Which mode is used the most in the services that consume
> > castellan
> > > >> >> > today?
> > > >> >>
> > > >> >> Afaik Barbican is the only backend that currently exists in
> > Castellan
> > > >> >>[0]. Looking again it seems some support has been added for vault
> > > >>which
> > > >> >>is great, but I reckon Barbican would still be the primary use.
> > > >> >>
> > > >> >> I haven't been hugely active in Castellan but if the team would
> > like
> > > >> >>some more input on this or reviews please do ping me, I'd be glad to
> > > >> >>help.
> > > >> >
> > > >> >What I mean is, in the services consuming Castellan, how do they
> > expect
> > > >> >it to authenticate to Barbican? As the current user or as a
> > hard-coded
> > > >> >fixed user controlled by the deployer? I would think most services
> > > >>would
> > > >> >need to connect as the ³current² user talking to them so they can
> > > >>access
> > > >> >that user¹s secrets from Barbican. Removing the keystoneauth stuff
> > from
> > > >> >the driver would therefore break all of those applications.
> > > >> >
> > > >> >Doug
> > > >>
> > > >> We're a mix right now.  Nova and Cinder pass through the a user's
> > token
> > > >>to
> > > >> retrieve the user's key for encrypted volumes.  Octavia uses its
> > service
> > > >> account to retrieve certificates for load balancing TLS connections.
> > > >> Users must grant Octavia read permissions in advance.
> > > >
> > > >OK, so it sounds like we do need to continue to support both
> > > >approaches to authentication.
> > > >
> > > >> Keystone is currently the only authentication option for Barbican.  I
> > > >> believe the proposal to decouple keystoneauth is advance work for
> > adding
> > > >> new auth methods and backends as future work.  Vault and Custodia are
> > > >>two
> > > >> such backends in progress.  They don't support keystoneauth and likely
> > > >> won't, so we'll need alternatives.
> > > >
> > > >Each driver manages its own authentication, right? Why do we need to
> > > >remove the keystoneauth stuff in the barbican driver in order to enable
> > > >other drivers?
> > >
> > > I would use the word "decouple", with the intent to give the option of
> > > using Castellan without having a dependency on keystoneauth.  But, I
> > don't
> > > want to speak for original posters who used the word "remove" in case
> > they
> > > have other ideas.
> > >
> > > Until recently Barbican was the only secret store and Keystone was the
> > > only authentication service, so we didn't have to sort through the
> > > modularity.
> >
> > I'm sorry that I missed the conversation about this in Denver.  It
> > seems like everyone else understands what's being proposed in a way
> > very different than I do, so I apologize for continuing to just ask
> > the same questions.  I'll try rephrasing, but it would be *very*
> > helpful if someone would summarize that discussion and lay out the
> > plan in more detail than "we want to remove the use of keystoneauth."
> > If we can't do it by email, then maybe via an Oslo spec.
> >
> >
> > The barbican driver has 2 modes for using keystoneauth. One is to
> > use the use the execution context to authenticate using the same
> > token that the current user passed in to the service calling into
> > castellan. The other is to use credentials from the configuration
> > file.
> >
> > Those options seem to be pretty well abstracted in the API, so that
> > the application using castellan can just pass the right sort of
> > context and get the right behavior from the driver, without having
> > to know what the driver is. We currently only have a barbican driver,
> > and that driver uses keystoneauth directly because that is the only
> > way to control which authentication mode is used. Other drivers
> > would presumably use some means other than keystoneauth to authenticate
> > to the backends they talk to, with the difference in behavior 

Re: [openstack-dev] [oslo] Oslo team updates

[Flavio Percoco]

On 02/01/18 11:53 +0800, ChangBo Guo wrote:

In last two cycles some people's situation changed, can't focus on Oslo
code review, so I propose  some changes in Oslo team.  Remove following
people, thanks their past hard wok to make Oslo well, and welcome them back
if they want to join the team again.  please +1/-1 for the change

Generalist Code Reviewers:
Brant Knudson

Specialist API Maintainers:
oslo-cache-core:  Brant Kundson  David Stanek
oslo-db-core: Viktor Serhieiev
oslo-messaging-core:Dmitriy Ukhlov Oleksii Zamiatin Viktor Serhieiev
oslo-policy-core: Brant Kundson  David Stanek guang-yee
oslo-service-core: Marian Horban


+1

Thanks everyone

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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] [Zun] Containers in privileged mode

[João Paulo Sá da Silva]

Hello!

Is it possible to create containers in privileged mode or to add caps as 
NET_ADMIN?

Kind regards,
João

__
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] Oslo team updates

[Ken Giusti]

+1, and a big thank you for all your contributions

On Tue, Jan 2, 2018 at 9:39 AM, Davanum Srinivas  wrote:
> +1 from me as well. Thanks everyone!
>
> On Tue, Jan 2, 2018 at 9:31 AM, Doug Hellmann  wrote:
>> Excerpts from ChangBo Guo's message of 2018-01-02 11:53:02 +0800:
>>> In last two cycles some people's situation changed, can't focus on Oslo
>>> code review, so I propose  some changes in Oslo team.  Remove following
>>> people, thanks their past hard wok to make Oslo well, and welcome them back
>>> if they want to join the team again.  please +1/-1 for the change
>>>
>>> Generalist Code Reviewers:
>>>  Brant Knudson
>>>
>>> Specialist API Maintainers:
>>> oslo-cache-core:  Brant Kundson  David Stanek
>>> oslo-db-core: Viktor Serhieiev
>>> oslo-messaging-core:Dmitriy Ukhlov Oleksii Zamiatin Viktor Serhieiev
>>> oslo-policy-core: Brant Kundson  David Stanek guang-yee
>>> oslo-service-core: Marian Horban
>>>
>>> We welcome anyone join the team or contribution in Oslo. The Oslo program
>>> brings together generalist code reviewers and specialist API maintainers
>>> They share a common interest in tackling copy-and-paste technical debt
>>> across the OpenStack project. For more information please refer to wiki
>>> [1].
>>>
>>> [1] https://wiki.openstack.org/wiki/Oslo
>>
>> +1 -- it's sad to see the team shrink a bit, but it's good to keep the
>> list accurate based on when people can contribute.
>>
>> __
>> 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



-- 
Ken Giusti  (kgiu...@gmail.com)

__
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] Oslo team updates

[Davanum Srinivas]

+1 from me as well. Thanks everyone!

On Tue, Jan 2, 2018 at 9:31 AM, Doug Hellmann  wrote:
> Excerpts from ChangBo Guo's message of 2018-01-02 11:53:02 +0800:
>> In last two cycles some people's situation changed, can't focus on Oslo
>> code review, so I propose  some changes in Oslo team.  Remove following
>> people, thanks their past hard wok to make Oslo well, and welcome them back
>> if they want to join the team again.  please +1/-1 for the change
>>
>> Generalist Code Reviewers:
>>  Brant Knudson
>>
>> Specialist API Maintainers:
>> oslo-cache-core:  Brant Kundson  David Stanek
>> oslo-db-core: Viktor Serhieiev
>> oslo-messaging-core:Dmitriy Ukhlov Oleksii Zamiatin Viktor Serhieiev
>> oslo-policy-core: Brant Kundson  David Stanek guang-yee
>> oslo-service-core: Marian Horban
>>
>> We welcome anyone join the team or contribution in Oslo. The Oslo program
>> brings together generalist code reviewers and specialist API maintainers
>> They share a common interest in tackling copy-and-paste technical debt
>> across the OpenStack project. For more information please refer to wiki
>> [1].
>>
>> [1] https://wiki.openstack.org/wiki/Oslo
>
> +1 -- it's sad to see the team shrink a bit, but it's good to keep the
> list accurate based on when people can contribute.
>
> __
> 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] [oslo] Oslo team updates

[Doug Hellmann]

Excerpts from ChangBo Guo's message of 2018-01-02 11:53:02 +0800:
> In last two cycles some people's situation changed, can't focus on Oslo
> code review, so I propose  some changes in Oslo team.  Remove following
> people, thanks their past hard wok to make Oslo well, and welcome them back
> if they want to join the team again.  please +1/-1 for the change
> 
> Generalist Code Reviewers:
>  Brant Knudson
> 
> Specialist API Maintainers:
> oslo-cache-core:  Brant Kundson  David Stanek
> oslo-db-core: Viktor Serhieiev
> oslo-messaging-core:Dmitriy Ukhlov Oleksii Zamiatin Viktor Serhieiev
> oslo-policy-core: Brant Kundson  David Stanek guang-yee
> oslo-service-core: Marian Horban
> 
> We welcome anyone join the team or contribution in Oslo. The Oslo program
> brings together generalist code reviewers and specialist API maintainers
> They share a common interest in tackling copy-and-paste technical debt
> across the OpenStack project. For more information please refer to wiki
> [1].
> 
> [1] https://wiki.openstack.org/wiki/Oslo

+1 -- it's sad to see the team shrink a bit, but it's good to keep the
list accurate based on when people can contribute.

__
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] Fwd: bug deputy report

[Miguel Lavalle]

-- Forwarded message --
From: Takashi Yamamoto 
Date: Tue, Jan 2, 2018 at 7:45 AM
Subject: bug deputy report
To: Miguel Lavalle 


Hi,

I was a bug deputy but I don't think I can attend today's meeting.
(I'm not feeling well today.)
The week was quiet. I guess it's the most quiet week in a year.
There were nothing critical or urgent.

bug 1740068
lost composite primary key in firewall_group_port_associations_v2
A fix is available, it's unclear why migration tests couldn't catch this.

bug 1740198
DHCP was enabled successfully when IP pool is exhausted
seems like an old issue.
Miguel, can you take a look?

bug 1740450
Restarting l3 agent results in lost of centralized fip in snat ns
the report seems valid and even has a suggested fix.
asked bhaley to triage.
__
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] Tripleo CI Community meeting tomorrow

[Arx Cruz]

Hello

We are going to have a TripleO CI Community meeting tomorrow 01/03/2018 at
2 pm UTC time.
The meeting is going to happen on BlueJeans [1] and also on IRC on #tripleo
 channel.

After that, we will hold Office Hours starting at 4PM UTC in case someone
from community have any questions related to CI.

Hope to see you there.

1 - https://bluejeans.com/7071866728



Kind regards,
Arx Cruz
__
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] Proposing Luka Peschke (peschk_l) as core for cloudkitty

[Christophe Sauthier]

Hello developers mailing list folks,

I'd like to propose that we add Luka Peschke (peschk_l) as an OpenStack 
cloudkitty core reviewer.


He has been a member of our community for years, contributing very 
seriously in cloudkitty. He also provided many reviews on the project as 
you can see in his activity logs


http://stackalytics.com/report/contribution/cloudkitty/60

His willing to help whenever it is need has been really appreciated !

Current Cloudkitty cores, please respond with +1 or explain your 
opinion if voting against... If there are no objection in the next 5 
days I'll add him.


All the best,

Christophe

Christophe Sauthier
CEO

Objectif Libre : Au service de votre Cloud

+33 (0) 6 16 98 63 96 | christophe.sauth...@objectif-libre.com

www.objectif-libre.com | @objectiflibre | 
www.linkedin.com/company/objectif-libre

Recevez la Pause Cloud Et DevOps : olib.re/abo-pause

__
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