[openstack-dev] [neutron] Update port status to error from l2 agent

[Edan David]

Hi all,

It seems today that the ml2 rpc API only supports reporting that a port is 
up\down,
There may be situations when the l2 agent can fail,
For example SR-IOV agent can report failure when configuring a port on the 
wrong physnet.
In these cases we should how would one report port failed status with the rpc 
messages?
Should we add a new rpc call?
Also it's not clear to me why the documentation in the plugins/ml2/rpc.py file
States that the method 'update_device_down'  function is: "Device no longer 
exists on agent", when it stets the port status to down in admin_state_down.

__
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][UI] Port number for frontend app

[Honza Pokorny]

Hello folks,

We've been using port 3000 for the GUI during development and testing.
Now that we're working on packaging and shipping our code, we're
wondering if port 3000 is still the best choice.

Would 3000 conflict with any other services?  Is there a better option?

Thanks

Honza Pokorny

__
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] [vitrage] relationship_type in static_datasources

[Yujun Zhang]

I'm following the sample configuration in docs [1] to verify how static
datasources works.

It seems `backup` relationship is not displayed in the entity graph view
and neither is it included in topology show.

There is an enumeration for edge labels [2]. Should relationship in static
datasource be limited to it?

[1]
https://github.com/openstack/vitrage/blob/master/doc/source/static-physical-config.rst
[2]
https://github.com/openstack/vitrage/blob/master/vitrage/common/constants.py#L49
__
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] [Kuryr] Proposing vikasc for kuryr-libnetwork core

[Vikas Choudhary]

Thanks everyone!

I really appreciate this. Happy to join Kuryr-Core  :)

We have a great team, very diverse and very dedicated. It's pleasure to
work with all of you.

Thanks,
Vikas Choudhary

On Sat, Aug 20, 2016 at 11:51 PM, Gal Sagie  wrote:

> The entire core team voted +1.
> I have added Vikas to Kuryr core team, Congrats and keep up the good work
>
> Thanks
> Gal.
>
> On Thu, Aug 18, 2016 at 7:56 PM, Mohammad Banikazemi 
> wrote:
>
>> +1
>> Vikas has been working on various aspects of Kuryr with dedication for
>> some time. So yes it's about time :)
>>
>> Best,
>>
>> Mohammad
>>
>>
>> [image: Inactive hide details for Antoni Segura Puimedon ---08/16/2016
>> 05:55:48 PM---Hi Kuryrs, I would like to propose Vikas Choudhary]Antoni
>> Segura Puimedon ---08/16/2016 05:55:48 PM---Hi Kuryrs, I would like to
>> propose Vikas Choudhary for the core team for the
>>
>> From: Antoni Segura Puimedon 
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> Date: 08/16/2016 05:55 PM
>> Subject: [openstack-dev] [Kuryr] Proposing vikasc for kuryr-libnetwork
>> core
>> --
>>
>>
>>
>> Hi Kuryrs,
>>
>> I would like to propose Vikas Choudhary for the core team for the
>> kuryr-libnetwork subproject. Vikas has kept submitting patches and reviews
>> at a very good rhythm in the past cycle and I believe he will help a lot to
>> move kuryr forward.
>>
>> I would also like to propose him for the core team for the
>> kuryr-kubernetes subproject since he has experience in the day to day work
>> with kubernetes and can help with the review and refactoring of the
>> prototype upstreaming.
>>
>> Regards,
>>
>> Antoni Segura Puimedon__
>> 
>> 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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best Regards ,
>
> The G.
>
__
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] Hold off on pushing new patches for config option cleanup

[Michael Still]

So, if this is about preserving CI time, then its cool for me to merge
these on a US Sunday when the gate is otherwise idle, right?

Michael

On Fri, Aug 19, 2016 at 7:02 AM, Sean Dague  wrote:

