Re: [openstack-dev] [mogan] Nominating liusheng for Mogan core

[Zhenguo Niu]

Welcome liusheng to Mogan core!

On Fri, Mar 24, 2017 at 8:23 PM, Feng, Shaohe  wrote:

> Liusheng deserved it for his great contribution.
>
> ＋１
> Thanks.
>
> BR
> Ｓｈａｏｈｅ
>
>
> On Mon, Mar 20, 2017 at 4:19 PM, Zhenguo Niu 
> wrote:
>
>> Hi team,
>>
>> I would like to nominate liusheng to Mogan core. Liusheng has been a
>> significant code contributor since the project's creation providing high
>> quality reviews.
>>
>> Please feel free to respond in public or private your support or any
>> concerns.
>>
>>
>> Thanks,
>> Zhenguo
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>


-- 
Best Regards,
Zhenguo Niu
__
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] [Horizon][searchlight] Sharing resource type implementations

[Richard Jones]

I've completed this work. The two patches to migrate the code over and
one additional bug fix are:

Horizon: Copy os-nova-servers from searchlight ui
  https://review.openstack.org/#/c/444095/

Searchlight UI: Remove os-nova-servers resource type
  https://review.openstack.org/#/c/450067/   (depends-on 444095)

Searchlight UI: Resource detail views have moved
  https://review.openstack.org/#/c/450068/

I have tested Searchlight UI and it doesn't break with the additional
resource type registered, however:

1. There is duplication of actions in the action dropdown for instances rows.
2. The details page link is broken, which is addressed in the separate
bug patch above.
3. The Horizon-side instances list is confused when an unmodified
Searchlight UI is installed - table columns are also duplicated.


Richard

__
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-quickstart][tripleo-ci] Review of critical bugfix

[Sagi Shnaidman]

Hi, all

we have a pretty critical bug in quickstart jobs[1] that ignores status
code of commands, please review its fix[2]. If you have more elegant
solution than setting pipefail or exiting with PIPESTATUS, please suggest
in comments.

Thanks

[1] https://bugs.launchpad.net/tripleo/+bug/1676156
[2] https://review.openstack.org/450023

-- 
Best regards
Sagi Shnaidman
__
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][networking-odl][qa] What's the recommended behavior for SG Rules with ethertype='IPv6' and protocol='icmp' ?

[Sridhar Gaddam]

On Fri, Mar 24, 2017 at 7:27 PM, Brian Haley  wrote:

> On 03/24/2017 06:41 AM, Ghanshyam Mann wrote:
>
>> Hi All,
>>
>> Tempest is testing SG rule creation and pinging scenario tests with
>> ethertype='IPv6' and protocol='icmp' [0].
>> In case of ethertype='IPv6', currently neutron accept protocol type
>> as 'icmp', 'icmpv6' and 'ipv6-icmp' which again seems like duplication
>> of SG rules bug on neutron side but not sure [1]
>>
>> But it seems like some driver does not work with 'icmp' on IPv6, at
>> least ODL as mentioned in bug [2]. Where few others like ML2/OVS
>> iptables driver convert 'icmp' to 'icmpv6' when ethertype='IPv6' and had
>> no issue with 'icmp'.
>>
>> IMO neutron should keep accepting 'icmp' for IPv6 for backward
>> compatibility and legacy usage and tempest should test 'icmp' also along
>> with other protocol type.
>> But we need more feedback on that what is right way (as per backward
>> compatibility pov) and recommended way for having best behaviour for SG
>> rules on IPv6. What best can work for all plugins also?
>>
>
> Thanks for raising this issue.  Let me just restate it a little so it's
> clear.
>
> 1. One can create an IPv6 rule using protocol value "icmp" today, and the
> base security group code does the right thing changing the rule to be
> correct for the underlying implementation, for example, "ipv6-icmp" for
> iptables.  It doesn't look like all other drivers handle this properly.
>
> ​Well, let the Neutron API accept multiple values like
"icmp/icmpv6/ipv6-icmp", but IMO it should store a single Security Group
rule in the DB and raise "Duplicate error when similar rule is configured
once again".
Currently, Neutron treats each of them as a different Security Group rule
and stores them as separate entries in the DB.
However, IPtables Firewall driver in Neutron is converting[1] the
"ethertype=IPv6 and protocol=icmp" as a request to ICMPv6 and applying the
necessary ip-table rule.
https://github.com/openstack/neutron/blob/stable/newton/neutron/agent/linux/iptables_firewall.py#L373