> On 08/18/2016 04:46 PM, Michael Still wrote:
> > We're still ok with merging existing ones though?
>
> Mostly we'd like to conserve the CI time now. It's about 14.5 node-hours
> to run CI on these patches (probably on about 9 node-hours in the gate).
> With ~800 nodes every patch represents 1.5% of our CI resources (per
> hour) to pass through. There are a ton of these patches up there, so
> even just landing gating ones consumes resources that could go towards
> other more critical fixes / features.
>
> I think the theory is these are fine to merge post freeze / milestone 3,
> when the CI should have cooled down a bit and there is more head room.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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
>



-- 
Rackspace Australia
__
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] Upcoming OpenStackClient 3.0 Release (Monday)

[Dean Troyer]

We're excited to pre-announce the release of OSC 3.0.0. The release is
expected to be approved by the release team during their working hours on
Monday 22 Aug 2016.

This is a **huge** release, and we shuffled things around so we've bumped
our major version. We tried our darndest to not break anything, and where
applicable we deprecated things instead. We have a small number of known,
documented breaking changes, which is why we did a major version bump,
please keep this in mind when upgrading.

We've added a lot of support:
  - We now use keystoneauth for all authentication and client sessions: from
that we will get support for various federated identity protocols as they
are added (saml, openid connect), kerberos, time-base one-time password,
any auth plugin in keystoneauth).
  - Support for various languages: we fixed some basic unicode issues with
OSC, resulting in a much cleaner experience when using non-English languages.
Additional important unicode fixes are being made in cliff and will get
picked up automatically by all releases of OSC when those are released.
  - Lots of new networking commands and additional options for existing
ones.  Too many to list them all here: support for networks, ports,
subnets, ip addresses, routers, network RBAC, security group, etc.
  - Bulk deletion support for nearly all delete commands: when deleting
resources supply as many as you want and we'll try to delete them all, and
report on any that failed.
  - Under the hood we moved a chuck of the common and low-level bits of OSC
into a new `osc-lib` repository to expose them as a documented and stable
library API.  This is now all available to OSC plugins without having to
depend on OpenStackClient itself.  The osc-lib dependency list is very
short, and most of those will already be used by plugins. This also led to
a restructuring of the CLI parsing and shell configuration code to remove
some duplication and overlap with os-client-config and isolate the
remainder in osc-lib.  osc-lib 1.0 has already been released and is now
available for use by plugins.

The known breaking changes are:
  - The `ip floating` commands have been renamed to `floating ip` -- check
the help output for details.  The old commands are still present but
deprecated and no longer appear in help output.
  - Finding role assignments for a user or project using the `roles list`
command has been deprecated, folks should use `role assignment list` for
this operation.

The usual patch will be automatically created to bump the upper-constaints
of OSC. Where possible, we encourage projects that depend on OSC (puppet,
osc-plugins, tripleo, etc) to propose a patch that uses the Depends-On
mechanism (depends on the upper-constaints change), to ensure your gate
won't break.

Thank you to the entire OSC team, we have had a lot of new contributors
this year, many of them working hard on the Networking commands.

dt

-- 

Dean Troyer
dtro...@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] [NOVA] How boot an instance on specific compute with provider-network: physnet1

[Jay Pipes]

On 08/21/2016 03:24 PM, Fawaz Mohammed wrote:

I belive utilizing host aggregate is better than availability zone in
this case.


Users don't know anything about host aggregates. They are a 
cloud-admin-only way of grouping like compute resources together and the 
end user doesn't have any way of specifying a particular host aggregate 
when launching an instance.


Best,
-jay


On Aug 19, 2016 8:33 PM, "Leehom Li (feli5)" mailto:fe...@cisco.com>> wrote:

Hi, All

I used to use below command to boot an instance with a specified IP
address to a
Specified compute node.

nova boot
--image  \
--flavor  \
--nic net-id=,v4-fixed-ip= \
--availability-zone :




May it helps.

leehom

On 8/17/16, 11:53 PM, "Géza Gémes" mailto:geza.ge...@ericsson.com>> wrote:

>On 08/17/2016 05:38 PM, Rick Jones wrote:
>> On 08/17/2016 08:25 AM, Kelam, Koteswara Rao wrote:
>>> Hi All,
>>>
>>> I have two computes
>>>
>>> Compute node 1:
>>> 1. physnet3:br-eth0
>>>
>>> 2. physnet2: br-eth2
>>>
>>> Compute node 2:
>>> 1. physnet3:br-eth0
>>> 2. physnet1:br-eth1
>>> 3. physnet2:br-eth2
>>>
>>> When I boot an instance with a network of provider-network physnet1,
>>> nova is scheduling it on compute1 but there is no physnet1 on
compute1
>>> and it fails.
>>>
>>> Is there any mechanism/way to choose correct compute with correct
>>> provider-network?
>>
>> Well, the --availability-zone option can be given a host name
>> separated from an optional actual availability zone identifier by a
>> colon:
>>
>> nova boot .. --availability-zone :hostname ...
>>
>> But specifying a specific host rather than just an availability zone
>> requires the project to have forced_host (or is it force_host?)
>> capabilities.  You could, perhaps, define the two computes to be
>> separate availability zones to work around that.
>>
>> rick jones
>>
>>
>>
>>_
>>_
>>
>> 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

>
>Hi,
>
>Does it help if you boot your VMs, with pre-created neutron ports,
>rather than a neutron network? I think nova is supposed to bind
then and
>failing that it shall rescedule the VM (up to the configured
re-schedule
>attempts (3 by default)). I think this is an area, where e.g. one
of the
>physnet would relate to an SRIOV PF the PciDeviceFilter would be
able to
>select the right host from beginning.
>
>Cheers,
>
>Geza
>
>
>__
>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] [NOVA] How boot an instance on specific compute with provider-network: physnet1

[Fawaz Mohammed]

I belive utilizing host aggregate is better than availability zone in this
case.

On Aug 19, 2016 8:33 PM, "Leehom Li (feli5)"  wrote:

> Hi, All
>
> I used to use below command to boot an instance with a specified IP
> address to a
> Specified compute node.
>
> nova boot
> --image  \
> --flavor  \
> --nic net-id=,v4-fixed-ip= \
> --availability-zone :
> 
>
>
>
> May it helps.
>
> leehom
>
> On 8/17/16, 11:53 PM, "Géza Gémes"  wrote:
>
> >On 08/17/2016 05:38 PM, Rick Jones wrote:
> >> On 08/17/2016 08:25 AM, Kelam, Koteswara Rao wrote:
> >>> Hi All,
> >>>
> >>> I have two computes
> >>>
> >>> Compute node 1:
> >>> 1. physnet3:br-eth0
> >>>
> >>> 2. physnet2: br-eth2
> >>>
> >>> Compute node 2:
> >>> 1. physnet3:br-eth0
> >>> 2. physnet1:br-eth1
> >>> 3. physnet2:br-eth2
> >>>
> >>> When I boot an instance with a network of provider-network physnet1,
> >>> nova is scheduling it on compute1 but there is no physnet1 on compute1
> >>> and it fails.
> >>>
> >>> Is there any mechanism/way to choose correct compute with correct
> >>> provider-network?
> >>
> >> Well, the --availability-zone option can be given a host name
> >> separated from an optional actual availability zone identifier by a
> >> colon:
> >>
> >> nova boot .. --availability-zone :hostname ...
> >>
> >> But specifying a specific host rather than just an availability zone
> >> requires the project to have forced_host (or is it force_host?)
> >> capabilities.  You could, perhaps, define the two computes to be
> >> separate availability zones to work around that.
> >>
> >> rick jones
> >>
> >>
> >>
> >>__
> ___
> >>_
> >>
> >> 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
> >
> >Hi,
> >
> >Does it help if you boot your VMs, with pre-created neutron ports,
> >rather than a neutron network? I think nova is supposed to bind then and
> >failing that it shall rescedule the VM (up to the configured re-schedule
> >attempts (3 by default)). I think this is an area, where e.g. one of the
> >physnet would relate to an SRIOV PF the PciDeviceFilter would be able to
> >select the right host from beginning.
> >
> >Cheers,
> >
> >Geza
> >
> >
> >___
> ___
> >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-dev] [neutron][ipam] CI failing