Since this is not a documented behavior, other firewall drivers (which I
guess could be an issue even with OVS firewall driver) may be missing this
info.​


> 2. The neutron API will accept multiple values - "icmp", "ipv6-icmp" and
> "icmpv6" for an IPv6 rule, but it will create unique database entries for
> each (I just verified that).  While that shouldn't create multiple entries
> in the base iptables code, it will probably generate a warning in the logs
> about a duplicate being suppressed.
>
>
> So there are a few things that could be done:
>
> 1. Drivers need to accept "icmp" in order to be backwards-compatible with
> the current code.
>
> 2. Duplicates should be detected and generate 409 (?) errors.
>
> 3. We should add a migration (IMO) where any duplicates are squashed.
>
> ​Agree with your points.
​

> The open question is, do we want to change the DB to have a different
> value here, like "icmpv6" ?  We could obviously add a migration where we
> update the value.  The problem is that flag day could pose a problem if
> out-of-tree drivers don't support the new value.  I think we should leave
> it "icmp" for that reason, thoughts from others?
>
> IMO, the out-of-tree drivers should be supporting the icmpv6 protocol​
rule properly. There is a possibility that they may hit this issue[
https://bugs.launchpad.net/tempest/+bug/1671366] for not being aware that a
request for "Ethertype=IPv6 and protocol=icmp" should be treated as ICMPv6
SG rule.

Please see the DB entries for the two SG rules -
http://paste.openstack.org/show/604190/




> -Brian
>
> __
> 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] [os-client-config] get_session_endpoint() and Keystone admin endpoint

[Akira Yoshiyama]

Hi,

2017-03-25 4:54 GMT+09:00 Monty Taylor :
> On 03/24/2017 10:34 AM, Akira Yoshiyama wrote:
>> Hi Monty,
>>
>> Thank you for your reply.
>>
>> 2017年3月24日(金) 20:58 Monty Taylor > >:
>>
>> On 03/19/2017 07:18 AM, Akira Yoshiyama wrote:
>> > Hi all,
>> >
>> > I have developed Yakumo, a pythonic unified OpenStack client library:
>> >
>> >   PyPI: https://pypi.python.org/pypi/yakumo
>> >   Git: https://github.com/yosshy/python-yakumo
>>
>> Nice library!
>>
>>
>> Thank you :)
>>
>> We use it for our smoke tests.
>>
>> > and I found that
>> > os_client_config.cloud_config.CloudConfig.get_session_endpoint()
>> > didn't return Keystone admin endpoint because of below:
>> >
>> >
>>  
>> https://github.com/openstack/os-client-config/blob/master/os_client_config/cloud_config.py#L258
>> >
>> > Why is it so?
>>
>> It's done that way in os-client-config because not doing it that way
>> breaks python-keystoneclient. Or at least it used to - looking through
>> the keystoneclient code it seems jamie has fixed this now.
>>
>>
>> Wonderful!
>>
>> I'm going to nudge Morgan or Jamie to respond too - I think we might be
>> able to get rid of this conditional (which would make me super happy)
>>
>>
>> How about an extra option like below?
>>
>> def get_session_endpoint(
>> ., allow_identity_admin=False):
>
> I think that's a great idea - you feel like proposing it?

Yes. I'll push a patch for review soon.

Regards,
Akira

__
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