[Gary Kotton]

Hi,
Has anyone else seen the issue at 
https://bugs.launchpad.net/neutron/+bug/1615403 . This happens quite often 
since the upgrade of the deafutl value last week.
Thanks
Gary
__
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] [vitrage] gate-vitrage-dsvm-api FAILURE

[Weyl, Alexey (Nokia - IL)]

Hi Yujun,

It seems to be due to changes that were made in other projects.

We have the same problems with our commits.

We are waiting to tomorrow to see it there will be any fixes in those projects 
for those problems.

Alexey

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
Sent: Friday, August 19, 2016 8:46 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [vitrage] gate-vitrage-dsvm-api FAILURE

I submit a simple patch for additional log message but the CI job keeps failure 
even after recheck.

It seems some configuration files are missing according to the console log [2].

Does anybody encountering the same issue as me?

```
2016-08-18 
19:59:15.155472
 | 2016-08-18 19:59:15.155 | ++ 
/opt/stack/new/vitrage/devstack/post_test_hook.sh:source:L31: sudo 
oslo-config-generator --config-file etc/config-generator.tempest.conf 
--output-file etc/tempest.conf
2016-08-18 
19:59:15.402397
 | 2016-08-18 19:59:15.401 | Traceback (most recent call last):2016-08-18 
19:59:15.403804
 | 2016-08-18 19:59:15.403 | File "/usr/local/bin/oslo-config-generator", line 
11, in 
2016-08-18 
19:59:15.405044
 | 2016-08-18 19:59:15.404 | sys.exit(main())
2016-08-18 
19:59:15.406367
 | 2016-08-18 19:59:15.406 | File 
"/usr/local/lib/python2.7/dist-packages/oslo_config/generator.py", line 478, in 
main
2016-08-18 
19:59:15.407918
 | 2016-08-18 19:59:15.407 | conf(args, version=version)
2016-08-18 
19:59:15.409207
 | 2016-08-18 19:59:15.408 | File 
"/usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py", line 2256, in 
__call__
2016-08-18 
19:59:15.410630
 | 2016-08-18 19:59:15.410 | raise 
ConfigFilesNotFoundError(self._namespace._files_not_found)
2016-08-18 
19:59:15.412069
 | 2016-08-18 19:59:15.411 | oslo_config.cfg.ConfigFilesNotFoundError: Failed 
to find some config files: 
/opt/stack/new/tempest/etc/config-generator.tempest.conf
```


[1] https://review.openstack.org/#/c/357001/
[2] 
http://logs.openstack.org/01/357001/1/check/gate-vitrage-dsvm-api/2e679a2/console.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][Higgins] Proposing Sudipta Biswas and Wenzhi Yu for Zun core reviewer team

[Wenzhi Yu (yuywz)]

Thanks Hongbin and Team! I will keep on going :)

2016-08-21



Best Regards,
Wenzhi Yu (yuywz)



发件人：Hongbin Lu 
发送时间：2016-08-19 21:51
主题：Re: [openstack-dev] [Zun][Higgins] Proposing Sudipta Biswas and Wenzhi Yu 
for Zun core reviewer team
收件人："OpenStack Development Mailing List (not for usage 
questions)"
抄送：

Hi all,


Thanks for your vote. According to the feedback, Sudipta and Wenzhi have been 
added to the core team [1].


Best regards,
Hongbin


On Sat, Aug 13, 2016 at 5:44 PM, Fei Long Wang  wrote:

+1

On 12/08/16 19:22, taget wrote:


+1 for both, they would be great addition to zun team.

On 2016年08月12日 10:26, Yanyan Hu wrote:


Both Sudipta and Wenzhi have been actively contributing to the Zun project for 
a while. Sudipta provided helpful advice for the project roadmap and 
architecture design. Wenzhi consistently contributed high quality patches and 
insightful reviews. I think both of them are qualified to join the core team.





-- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--



__
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