Re: [openstack-dev] [Neutron] Propose Slawek Kaplonski for Neutron core

[Sławomir Kapłoński]

Hi,

Thanks all of You for support. I'm very happy to be part of the team.

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl


> Wiadomość napisana przez Miguel Lavalle  w dniu 
> 06.12.2017, o godz. 16:58:
> 
> Hi Neutron Team,
> 
> It has been a week since Slawek's nomination to Neutron core went out. We 
> have received great positive feedback from the team and community members at 
> large. As a consequence, I want to welcome Slawek to the core team and 
> congratulate him on his hard work and many contributions to OpenStack 
> Networking. Keep it up!
> 
> Cheers
> 
> Miguel
> 
> On Mon, Dec 4, 2017 at 7:06 AM, Anna Taraday  
> wrote:
> +1 !
> Well deserved! 
> 
> On Sun, Dec 3, 2017 at 1:03 PM Gary Kotton  wrote:
> +1
> 
>  
> 
> Welcome to the team!
> 
>  
> 
> From: Miguel Lavalle 
> Reply-To: OpenStack List 
> Date: Wednesday, November 29, 2017 at 9:21 PM
> To: OpenStack List 
> Subject: [openstack-dev] [Neutron] Propose Slawek Kaplonski for Neutron core
> 
>  
> 
> Hi Neutron Team,
> 
>  
> 
> I want to nominate Slawek Kaplonski (irc: slaweq) to Neutron core. Slawek has 
> been an active contributor to the project since the Mitaka cycle. He has been 
> instrumental in the development of the QoS capabilities in Neutron, becoming 
> the lead of the sub-team focused on that set of features. More recently, he 
> has collaborated in the implementation of OVO and is an active participant in 
> the CI sub-team. His number of code reviews during the Queens cycle is on par 
> with the leading core members of the team: 
> http://stackalytics.com/?module=neutron
> 
>  
> 
> In my opinion, his efforts are highly valuable to the team and we will be 
> very lucky to have him as a fully voting core.
> 
>  
> 
> I will keep this nomination open for a week as customary,
> 
>  
> 
> Thank you,
> 
>  
> 
> 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
> -- 
> Regards,
> Ann Taraday
> 
> __
> 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] [openstack-ansible] Cannot connect to prxy server from infra1-repo-container

[Goutham Pratapa]

Hi,

We are trying test environment deployment with openstack-ansible pike
release. After executing setup-hosts.yaml, the lxc-containers were created.
We have an issue while doing apt-get update in infra-repo-container as it
couldn't connect to the proxy server.
The strange this is that the infra-repo-container is not showing ip on any
interface when checked with ip r.
Could you please help us with this issue. Below are some logs on the
container and on the host.

E: Failed to fetch
http://security.ubuntu.com/ubuntu/dists/xenial-security/main/binary-amd64/Packages
Something wicked happened resolving '10.51.40.88:8080' (-9 - Address family
for hostname not supported)

root@infra1-repo-container-a7a137c4:/# ping 10.51.40.88 (proxy server)
connect: Network is unreachable

On Container:

root@infra1-repo-container-a7a137c4:/# cat /etc/network/interfaces
# The loopback network interface
auto lo
iface lo inet loopback
# LXC interface, this is ALWAYS assumed to be DHCP.
auto eth0
iface eth0 inet dhcp
# Load any additional configs
source /etc/network/interfaces.d/*.cfg

root@infra1-repo-container-a7a137c4:/# cat
/etc/network/interfaces.d/eth1.cfg
# Ansible managed

### start generated network for [ eth1 ] ###
auto eth1
iface eth1 inet static
address 192.168.124.126
netmask 255.255.255.0
mtu 1500
post-up sysctl -w net.ipv4.conf.$IFACE.arp_notify=1
post-up ip link set $IFACE address $(cat /sys/class/net/$IFACE/address)
### end generated network for [ eth1 ] ###
root@infra1-repo-container-a7a137c4:/# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse
Iface

On host:

root@ubuntu:/home/ansible# ifconfig lxcbr0
lxcbr0Link encap:Ethernet  HWaddr fe:02:f2:ff:bd:86
  inet addr:10.0.3.1  Bcast:10.0.3.255  Mask:255.255.255.0
  inet6 addr: fe80::a085:76ff:febb:401d/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:691 errors:0 dropped:0 overruns:0 frame:0
  TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:181224 (181.2 KB)  TX bytes:828 (828.0 B)
root@ubuntu:/home/ansible# ip r
default via 192.168.124.1 dev eno1
10.0.3.0/24 dev lxcbr0  proto kernel  scope link  src 10.0.3.1
192.168.124.0/24 dev eno1  proto kernel  scope link  src 192.168.124.28
192.168.124.0/24 dev br-mgmt  proto kernel  scope link  src 192.168.124.28

-- 
Cheers !!!
Goutham Pratapa
__
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] Some historic digging

[Cédric Jeanneret]

Hello,

While trying to add some unit tests for some resources in the
puppet-tripleo repository, I stumbled on a not-so-nice case: the
tripleo::firewall::service_rules definition.

In there, a resource is dynamically taken from hiera, using the
following key structure:
tripleo..firewall_rules

Although this seems to work properly in the tripleo deploy process, it
just doesn't work at all for a unit test.

After some more digging, it appears the "dot" (".") in YAML is a
reserved char for hashes. In the puppet world, we usually use the double
semi-colon, aka "::" as a separator.

Sooo… I'm wondering what's the history behind that non-puppet-standard
choice of "dot" separator, and what would be required in order to move
to a more standard syntax for that kind of resources.

I've checked the puppet-tripleo repository, and apparently only two
resources are using that kind of syntax:
- tripleo::firewall::service_rules (already widely present in the
tripleo-heat-templates)
- tripleo::haproxy::service_endpoints
(at least, those are the only resources using a "$underscore_name" variable)

Currently, if anyone wants to change something close to those two
resources, it won't be tested against regressions, and it's a really bad
situation. Especially since it might break central services (closing all
firewall ports isn't good, for example, or dropping an haproxy endpoint
by mistake)… Unit tests are needed, especially in such a huge piece of
software ;).

Thank you for your historical knowledge and its sharing :).

Cheers,

C.

-- 
Cédric Jeanneret
Senior Linux System Administrator
Infrastructure Solutions

Camptocamp SA
PSE-A / EPFL, 1015 Lausanne

Phone: +41 21 619 10 32
Office: +41 21 619 10 02
Email: cedric.jeanne...@camptocamp.com



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] [tripleo] Proposing Wesley Hayutin core on TripleO CI

[Marios Andreou]

+1 !

On Wed, Dec 6, 2017 at 5:45 PM, Emilien Macchi  wrote:

> Team,
>
> Wes has been consistently and heavily involved in TripleO CI work.
> He has a very well understanding on how tripleo-quickstart and
> tripleo-quickstart-extras work, his number and quality of reviews are
> excellent so far. His experience with testing TripleO is more than
> valuable.
> Also, he's always here to help on TripleO CI issues or just
> improvements (he's the guy filling bugs on a Saturday evening).
> I think he would be a good addition to the TripleO CI core team
> (tripleo-ci, t-q and t-q-e repos for now).
> Anyway, thanks a lot Wes for your hard work on CI, I think it's time
> to move on and get you +2 ;-)
>
> As usual, it's open for voting, feel free to bring any feedback.
> Thanks everyone,
> --
> 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 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] [ceilometer][gnocchi] some code not very understood

[Jaze Lee]

Hello,

   I think at line 416, we should remove some measures that already post at 390.
   Or may be i miss something?

   
https://github.com/openstack/ceilometer/blob/master/ceilometer/publisher/gnocchi.py#L416





-- 
谦谦君子

__
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] Boot from volume 's instance of rebuild operation

[Jaze Lee]

2017-12-07 10:27 GMT+08:00 Mathieu Gagné :
> On Wed, Dec 6, 2017 at 9:13 PM, Jaze Lee  wrote:
>> 2017-12-07 7:12 GMT+08:00 Matt Riedemann :
>>> On 12/6/2017 2:11 AM, 李杰 wrote:

 Hi,all

 Now the boot from volume 's instance of rebuild operation has a
 problem.For example,after the rebuild operation,the instance 's root disk 
 is
 not replace.
 I found the reason is that when we use the "_build_resources" function to
 prepare source,it obtains the block devices according to the previous
 instance 's uuid and attaches them to instance.So boot from volume 's
 instance of rebuild operation doesn't update data.
 To solve it,I plan to use CLI 's "metadata" option,to increase a
 key name "source_type".The "source_type" includes "snapshot" and "image".We
 can judge from "source_type".If the "source_type" is "snapshot",we can
 transform the given snapshot to a volume and attach this volume to
 instance.If the "source_type" is "image",we don't handle it.
 Can you give me some advice?Help in troubleshooting this issue
 will be appreciated.

>>>
>>> See: https://review.openstack.org/#/c/520660/
>>>
>>> We just started disallowing rebuilding a volume-backed instance where the
>>> image changes during the rebuild. We don't support it in the compute
>>> service, as you've found out, so we're going to make it a fast failure in
>>> the API.
>>
>> Well, are there some reasons for you want to disallowing rebuilding a
>> volume-backend instance.
>> Just give the the review is not a convincing answer.
>>
>
> Rebuilding a volume-backed instance never worked. While the API
> currently accepts your request, nothing will happen. The instance
> won't be rebuilt as expected.
>
> There had been a couple of proposals/changes to add support:
> * https://review.openstack.org/#/c/442295/
> * https://review.openstack.org/#/c/305079/
>
> But technical challenges have been uncovered, making it harder to
> implement a proper solution.
>
> The change [1] linked by Matt Riedemann proposes failing rapidly so
> the user isn't under the false impression that a rebuild is being
> performed when in fact, nothing will happen.
>
> I do agree that being able to rebuild a volume-backed instance would
> be a great addition. We have been offering volume-backed instance for
> more than 4 years and our users love it.
> But for now, rebuild just doesn't work at all. It's better to send the
> right message through the API by failing fast.
>
> [1] https://review.openstack.org/#/c/520660/

Oh, I think it is not a proper solution. Adding a fast failure is much easier
than to support rebuilding of volume-backend instance.
I found the last reason to abandon the review at
https://review.openstack.org/#/c/305079/
is because the design is not very clear and lack of bp.
So everyone who wants to add this feature to nova is welcome. Please go ahead.




>
> --
> Mathieu
>
> __
> 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] [masakari] problems starting up masakari instance monitoring in devstack @ master

[Rikimaru Honjo]

Hello Greg,

I forgot to tell you.

Please use process_list.yaml instead of proc.list.sample.

On 2017/12/07 14:03, Rikimaru Honjo wrote:

Hello Greg,

Please use masakarimonitors.conf instead of hostmonitor.conf and 
processmonitor.conf.
You can generate it by "tox -egenconfig".

hostmonitor.conf and processmonitor.conf are used for monitors implemented by 
shell script.
masakarimonitors.conf is a configuration file for monitors implemented by 
python that you installed.

And, we are preparing setting guides.
Please see it if you are good.

masakari:
https://review.openstack.org/#/c/489570/

masakari-monitors:
https://review.openstack.org/#/c/489095/

Best regards,

On 2017/12/06 22:48, Waines, Greg wrote:

I am just getting started working with masakari.
I am working on master.

I have setup Masakari in Devstack (see details at end of email) ... which 
starts up masakari-engine and masakari-api processes.

I have git cloned the masakari-monitors and started them up (roughly) following 
the instructions at https://github.com/openstack/masakari-monitors .
Specifically:
# install & startup monitors
cd
git clone https://github.com/openstack/masakari-monitors.git
cd masakari-monitors
sudo python setup.py install
cd
sudo mkdir /etc/masakarimonitors
sudo cp ~/masakari-monitors/etc/masakarimonitors/hostmonitor.conf.sample 
/etc/masakarimonitors/hostmonitor.conf
sudo cp ~/masakari-monitors/etc/masakarimonitors/processmonitor.conf.sample 
/etc/masakarimonitors/processmonitor.conf
sudo cp ~/masakari-monitors/etc/masakarimonitors/proc.list.sample 
/etc/masakarimonitors/proc.list
cd ~/masakari-monitors/masakarimonitors/cmd
sudo masakari-processmonitor.sh /etc/masakarimonitors/processmonitor.conf 
/etc/masakarimonitors/proc.list &
sudo masakari-hostmonitor.sh /etc/masakarimonitors/hostmonitor.conf &
sudo /usr/bin/python ./instancemonitor.py &

However the instancemonitor.py starts and exits ... and does not appear to 
start any process(es) ... with no error messages and no log file.

Is this the correct way to startup masakari instance monitoring ?

Greg.




My Masakari setup in Devstack

sudo useradd -s /bin/bash -d /opt/stack -m stack
echo "stack ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/stack
sudo su - stack

git clone https://github.com/openstack-dev/devstack
cd devstack

 local.conf file:
[[local|localrc]]
ADMIN_PASSWORD=admin
DATABASE_PASSWORD=admin
RABBIT_PASSWORD=admin
SERVICE_PASSWORD=admin
# setup Neutron services
disable_service n-net
enable_service q-svc
enable_service q-agt
enable_service q-dhcp
enable_service q-l3
enable_service q-meta
# ceilometer
enable_plugin ceilometer https://git.openstack.org/openstack/ceilometer
enable_plugin aodh https://git.openstack.org/openstack/aodh
# heat
enable_plugin heat https://git.openstack.org/openstack/heat
# vitrage
enable_plugin vitrage https://git.openstack.org/openstack/vitrage
enable_plugin vitrage-dashboard 
https://git.openstack.org/openstack/vitrage-dashboard
# masakari
enable_plugin masakari git://git.openstack.org/openstack/masakari


./stack.sh





__
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





--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Rikimaru Honjo
E-mail:honjo.rikim...@po.ntt-tx.co.jp


__
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] [masakari]problems starting up masakari instance monitoring in devstack @ master

[Rikimaru Honjo]

Hello Greg,

Please use masakarimonitors.conf instead of hostmonitor.conf and 
processmonitor.conf.
You can generate it by "tox -egenconfig".

hostmonitor.conf and processmonitor.conf are used for monitors implemented by 
shell script.
masakarimonitors.conf is a configuration file for monitors implemented by 
python that you installed.

And, we are preparing setting guides.
Please see it if you are good.

masakari:
https://review.openstack.org/#/c/489570/

masakari-monitors:
https://review.openstack.org/#/c/489095/

Best regards,

On 2017/12/06 22:48, Waines, Greg wrote:

I am just getting started working with masakari.
I am working on master.

I have setup Masakari in Devstack (see details at end of email) ... which 
starts up masakari-engine and masakari-api processes.

I have git cloned the masakari-monitors and started them up (roughly) following 
the instructions at https://github.com/openstack/masakari-monitors .
Specifically:
# install & startup monitors
cd
git clone https://github.com/openstack/masakari-monitors.git
cd masakari-monitors
sudo python setup.py install
cd
sudo mkdir /etc/masakarimonitors
sudo cp ~/masakari-monitors/etc/masakarimonitors/hostmonitor.conf.sample 
/etc/masakarimonitors/hostmonitor.conf
sudo cp ~/masakari-monitors/etc/masakarimonitors/processmonitor.conf.sample 
/etc/masakarimonitors/processmonitor.conf
sudo cp ~/masakari-monitors/etc/masakarimonitors/proc.list.sample 
/etc/masakarimonitors/proc.list
cd ~/masakari-monitors/masakarimonitors/cmd
sudo masakari-processmonitor.sh /etc/masakarimonitors/processmonitor.conf 
/etc/masakarimonitors/proc.list &
sudo masakari-hostmonitor.sh /etc/masakarimonitors/hostmonitor.conf &
sudo /usr/bin/python ./instancemonitor.py &

However the instancemonitor.py starts and exits ... and does not appear to 
start any process(es) ... with no error messages and no log file.

Is this the correct way to startup masakari instance monitoring ?

Greg.




My Masakari setup in Devstack

sudo useradd -s /bin/bash -d /opt/stack -m stack
echo "stack ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/stack
sudo su - stack

git clone https://github.com/openstack-dev/devstack
cd devstack

 local.conf file:
[[local|localrc]]
ADMIN_PASSWORD=admin
DATABASE_PASSWORD=admin
RABBIT_PASSWORD=admin
SERVICE_PASSWORD=admin
# setup Neutron services
disable_service n-net
enable_service q-svc
enable_service q-agt
enable_service q-dhcp
enable_service q-l3
enable_service q-meta
# ceilometer
enable_plugin ceilometer https://git.openstack.org/openstack/ceilometer
enable_plugin aodh https://git.openstack.org/openstack/aodh
# heat
enable_plugin heat https://git.openstack.org/openstack/heat
# vitrage
enable_plugin vitrage https://git.openstack.org/openstack/vitrage
enable_plugin vitrage-dashboard 
https://git.openstack.org/openstack/vitrage-dashboard
# masakari
enable_plugin masakari git://git.openstack.org/openstack/masakari


./stack.sh





__
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



--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Rikimaru Honjo
E-mail:honjo.rikim...@po.ntt-tx.co.jp



__
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] Boot from volume 's instance of rebuild operation

[Mathieu Gagné]

On Wed, Dec 6, 2017 at 9:13 PM, Jaze Lee  wrote:
> 2017-12-07 7:12 GMT+08:00 Matt Riedemann :
>> On 12/6/2017 2:11 AM, 李杰 wrote:
>>>
>>> Hi,all
>>>
>>> Now the boot from volume 's instance of rebuild operation has a
>>> problem.For example,after the rebuild operation,the instance 's root disk is
>>> not replace.
>>> I found the reason is that when we use the "_build_resources" function to
>>> prepare source,it obtains the block devices according to the previous
>>> instance 's uuid and attaches them to instance.So boot from volume 's
>>> instance of rebuild operation doesn't update data.
>>> To solve it,I plan to use CLI 's "metadata" option,to increase a
>>> key name "source_type".The "source_type" includes "snapshot" and "image".We
>>> can judge from "source_type".If the "source_type" is "snapshot",we can
>>> transform the given snapshot to a volume and attach this volume to
>>> instance.If the "source_type" is "image",we don't handle it.
>>> Can you give me some advice?Help in troubleshooting this issue
>>> will be appreciated.
>>>
>>
>> See: https://review.openstack.org/#/c/520660/
>>
>> We just started disallowing rebuilding a volume-backed instance where the
>> image changes during the rebuild. We don't support it in the compute
>> service, as you've found out, so we're going to make it a fast failure in
>> the API.
>
> Well, are there some reasons for you want to disallowing rebuilding a
> volume-backend instance.
> Just give the the review is not a convincing answer.
>

Rebuilding a volume-backed instance never worked. While the API
currently accepts your request, nothing will happen. The instance
won't be rebuilt as expected.

There had been a couple of proposals/changes to add support:
* https://review.openstack.org/#/c/442295/
* https://review.openstack.org/#/c/305079/

But technical challenges have been uncovered, making it harder to
implement a proper solution.

The change [1] linked by Matt Riedemann proposes failing rapidly so
the user isn't under the false impression that a rebuild is being
performed when in fact, nothing will happen.

I do agree that being able to rebuild a volume-backed instance would
be a great addition. We have been offering volume-backed instance for
more than 4 years and our users love it.
But for now, rebuild just doesn't work at all. It's better to send the
right message through the API by failing fast.

[1] https://review.openstack.org/#/c/520660/

--
Mathieu

__
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] Boot from volume 's instance of rebuild operation

[Jaze Lee]

2017-12-07 7:12 GMT+08:00 Matt Riedemann :
> On 12/6/2017 2:11 AM, 李杰 wrote:
>>
>> Hi,all
>>
>> Now the boot from volume 's instance of rebuild operation has a
>> problem.For example,after the rebuild operation,the instance 's root disk is
>> not replace.
>> I found the reason is that when we use the "_build_resources" function to
>> prepare source,it obtains the block devices according to the previous
>> instance 's uuid and attaches them to instance.So boot from volume 's
>> instance of rebuild operation doesn't update data.
>> To solve it,I plan to use CLI 's "metadata" option,to increase a
>> key name "source_type".The "source_type" includes "snapshot" and "image".We
>> can judge from "source_type".If the "source_type" is "snapshot",we can
>> transform the given snapshot to a volume and attach this volume to
>> instance.If the "source_type" is "image",we don't handle it.
>> Can you give me some advice?Help in troubleshooting this issue
>> will be appreciated.
>>
>
> See: https://review.openstack.org/#/c/520660/
>
> We just started disallowing rebuilding a volume-backed instance where the
> image changes during the rebuild. We don't support it in the compute
> service, as you've found out, so we're going to make it a fast failure in
> the API.

Well, are there some reasons for you want to disallowing rebuilding a
volume-backend instance.
Just give the the review is not a convincing answer.





>
> --
>
> 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 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] [all] TC Report 49

[James E. Blair]

Chris Dent  writes:

> The expansion of the Foundation was talked about at the summit in
> Sydney, but having something happen this quickly was a bit of a
> surprise, leading to some [questions in
> IRC](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-12-05.log.html#t2017-12-05T14:11:33)
> today. Jonathan Bryce showed up to help answer them.

I'd like to address a misconception in that IRC log:

2017-12-05T14:20:56   it does not take long to create a repo on our 
infrastructure
2017-12-05T14:21:14   though I guess without the name flattening, it 
would have been an "openstack" repository

While there's still some work to be done on flattening the namespace for
existing repos, I think it would be quite straightforward to create a
repository for a non-openstack project in gerrit with no prefix (or, of
course, a different prefix).  I don't think that would have been an
obstacle.

And regarding this:

2017-12-05T15:05:30   i'm not sure how much of infra's ci they could 
make use of given https://github.com/kata-containers/tests

I don't see an obstacle to using Zuul right now either -- even before
they have tests.

-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] [nova] Boot from volume 's instance of rebuild operation

[Matt Riedemann]

On 12/6/2017 2:11 AM, 李杰 wrote:

Hi,all

        Now the boot from volume 's instance of rebuild operation has a 
problem.For example,after the rebuild operation,the instance 's root 
disk is not replace.
I found the reason is that when we use the "_build_resources" function 
to prepare source,it obtains the block devices according to the previous 
instance 's uuid and attaches them to instance.So boot from volume 's 
instance of rebuild operation doesn't update data.
        To solve it,I plan to use CLI 's "metadata" option,to increase a 
key name "source_type".The "source_type" includes "snapshot" and 
"image".We can judge from "source_type".If the "source_type" is 
"snapshot",we can transform the given snapshot to a volume and attach 
this volume to instance.If the "source_type" is "image",we don't handle it.
        Can you give me some advice?Help in troubleshooting this issue 
will be appreciated.




See: https://review.openstack.org/#/c/520660/

We just started disallowing rebuilding a volume-backed instance where 
the image changes during the rebuild. We don't support it in the compute 
service, as you've found out, so we're going to make it a fast failure 
in the API.


--

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

Re: [openstack-dev] Removing Keystoneauth Dependency in Castellan Discussion

[Doug Hellmann]

Excerpts from Gage Hugo's message of 2017-12-06 15:16:14 -0600:
> It's been a bit since the summit but I believe this was also discussed at
> the Denver PTG as well:  https://etherpad.openstack.org/p/oslo-ptg-queens
> 
> The keystoneauth stuff seems to be more from Sydney, but if I remember
> correctly, Castellan authenticates through keystoneauth and passes the
> session to barbicanclient.  This is the only use of keystoneauth within
> Castellan, so one idea that was mentioned was to see if Castellan could
> simply pass the credentials to barbicanclient, which would auth through
> keystoneauth instead, removing the dependency from Castellan.

It looks like Castellan tries to authenticate using the token from
the context in two separate cases [1]. That would cause the service
using castellan to connect to barbican as the user making the API
request. Removing the use of keystoneauth would mean that feature
would no longer work, and all requests to barbican would be made
as a hard-coded user.  That seems like a pretty fundamental difference
in behavior.

Which mode is used the most in the services that consume castellan
today?

I'm still not understanding the real motivation for removing the
dependency. Is it just someone's notion of cleaning things up? Or is
there a runtime issue of some sort?

Doug

[1] 
http://git.openstack.org/cgit/openstack/castellan/tree/castellan/key_manager/barbican_key_manager.py#n140

> 
> On Tue, Dec 5, 2017 at 10:54 AM, Doug Hellmann 
> wrote:
> 
> > Excerpts from ARORA, ROHAN's message of 2017-12-05 14:37:49 +:
> > > So from my understanding now, we are wanting to remove the HARD
> > dependency on Keystoneauth, not to remove it completely since that would
> > break the barbican client. Currently seeing if we just remove the
> > dependency from requirements.txt, if that stops Keystoneauth from being
> > used until you try to use the barbican.
> >
> > There would need to be more changes than that, because we still need the
> > package to be installed for testing the Barbican driver.
> >
> > Maybe if someone could explain what the issue is, I can offer more
> > detailed advice. What is wrong with having the keystoneauth dependency?
> > Is it breaking something? Is it interfering with some other library?
> >
> > 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] Removing Keystoneauth Dependency in Castellan Discussion

[Gage Hugo]

It's been a bit since the summit but I believe this was also discussed at
the Denver PTG as well:  https://etherpad.openstack.org/p/oslo-ptg-queens

The keystoneauth stuff seems to be more from Sydney, but if I remember
correctly, Castellan authenticates through keystoneauth and passes the
session to barbicanclient.  This is the only use of keystoneauth within
Castellan, so one idea that was mentioned was to see if Castellan could
simply pass the credentials to barbicanclient, which would auth through
keystoneauth instead, removing the dependency from Castellan.

On Tue, Dec 5, 2017 at 10:54 AM, Doug Hellmann 
wrote:

> Excerpts from ARORA, ROHAN's message of 2017-12-05 14:37:49 +:
> > So from my understanding now, we are wanting to remove the HARD
> dependency on Keystoneauth, not to remove it completely since that would
> break the barbican client. Currently seeing if we just remove the
> dependency from requirements.txt, if that stops Keystoneauth from being
> used until you try to use the barbican.
>
> There would need to be more changes than that, because we still need the
> package to be installed for testing the Barbican driver.
>
> Maybe if someone could explain what the issue is, I can offer more
> detailed advice. What is wrong with having the keystoneauth dependency?
> Is it breaking something? Is it interfering with some other library?
>
> 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] [heat][qa] Split tempest plugin from heat

[Zane Bitter]

OK, an update on this. The current plan of record after the team meeting 
today goes something like this:


1) Identify tests that are moving to the new plugin repo, and remove 
them from the heat repo.
2) Start using the utils (base classes &c.) from the plugin repo in the 
remaining heat tests.
3) Find a way to run both the plugin tests and the in-repo tests as part 
of the same test run in the gate.

4) Remove the tests that are _not_ moving from the plugin repo.

There's been some interesting related discussion on 
https://review.openstack.org/#/c/521602/ that I'd encourage everyone to 
read. I like the idea of a configurable plugin system that's independent 
of Tempest to solve (3), but we'll see what comes out of that 
discussion. If that doesn't pan out then we can probably still do it the 
old-fashioned way.


I made a first pass at categorising the tests based on the categories I 
identified in that discussion here:


https://etherpad.openstack.org/p/heat-integration-test-categories

If other Heat folks could take a look and comment on/move stuff they 
think is wrong, that would be helpful. In particular, I'm pretty 
uncertain whether most of the things I listed under Interop Tests are 
actually good candidates for interop testing, or if they should just be 
regression tests.


thanks,
Zane.

__
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] overcloud keystone error "Could not determine a suitable URL for the plugin"

[Juan Antonio Osorio]

By using the ssl_overcloud flag in your configuration and setting it to
true.

On 6 Dec 2017 17:33, "Moshe Levi"  wrote:

> How do I tell quickstart to generate certs and enable tls?
>
>
>
> *From:* Juan Antonio Osorio [mailto:jaosor...@gmail.com]
> *Sent:* Wednesday, December 6, 2017 5:24 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [tripleo] overcloud keystone error "Could
> not determine a suitable URL for the plugin"
>
>
>
>
>
>
>
> On 6 Dec 2017 16:58, "Moshe Levi"  wrote:
>
> I have the access to 10.0.0.0 network
>
> I remove the
>
> -e /home/stack/enable-tls.yaml -e 
> ~/heat-templates/environments/tls-endpoints-public-ip.yaml
> -e /home/stack/inject-trust-anchor.yaml
>
> Form the ./overcloud-deploy.sh and now it working
>
> The issue you posted wasn't a TLS issue, but it might be that it was being
> hidden by nova. You could truly to access keystone directly and that will
> be more revealing.
>
>
>
> My /home/stack/enable-tls.yaml and /home/stack/inject-trust-anchor.yaml
> were taken from
>
> wget https://raw.githubusercontent.com/openstack-infra/tripleo-ci/
> master/test-environments/enable-tls.yaml
> 
>
> wget https://raw.githubusercontent.com/openstack-infra/tripleo-ci/
> master/test-environments/inject-trust-anchor.yaml
> 
>
> This will only work if you use the exact same fixed IP as we use in CI. So
> i don't recommend using that. Rather generate your own certs or tell
> quickstart to do it for you by using the appropriate flag.
>
>
>
> So maybe the is an issue with tripleo or just these config files
>
>
>
> *From:* Juan Antonio Osorio [mailto:jaosor...@gmail.com]
> *Sent:* Wednesday, December 6, 2017 12:36 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [tripleo] overcloud keystone error "Could
> not determine a suitable URL for the plugin"
>
>
>
> From the node you're running the nova command, do you have access to the
> 10.0.0.0 network (external)?
>
>
>
> In virtual environments, quickstart will leave an
> overcloud-prep-network.sh script that will create a vlan interface that
> gives the undercloud access to that network. So, if it's a virtual
> environment and you're running that command from the undercloud (which from
> the log you sent it seems that's the case) you need to run that. Note that
> you need to run that every time you update your undercloud.
>
>
>
> BR
>
>
>
>
>
> On 6 Dec 2017 09:06, "Moshe Levi"  wrote:
>
> Hi all,
>
>
>
> We deploy tripleo master using quickstart.
>
> We this delorean repo:
>
> name=delorean
>
> baseurl=https://trunk.rdoproject.org/centos7-master/ac/82/
> ac82ea9271a4ae3860528eaf8a813da7209e62a6_28eeb6c7/
> 
>
>
>
> The undercloud and overcloud deployment were successfully, but we I try to
> run command on the overcloud
>
> I am getting the  keystone error "Could not determine a suitable URL for
> the plugin"
>
> See nova-list with debug info [1]
>
> Do you know how to resolve this? Help in troubleshooting this issue will
> be appreciated.
>
>
>
>
>
> [1]  http://paste.openstack.org/show/628240/
> 
>
>
>
>
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

Re: [openstack-dev] [tripleo] Proposing Wesley Hayutin core on TripleO CI

[Juan Antonio Osorio]

+1

On 6 Dec 2017 18:25, "Harry Rybacki"  wrote:

On Wed, Dec 6, 2017 at 11:19 AM, mathieu bultel  wrote:
> On 12/06/2017 04:45 PM, Emilien Macchi wrote:
>> Team,
>>
>> Wes has been consistently and heavily involved in TripleO CI work.
>> He has a very well understanding on how tripleo-quickstart and
>> tripleo-quickstart-extras work, his number and quality of reviews are
>> excellent so far. His experience with testing TripleO is more than
>> valuable.
>> Also, he's always here to help on TripleO CI issues or just
>> improvements (he's the guy filling bugs on a Saturday evening).
>> I think he would be a good addition to the TripleO CI core team
>> (tripleo-ci, t-q and t-q-e repos for now).
>> Anyway, thanks a lot Wes for your hard work on CI, I think it's time
>> to move on and get you +2 ;-)
>>
>> As usual, it's open for voting, feel free to bring any feedback.
>> Thanks everyone,
>
> +1 of course
>
+1!
>
> __
> 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] [tripleo] Proposing Wesley Hayutin core on TripleO CI

[Harry Rybacki]

On Wed, Dec 6, 2017 at 11:19 AM, mathieu bultel  wrote:
> On 12/06/2017 04:45 PM, Emilien Macchi wrote:
>> Team,
>>
>> Wes has been consistently and heavily involved in TripleO CI work.
>> He has a very well understanding on how tripleo-quickstart and
>> tripleo-quickstart-extras work, his number and quality of reviews are
>> excellent so far. His experience with testing TripleO is more than
>> valuable.
>> Also, he's always here to help on TripleO CI issues or just
>> improvements (he's the guy filling bugs on a Saturday evening).
>> I think he would be a good addition to the TripleO CI core team
>> (tripleo-ci, t-q and t-q-e repos for now).
>> Anyway, thanks a lot Wes for your hard work on CI, I think it's time
>> to move on and get you +2 ;-)
>>
>> As usual, it's open for voting, feel free to bring any feedback.
>> Thanks everyone,
>
> +1 of course
>
+1!
>
> __
> 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] Proposing Wesley Hayutin core on TripleO CI

[mathieu bultel]

On 12/06/2017 04:45 PM, Emilien Macchi wrote:
> Team,
>
> Wes has been consistently and heavily involved in TripleO CI work.
> He has a very well understanding on how tripleo-quickstart and
> tripleo-quickstart-extras work, his number and quality of reviews are
> excellent so far. His experience with testing TripleO is more than
> valuable.
> Also, he's always here to help on TripleO CI issues or just
> improvements (he's the guy filling bugs on a Saturday evening).
> I think he would be a good addition to the TripleO CI core team
> (tripleo-ci, t-q and t-q-e repos for now).
> Anyway, thanks a lot Wes for your hard work on CI, I think it's time
> to move on and get you +2 ;-)
>
> As usual, it's open for voting, feel free to bring any feedback.
> Thanks everyone,

+1 of course


__
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] Proposing Wesley Hayutin core on TripleO CI

[Martin André]

+1

On Wed, Dec 6, 2017 at 4:45 PM, Emilien Macchi  wrote:
> Team,
>
> Wes has been consistently and heavily involved in TripleO CI work.
> He has a very well understanding on how tripleo-quickstart and
> tripleo-quickstart-extras work, his number and quality of reviews are
> excellent so far. His experience with testing TripleO is more than
> valuable.
> Also, he's always here to help on TripleO CI issues or just
> improvements (he's the guy filling bugs on a Saturday evening).
> I think he would be a good addition to the TripleO CI core team
> (tripleo-ci, t-q and t-q-e repos for now).
> Anyway, thanks a lot Wes for your hard work on CI, I think it's time
> to move on and get you +2 ;-)
>
> As usual, it's open for voting, feel free to bring any feedback.
> Thanks everyone,
> --
> 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 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] Proposing Wesley Hayutin core on TripleO CI

[Jiří Stránský]

+1

On 6.12.2017 16:45, Emilien Macchi wrote:

Team,

Wes has been consistently and heavily involved in TripleO CI work.
He has a very well understanding on how tripleo-quickstart and
tripleo-quickstart-extras work, his number and quality of reviews are
excellent so far. His experience with testing TripleO is more than
valuable.
Also, he's always here to help on TripleO CI issues or just
improvements (he's the guy filling bugs on a Saturday evening).
I think he would be a good addition to the TripleO CI core team
(tripleo-ci, t-q and t-q-e repos for now).
Anyway, thanks a lot Wes for your hard work on CI, I think it's time
to move on and get you +2 ;-)

As usual, it's open for voting, feel free to bring any feedback.
Thanks everyone,




__
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] [policy] [rbac] No meetings until 2017-01-03

[Lance Bragstad]

The date in the subject line should be 2018-01-03, not 2017... Sorry
about the confusion.

On 12/06/2017 10:12 AM, Lance Bragstad wrote:
> Hey all,
>
> Sending out a note that there won't be a policy meeting for the
> remainder of December. Folks are focusing on the community goal and
> feature work. We'll pick up policy meetings once things settle down
> after the holidays.
>
> Thanks!
>
> Lance
>
>




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

[openstack-dev] [policy] [rbac] No meetings until 2017-01-03

[Lance Bragstad]

Hey all,

Sending out a note that there won't be a policy meeting for the
remainder of December. Folks are focusing on the community goal and
feature work. We'll pick up policy meetings once things settle down
after the holidays.

Thanks!

Lance




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] [tripleo] Proposing Wesley Hayutin core on TripleO CI

[Alex Schultz]

+1

On Wed, Dec 6, 2017 at 8:45 AM, Emilien Macchi  wrote:
> Team,
>
> Wes has been consistently and heavily involved in TripleO CI work.
> He has a very well understanding on how tripleo-quickstart and
> tripleo-quickstart-extras work, his number and quality of reviews are
> excellent so far. His experience with testing TripleO is more than
> valuable.
> Also, he's always here to help on TripleO CI issues or just
> improvements (he's the guy filling bugs on a Saturday evening).
> I think he would be a good addition to the TripleO CI core team
> (tripleo-ci, t-q and t-q-e repos for now).
> Anyway, thanks a lot Wes for your hard work on CI, I think it's time
> to move on and get you +2 ;-)
>
> As usual, it's open for voting, feel free to bring any feedback.
> Thanks everyone,
> --
> 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 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] Propose Slawek Kaplonski for Neutron core

[Miguel Lavalle]

Hi Neutron Team,

It has been a week since Slawek's nomination to Neutron core went out. We
have received great positive feedback from the team and community members
at large. As a consequence, I want to welcome Slawek to the core team and
congratulate him on his hard work and many contributions to OpenStack
Networking. Keep it up!

Cheers

Miguel

On Mon, Dec 4, 2017 at 7:06 AM, Anna Taraday 
wrote:

> +1 !
> Well deserved!
>
> On Sun, Dec 3, 2017 at 1:03 PM Gary Kotton  wrote:
>
>> +1
>>
>>
>>
>> Welcome to the team!
>>
>>
>>
>> *From: *Miguel Lavalle 
>> *Reply-To: *OpenStack List 
>> *Date: *Wednesday, November 29, 2017 at 9:21 PM
>> *To: *OpenStack List 
>> *Subject: *[openstack-dev] [Neutron] Propose Slawek Kaplonski for
>> Neutron core
>>
>>
>>
>> Hi Neutron Team,
>>
>>
>>
>> I want to nominate Slawek Kaplonski (irc: slaweq) to Neutron core. Slawek
>> has been an active contributor to the project since the Mitaka cycle. He
>> has been instrumental in the development of the QoS capabilities in
>> Neutron, becoming the lead of the sub-team focused on that set of features.
>> More recently, he has collaborated in the implementation of OVO and is an
>> active participant in the CI sub-team. His number of code reviews during
>> the Queens cycle is on par with the leading core members of the team:
>> http://stackalytics.com/?module=neutron
>> 
>>
>>
>>
>> In my opinion, his efforts are highly valuable to the team and we will be
>> very lucky to have him as a fully voting core.
>>
>>
>>
>> I will keep this nomination open for a week as customary,
>>
>>
>>
>> Thank you,
>>
>>
>>
>> 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
>>
> --
> Regards,
> Ann Taraday
>
> __
> 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] Proposing Wesley Hayutin core on TripleO CI

[Emilien Macchi]

Team,

Wes has been consistently and heavily involved in TripleO CI work.
He has a very well understanding on how tripleo-quickstart and
tripleo-quickstart-extras work, his number and quality of reviews are
excellent so far. His experience with testing TripleO is more than
valuable.
Also, he's always here to help on TripleO CI issues or just
improvements (he's the guy filling bugs on a Saturday evening).
I think he would be a good addition to the TripleO CI core team
(tripleo-ci, t-q and t-q-e repos for now).
Anyway, thanks a lot Wes for your hard work on CI, I think it's time
to move on and get you +2 ;-)

As usual, it's open for voting, feel free to bring any feedback.
Thanks everyone,
-- 
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

Re: [openstack-dev] [tripleo] overcloud keystone error "Could not determine a suitable URL for the plugin"

[Moshe Levi]

How do I tell quickstart to generate certs and enable tls?

From: Juan Antonio Osorio [mailto:jaosor...@gmail.com]
Sent: Wednesday, December 6, 2017 5:24 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [tripleo] overcloud keystone error "Could not 
determine a suitable URL for the plugin"



On 6 Dec 2017 16:58, "Moshe Levi" 
mailto:mosh...@mellanox.com>> wrote:
I have the access to 10.0.0.0 network
I remove the
-e /home/stack/enable-tls.yaml -e 
~/heat-templates/environments/tls-endpoints-public-ip.yaml -e 
/home/stack/inject-trust-anchor.yaml
Form the ./overcloud-deploy.sh and now it working
The issue you posted wasn't a TLS issue, but it might be that it was being 
hidden by nova. You could truly to access keystone directly and that will be 
more revealing.

My /home/stack/enable-tls.yaml and /home/stack/inject-trust-anchor.yaml  were 
taken from

wget 
https://raw.githubusercontent.com/openstack-infra/tripleo-ci/master/test-environments/enable-tls.yaml

wget 
https://raw.githubusercontent.com/openstack-infra/tripleo-ci/master/test-environments/inject-trust-anchor.yaml
This will only work if you use the exact same fixed IP as we use in CI. So i 
don't recommend using that. Rather generate your own certs or tell quickstart 
to do it for you by using the appropriate flag.

So maybe the is an issue with tripleo or just these config files

From: Juan Antonio Osorio 
[mailto:jaosor...@gmail.com]
Sent: Wednesday, December 6, 2017 12:36 PM
To: OpenStack Development Mailing List (not for usage questions) 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [tripleo] overcloud keystone error "Could not 
determine a suitable URL for the plugin"

From the node you're running the nova command, do you have access to the 
10.0.0.0 network (external)?

In virtual environments, quickstart will leave an overcloud-prep-network.sh 
script that will create a vlan interface that gives the undercloud access to 
that network. So, if it's a virtual environment and you're running that command 
from the undercloud (which from the log you sent it seems that's the case) you 
need to run that. Note that you need to run that every time you update your 
undercloud.

BR


On 6 Dec 2017 09:06, "Moshe Levi" 
mailto:mosh...@mellanox.com>> wrote:
Hi all,

We deploy tripleo master using quickstart.
We this delorean repo:
name=delorean
baseurl=https://trunk.rdoproject.org/centos7-master/ac/82/ac82ea9271a4ae3860528eaf8a813da7209e62a6_28eeb6c7/

The undercloud and overcloud deployment were successfully, but we I try to run 
command on the overcloud
I am getting the  keystone error "Could not determine a suitable URL for the 
plugin"
See nova-list with debug info [1]
Do you know how to resolve this? Help in troubleshooting this issue will be 
appreciated.


[1]  
http://paste.openstack.org/show/628240/





__
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] overcloud keystone error "Could not determine a suitable URL for the plugin"

[Juan Antonio Osorio]

On 6 Dec 2017 16:58, "Moshe Levi"  wrote:

I have the access to 10.0.0.0 network

I remove the

-e /home/stack/enable-tls.yaml -e
~/heat-templates/environments/tls-endpoints-public-ip.yaml
-e /home/stack/inject-trust-anchor.yaml

Form the ./overcloud-deploy.sh and now it working

The issue you posted wasn't a TLS issue, but it might be that it was being
hidden by nova. You could truly to access keystone directly and that will
be more revealing.



My /home/stack/enable-tls.yaml and /home/stack/inject-trust-anchor.yaml
were taken from

wget https://raw.githubusercontent.com/openstack-infra/tripleo-ci/
master/test-environments/enable-tls.yaml

wget https://raw.githubusercontent.com/openstack-infra/tripleo-ci/
master/test-environments/inject-trust-anchor.yaml

This will only work if you use the exact same fixed IP as we use in CI. So
i don't recommend using that. Rather generate your own certs or tell
quickstart to do it for you by using the appropriate flag.



So maybe the is an issue with tripleo or just these config files



*From:* Juan Antonio Osorio [mailto:jaosor...@gmail.com]
*Sent:* Wednesday, December 6, 2017 12:36 PM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [tripleo] overcloud keystone error "Could
not determine a suitable URL for the plugin"



>From the node you're running the nova command, do you have access to the
10.0.0.0 network (external)?



In virtual environments, quickstart will leave an overcloud-prep-network.sh
script that will create a vlan interface that gives the undercloud access
to that network. So, if it's a virtual environment and you're running that
command from the undercloud (which from the log you sent it seems that's
the case) you need to run that. Note that you need to run that every time
you update your undercloud.



BR





On 6 Dec 2017 09:06, "Moshe Levi"  wrote:

Hi all,



We deploy tripleo master using quickstart.

We this delorean repo:

name=delorean

baseurl=https://trunk.rdoproject.org/centos7-master/ac/82/
ac82ea9271a4ae3860528eaf8a813da7209e62a6_28eeb6c7/




The undercloud and overcloud deployment were successfully, but we I try to
run command on the overcloud

I am getting the  keystone error "Could not determine a suitable URL for
the plugin"

See nova-list with debug info [1]

Do you know how to resolve this? Help in troubleshooting this issue will be
appreciated.





[1]  http://paste.openstack.org/show/628240/











__
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] [qa][all] QA Office Hours on 07th Dec, 2017

[Chandan kumar]

Hello All,

a kind reminder that tomorrow at 9:00 UTC we'll start office hours for
the QA team in the #openstack-qa channel.
Please join us with any question/comment you may have related to
tempest plugin split community goal, tempest and others QA tools.

We'll triage bugs for QA projects from the past 7 days and then extend
the time frame if there is time left.

Thanks,

Chandan Kumar

__
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] overcloud keystone error "Could not determine a suitable URL for the plugin"

[Moshe Levi]

I have the access to 10.0.0.0 network
I remove the
-e /home/stack/enable-tls.yaml -e 
~/heat-templates/environments/tls-endpoints-public-ip.yaml -e 
/home/stack/inject-trust-anchor.yaml
Form the ./overcloud-deploy.sh and now it working

My /home/stack/enable-tls.yaml and /home/stack/inject-trust-anchor.yaml  were 
taken from

wget 
https://raw.githubusercontent.com/openstack-infra/tripleo-ci/master/test-environments/enable-tls.yaml

wget 
https://raw.githubusercontent.com/openstack-infra/tripleo-ci/master/test-environments/inject-trust-anchor.yaml

So maybe the is an issue with tripleo or just these config files

From: Juan Antonio Osorio [mailto:jaosor...@gmail.com]
Sent: Wednesday, December 6, 2017 12:36 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [tripleo] overcloud keystone error "Could not 
determine a suitable URL for the plugin"

From the node you're running the nova command, do you have access to the 
10.0.0.0 network (external)?

In virtual environments, quickstart will leave an overcloud-prep-network.sh 
script that will create a vlan interface that gives the undercloud access to 
that network. So, if it's a virtual environment and you're running that command 
from the undercloud (which from the log you sent it seems that's the case) you 
need to run that. Note that you need to run that every time you update your 
undercloud.

BR


On 6 Dec 2017 09:06, "Moshe Levi" 
mailto:mosh...@mellanox.com>> wrote:
Hi all,

We deploy tripleo master using quickstart.
We this delorean repo:
name=delorean
baseurl=https://trunk.rdoproject.org/centos7-master/ac/82/ac82ea9271a4ae3860528eaf8a813da7209e62a6_28eeb6c7/

The undercloud and overcloud deployment were successfully, but we I try to run 
command on the overcloud
I am getting the  keystone error "Could not determine a suitable URL for the 
plugin"
See nova-list with debug info [1]
Do you know how to resolve this? Help in troubleshooting this issue will be 
appreciated.


[1]  
http://paste.openstack.org/show/628240/





__
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] [horizon][heat] heat-dashboard is ready for Horizon team's review

[Kaz Shinohara]

Hi Akihiro, Horizon team,


Thanks a lot for your help as always:)

>> Thanks for updating the horizon patch. Is it ready to merge from the
>> perspective of heat dashboard team?
Yes, we think it's ready to be merged.

>> Perhaps the system panel needs to be pluggable.
>> As of now, it sounds no problem to remove the list of head services 
>> temporarily.
I had talked with Heat team & got no objection on this, looks it's ok
to remove it temporarily.
Making it pluggable sounds nice, hopefully we will have further
discussion in next PTG.

> IIRC about 25 bugs were forwarded. I hope heat-dashboard team can
> investigate them.
Thank you, we will work for them!

Regards,
Kaz



2017-12-06 15:49 GMT+09:00 Akihiro Motoki :
> I have another announcement on heat-dashboard split out.
>
> I moved the horizon bugs related to heat to heat-dashboard launchpad
> project last week.
> IIRC about 25 bugs were forwarded. I hope heat-dashboard team can
> investigate them.
>
> Akihiro
>
> 2017-12-06 15:46 GMT+09:00 Akihiro Motoki :
>> Hi Kaz,
>>
>> 2017-12-05 18:45 GMT+09:00 Kaz Shinohara :
>>> Hi Akihiro, Horizon & Heat team,
>>>
>>>
>>> We've slightly updated your change for the split out, please check
>>> https://review.openstack.org/#/c/523402/
>>
>> Thanks for updating the horizon patch. Is it ready to merge from the
>> perspective of heat dashboard team?
>>
>>> One non-voting job failed but hopefully not related to this change.
>>
>> The failing non-voting job is not related to the patch.
>> It is for Django 2.0 support but horizon has not support Django 2.0,
>> so it always fails now.
>>
>>> In parallel, we could confirm that heat-dashboard works without any
>>> issue along with this change.
>>>
>>> Also resolved the points what Akihiro kindly commented.
>>> https://etherpad.openstack.org/p/heat-dashboard-review-point
>>>
>>> The thing we should discuss going forward is how to handle admin info
>>> panel for Heat.
>>> Personally information we can see from the panel is really limited,
>>> just a list of heat engine services, so might be ok to be removed.
>>> https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/admin/info/tables.py#L256
>>> I've never seen other dashboards supporting admin functions, better to
>>> follow others & keep simplicity.
>>> Any opinion will be welcome :)
>>
>> Yeah, it makes sense.
>>
>> Perhaps the system panel needs to be pluggable.
>> As of now, it sounds no problem to remove the list of head services 
>> temporarily.
>>
>> Thanks,
>> Akihiro
>>
>>>
>>> Regards,
>>> Kaz
>>>
>>>
>>> 2017-11-29 12:39 GMT+09:00 Kaz Shinohara :
 Hi Akihiro,


 Thanks for your quick response!

 As you requested, we will check & update your patch to slit out heat
 support from Horizon repo.
 https://review.openstack.org/#/c/523402/

 Also replied for your comment in our etherpad, please kindly check.
 https://etherpad.openstack.org/p/heat-dashboard-review-point

 Regards,
 Kaz

 2017-11-28 21:08 GMT+09:00 Akihiro Motoki :
> Hi Kaz,
>
> Good hear the good progress of heat-dashboard. Thanks.
>
> I created a blueprint in horizon to track the effort (mainly in
> horizon side) and assign it to you:
> https://blueprints.launchpad.net/horizon/+spec/heat-dashboard-split-out
> I also left comments in your etherpad.
>
> I think it is time to prepare a patch which drops heat-dashboard code
> from horizon and test the new dashboard with it. Could you propose the
> patch?
>
> Thanks,
> Akihiro
>
>
> 2017-11-28 16:32 GMT+09:00 Kaz Shinohara :
>> Hi Horizon team,
>>
>>
>> As I talked with Rob & Ying in Sydney, now heat-dashboard repo is
>> ready, please kindly review it.
>>
>> http://git.openstack.org/cgit/openstack/heat-dashboard
>>
>> Also we described points to be clarified in this review, if you find
>> anything to be noted/fixed, please feel free to put your comment on
>> this etherpad, we will respond to them.
>>
>> https://etherpad.openstack.org/p/heat-dashboard-review-point
>>
>> We are planning to land heat-dashboard in queens-2, hopefully we will
>> fix any issue until then.
>>
>> Your cooperation will be highly appreciated.
>>
>> Regards,
>> Kaz Shinohara
>>
>> __
>> 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] [masakari] problems starting up masakari instance monitoring in devstack @ master

[Waines, Greg]

I am just getting started working with masakari.
I am working on master.

I have setup Masakari in Devstack (see details at end of email) ... which 
starts up masakari-engine and masakari-api processes.

I have git cloned the masakari-monitors and started them up (roughly) following 
the instructions at https://github.com/openstack/masakari-monitors .
Specifically:
# install & startup monitors
cd
git clone https://github.com/openstack/masakari-monitors.git
cd masakari-monitors
sudo python setup.py install
cd
sudo mkdir /etc/masakarimonitors
sudo cp ~/masakari-monitors/etc/masakarimonitors/hostmonitor.conf.sample 
/etc/masakarimonitors/hostmonitor.conf
sudo cp ~/masakari-monitors/etc/masakarimonitors/processmonitor.conf.sample 
/etc/masakarimonitors/processmonitor.conf
sudo cp ~/masakari-monitors/etc/masakarimonitors/proc.list.sample 
/etc/masakarimonitors/proc.list
cd ~/masakari-monitors/masakarimonitors/cmd
sudo masakari-processmonitor.sh /etc/masakarimonitors/processmonitor.conf 
/etc/masakarimonitors/proc.list &
sudo masakari-hostmonitor.sh /etc/masakarimonitors/hostmonitor.conf &
sudo /usr/bin/python ./instancemonitor.py &

However the instancemonitor.py starts and exits ... and does not appear to 
start any process(es) ... with no error messages and no log file.

Is this the correct way to startup masakari instance monitoring ?

Greg.




My Masakari setup in Devstack

sudo useradd -s /bin/bash -d /opt/stack -m stack
echo "stack ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/stack
sudo su - stack

git clone https://github.com/openstack-dev/devstack
cd devstack

local.conf file:
[[local|localrc]]
ADMIN_PASSWORD=admin
DATABASE_PASSWORD=admin
RABBIT_PASSWORD=admin
SERVICE_PASSWORD=admin
# setup Neutron services
disable_service n-net
enable_service q-svc
enable_service q-agt
enable_service q-dhcp
enable_service q-l3
enable_service q-meta
# ceilometer
enable_plugin ceilometer https://git.openstack.org/openstack/ceilometer
enable_plugin aodh https://git.openstack.org/openstack/aodh
# heat
enable_plugin heat https://git.openstack.org/openstack/heat
# vitrage
enable_plugin vitrage https://git.openstack.org/openstack/vitrage
enable_plugin vitrage-dashboard 
https://git.openstack.org/openstack/vitrage-dashboard
# masakari
enable_plugin masakari git://git.openstack.org/openstack/masakari


./stack.sh



__
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 exception when creating a network using Contrail R4.1 and OpenStack Ocata

[CARVER, PAUL]

Anda,

Will you be able to join the OpenContrail summit today? The Zoom link is below 
if you weren't able to make advance plans to join us in person in Austin. 
Hopefully the presentations will be helpful and there will be time for 
discussion directly related to this topic.

https://zoom.us/j/516126818
International numbers available: 
https://zoom.us/zoomconference?m=Ey5u5mAqUMK2XZED55tVEzbxDueqU9Wc

https://www.eventbrite.com/e/opencontrail-user-and-developer-group-kubecon-austin-2017-tickets-40200106601
http://www.opencontrail.org/event/opencontrail-kubecon-austin/


--
Paul Carver
VoIP: 732-545-7377
Cell: 908-803-1656
E: pcar...@att.com
Q Instant Message
It is difficult to make predictions. Especially about the future.


From: Anda Nicolae [mailto:anico...@lenovo.com]
Sent: Monday, December 04, 2017 12:08
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] Neutron exception when creating a network using 
Contrail R4.1 and OpenStack Ocata

Hi all,

I am struggling with Contrail R4.1 and OpenStack Ocata on Ubuntu 16.04.2.
I managed to install Contrail R4.1 on Ubuntu 16.04 using contrail-installer 
package and to successfully start all Contrail processes.
Then, I installed OpenStack Ocata using devstack. Unfortunately, I am facing 
some errors.

Worth mentioning that I have also installed only OpenStack Ocata without 
Contrail on Ubuntu 16.04 and it worked without any errors.

Some of the errors I have encountered with OpenStack Ocata and Contrail R4.1 
are:
If I issue: 'neutron net-list', works fine but 'neutron --debug net-create 
net1' returns:

DEBUG: keystoneauth.session GET call to None for http:// 
:5000/v2.0 used request id 
req-ee38087e-3167-4e2f-a3c7-05422984e40d
DEBUG: keystoneauth.identity.v2 Making authentication request to http:// 
/identity/v2.0/tokens
DEBUG: keystoneauth.session REQ: curl -g -i -X POST http:// 
:9696/v2.0/networks.json -H "User-Agent: 
python-neutronclient" -H "Content-Type: application/json" -H "Accept: 
application/json" -H "X-Auth-Token: 
{SHA1}07ab629ceba1f5e5eeb0533eccee9dad135910f9" -d '{"network": {"name": 
"net1", "admin_state_up": true}}'
DEBUG: keystoneauth.session RESP: [404] Content-Type: application/json 
Content-Length: 97 X-Openstack-Request-Id: 
req-ea656a0f-f621-43c7-af48-eaff7fd8d97a Date: Tue, 28 Nov 2017 00:52:14 GMT 
Connection: keep-alive
RESP BODY: {"NeutronError": {"message": "An unknown exception occurred.", 
"type": "NotFound", "detail": ""}}

DEBUG: keystoneauth.session POST call to network for 
http://:9696/v2.0/networks.json
 used request id req-ea656a0f-f621-43c7-af48-eaff7fd8d97a
DEBUG: neutronclient.v2_0.client Error message: {"NeutronError": {"message": 
"An unknown exception occurred.", "type": "NotFound", "detail": ""}}
DEBUG: neutronclient.v2_0.client POST call to neutron for http:// 
:9696/v2.0/networks.json used request id 
req-ea656a0f-f621-43c7-af48-eaff7fd8d97a
ERROR: neutronclient.shell An unknown exception occurred.
Neutron server returns request_ids: ['req-ea656a0f-f621-43c7-af48-eaff7fd8d97a']
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/neutronclient/shell.py", line 
877, in run_subcommand
return run_command(cmd, cmd_parser, sub_argv)
  File "/usr/local/lib/python2.7/dist-packages/neutronclient/shell.py", line 
114, in run_command
return cmd.run(known_args)
  File 
"/usr/local/lib/python2.7/dist-packages/neutronclient/neutron/v2_0/__init__.py",
 line 324, in run
return super(NeutronCommand, self).run(parsed_args)
  File "/usr/local/lib/python2.7/dist-packages/cliff/display.py", line 112, in 
run
column_names, data = self.take_action(parsed_args)
  File 
"/usr/local/lib/python2.7/dist-packages/neutronclient/neutron/v2_0/__init__.py",
 line 406, in take_action
data = obj_creator(body)
  File "/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", 
line 798, in create_network
return self.post(self.networks_path, body=body)
  File "/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", 
line 366, in post
headers=headers, params=params)
  File "/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", 
line 301, in do_request
self._handle_fault_response(status_code, replybody, resp)
 File "/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", 
line 276, in _handle_fault_response
exception_handler_v20(status_code, error_body)
  File "/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", 
line 92, in exception_handler_v20
request_ids=request_ids)
NotFound: An unknown exception occurred.

>From q-svc logs, I've found:
ERROR neutron_plugin_contrail.plugins.opencontrail.contrail_plugin_base 
[r

[openstack-dev] [etsinfv][neutron][gap-09]: No state for subnets

[Csatari, Gergely (Nokia - HU/Budapest)]

Hi,

During the discussions in NFV#20 about the subnet state we argeed, that we 
should remove the state from the specification of subnets in IFA005 and IFA006. 
This invalidates [GAP-09] in [1].

Br,
Gerg0

[1]: https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-explained
__
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] [etsinfv][gap-04][blazar]: Clarification on the scope of the capacity query

[Csatari, Gergely (Nokia - HU/Budapest)]

Hi,

During the Forum session about the ETSI NFV Gaps I received a request to 
clarify the scope of the capacity query mentioned in [GAP-04] with ETSI NFV.
The advice is that it should be possible to get the capacity of an OpenStack 
tenant, an user and a resource provider. This is because the NFVO might use 
different tenants and even different users to manage the resources in the 
OpenStack instances.

Any comments are welcome, also if you need more clarification on the gaps 
listed in [1] do not hesitate to contact me.

Br,
Gerg0

[1]: https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-explained

__
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] [publiccloud-wg] Reminder for todays meeting

[Tobias Rydberg]

Hi all,

Time again for a meeting for the Public Cloud WG - today at 1400 UTC in 
#openstack-meeting-3


Agenda and etherpad at: https://etherpad.openstack.org/p/publiccloud-wg

See you later!

Tobias Rydberg




smime.p7s
Description: S/MIME Cryptographic 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] [nova] [cinder] nova cannot create instance snapshot after ocata upgrade

[Gyorgy Szombathelyi]

Hi!

> how can i enable the service_token_roles?

Add the service role on the service project to the service users (nova, cinder, 
etc.).

> if i cset the service_token_role_required=true for nova, cinder, glance and
> neutron nova is unable to start instances.
> 
> i see the curl request form nova to cinder with an X-Service-Token but the
> result is always 401.
> 
> 
> Am Freitag, den 01.12.2017, 10:55 +0100 schrieb Kim-Norman Sahm:
> > after removing these options from the [keystone_authtoken] section in
> > cinder.conf snapshots are working:
> >
> > service_token_roles_required=True
> > service_token_roles=service
> >
> >
> >
> > Am Freitag, den 01.12.2017, 10:23 +0100 schrieb Kim-Norman Sahm:
> > >
> > > this is my cinder section of the nova.conf
> > >
> > > [cinder]
> > > os_region_name=myregion
> > > cross_az_attach=False
> > > catalog_info=volumev3:cinderv3:internalURL
> > >
> > >
> > > i don't find anything about cinder authentication in the nova config
> > > options. https://docs.openstack.org/ocata/config-reference/compute/
> > > co
> > > nf
> > > ig-options.html
> > >
> > >
> > >
> > > Am Donnerstag, den 30.11.2017, 11:30 -0600 schrieb Matt Riedemann:
> > > >
> > > >
> > > > On 11/30/2017 9:30 AM, Kim-Norman Sahm wrote:
> > > > >
> > > > >
> > > > >
> > > > > after upgrade openstack newton -> ocata i cannot create
> > > > > snapshots of my instances.
> > > > >
> > > > > if i try to create a snapshot of a instance horizon get this
> > > > > error:
> > > > > "Error: Unable to create snapshot."
> > > > > create a snapshot of a cinder volume  via openstackcli is
> > > > > working.
> > > > >
> > > > > nova.log
> > > > > 
> > > > > 2017-11-30 15:19:57.875 93 DEBUG cinderclient.v3.client [req-
> > > > > 5820c19b-
> > > > > fb11-43a2-8513-0782540b3d32 c756af2957c4447eafc4cef39cdb79e5
> > > > > 469dc3d300df4d41aaea00db572043ae - default default] REQ: curl -g
> > > > > -i -X GET
> > > > > https://cinder:8776/v3/469dc3d300df4d41aaea00db572043ae/vol
> > > > > um
> > > > > es
> > > > > /c67
> > > > > b5cf3-0beb-4efa-9177-d2b6498185fb -H "X-Service-Token:
> > > > > {SHA1}29a46cd87988e2bb905dbd3e796401aa23dff1a5" -H "User-
> Agent:
> > > > > python-
> > > > > cinderclient" -H "Accept: application/json" -H "X-Auth-Token:
> > > > > {SHA1}524061f0ab91e64ed6241e437792346f90df856e"
> > > > > _http_log_request
> > > > > /usr/lib/python2.7/dist-packages/keystoneauth1/session.py:347
> > > > > 2017-11-30 15:19:57.890 92 INFO nova.osapi_compute.wsgi.server
> > > > > [req-
> > > > > d83d5b73-fd24-406c-ad6b-feed6a40bfae
> > > > > c756af2957c4447eafc4cef39cdb79e5
> > > > > 469dc3d300df4d41aaea00db572043ae - default default] 10.78.21.2
> > > > > "GET /v2.1/flavors/203/os-extra_specs HTTP/1.1" status: 200 len:
> > > > > 448
> > > > > time:
> > > > > 0.0326798
> > > > > 2017-11-30 15:19:58.148 93 DEBUG cinderclient.v3.client [req-
> > > > > 5820c19b-
> > > > > fb11-43a2-8513-0782540b3d32 c756af2957c4447eafc4cef39cdb79e5
> > > > > 469dc3d300df4d41aaea00db572043ae - default default] RESP: [401]
> > > > > Date:
> > > > > Thu, 30 Nov 2017 15:19:57 GMT Server: Apache/2.4.18 (Ubuntu) x-
> > > > > openstack-request-id: req-22378faa-880b-4a80-a83e-41936741839e
> > > > > WWW-
> > > > > Authenticate: Keystone uri='https://keystone:5000/' Content-
> > > > > Length:
> > > > > 114
> > > > > Content-Type: application/json
> > > > > RESP BODY: {"error": {"message": "The request you have made
> > > > > requires authentication.", "code": 401, "title":
> > > > > "Unauthorized"}}
> > > > >   _http_log_response /usr/lib/python2.7/dist-
> > > > > packages/keystoneauth1/session.py:395
> > > > > 2017-11-30 15:19:58.149 93 DEBUG cinderclient.v3.client [req-
> > > > > 5820c19b-
> > > > > fb11-43a2-8513-0782540b3d32 c756af2957c4447eafc4cef39cdb79e5
> > > > > 469dc3d300df4d41aaea00db572043ae - default default] GET call to
> > > > > cinderv3 for https://cinder:8776/v3/469dc3d300df4d41aaea00db572
> > > > > 04
> > > > > 3a
> > > > > e/vo
> > > > > lumes/c67b5cf3-0beb-4efa-9177-d2b6498185fb used request id req-
> > > > > 22378faa-880b-4a80-a83e-41936741839e request
> > > > > /usr/lib/python2.7/dist-
> > > > > packages/keystoneauth1/session.py:640
> > > > > 2017-11-30 15:19:58.157 93 DEBUG cinderclient.v3.client [req-
> > > > > 5820c19b-
> > > > > fb11-43a2-8513-0782540b3d32 c756af2957c4447eafc4cef39cdb79e5
> > > > > 469dc3d300df4d41aaea00db572043ae - default default] RESP: [401]
> > > > > Date:
> > > > > Thu, 30 Nov 2017 15:19:58 GMT Server: Apache/2.4.18 (Ubuntu) x-
> > > > > openstack-request-id: req-02ebac9f-794a-46f4-85b2-0e429a1785cf
> > > > > WWW-
> > > > > Authenticate: Keystone uri='https://keystone:5000/' Content-
> > > > > Length:
> > > > > 114
> > > > > Content-Type: application/json
> > > > > RESP BODY: {"error": {"message": "The request you have made
> > > > > requires authentication.", "code": 401, "title":
> > > > > "Unauthorized"}}
> > > > >   _http_log_response /usr/lib/python2.7/dist-
> > > > > packages/keysto

Re: [openstack-dev] [horizon] Fetch resources in parallel

[Ivan Kolodyazhny]

Hi Team,

Last week we had a hot discussion about this topic at the meeting [6]. We
still don't have an agreement how to go forward with it. As was requested,
I did some perf testing with a current approach [3]. TBH, these tests
results don't show real data but look realistic. I used the same VM with
the same code (just checked out to the previous commit of horizon). To
get better results, we need to re-test all but I don't have enough time
now:(. I hope, these results are good enoudh and we can make our final
decision on this topic.

[3]
https://docs.google.com/spreadsheets/d/14zDpdkPUfGDR_ZycaGUoT64kHsGi1gL9JOha8n5PVeg/edit#gid=0
[6]
http://eavesdrop.openstack.org/meetings/horizon/2017/horizon.2017-11-29-20.00.log.html#l-12


Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Tue, Oct 31, 2017 at 11:06 PM, Ivan Kolodyazhny  wrote:

> Just forgot to mention one other option: we can use celery [6] too but I
> didn't do any performance testing with it. This solution will be more
> complex.
>
> [6] http://www.celeryproject.org/
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
> On Tue, Oct 31, 2017 at 7:15 PM, Ivan Kolodyazhny  wrote:
>
>> Hi team,
>>
>> We all know that unfortunately Horizon's performance not good enough in
>> some cases. That's why we try to fix it on both sides: client-side and
>> server-side.
>>
>> I would like to talk mostly about server-side now. On some views, we use
>> 'futurist' library [1] to fetch resources from API's in parallel. I've
>> filed a blueprint for this effort [2]. You can find some work in progress
>> patches in the Gerrit.
>>
>> For now, we use futurist.ThreadPoolExecutor in Horizon to fetch resources
>> from APIs. It requires some specific Apache configuration changes to allow
>> WSGI app to create threads. It means, our code execution depends on Apache
>> mod_wsgi configuration.
>>
>> To avoid this, we can use futurist.GreenThreadPoolExecutor. It
>> uses eventlet green threads which can be used to speed-up I/O operations
>> like 'call external API'.
>>
>> I did very simple performance testing [3] with proposed patch [4] for
>> volumes views. My tests are not ideal but you can see how it's going with
>> green thread. I propose to switch to the futurist.GreenThreadPoolExecutor
>> and add 'eventlet.monkey_patch()' call to the wsgi app for Horizon. It will
>> speed up parallel API calls and make Horizon independent on Apache or other
>> web server configuration.
>>
>> I added this topic to the next weekly meeting agenda [5] so we can
>> discuss it there too.
>>
>>
>> [1] https://github.com/openstack/futurist/
>> [2] https://blueprints.launchpad.net/horizon/+spec/fetch-
>> resources-in-parallel
>> [3] https://docs.google.com/spreadsheets/d/14zDpdkPUfGDR_ZycaGUo
>> T64kHsGi1gL9JOha8n5PVeg/edit?usp=sharing
>> [4] https://review.openstack.org/#/c/426493/
>> [5] https://wiki.openstack.org/wiki/Meetings/Horizon#Agenda_
>> for_Next_Meeting
>>
>> Regards,
>> Ivan Kolodyazhny,
>> http://blog.e0ne.info/
>>
>
>
__
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] overcloud keystone error "Could not determine a suitable URL for the plugin"

[Juan Antonio Osorio]

>From the node you're running the nova command, do you have access to the
10.0.0.0 network (external)?

In virtual environments, quickstart will leave an overcloud-prep-network.sh
script that will create a vlan interface that gives the undercloud access
to that network. So, if it's a virtual environment and you're running that
command from the undercloud (which from the log you sent it seems that's
the case) you need to run that. Note that you need to run that every time
you update your undercloud.

BR


On 6 Dec 2017 09:06, "Moshe Levi"  wrote:

Hi all,



We deploy tripleo master using quickstart.

We this delorean repo:

name=delorean

baseurl=https://trunk.rdoproject.org/centos7-master/ac/82/ac
82ea9271a4ae3860528eaf8a813da7209e62a6_28eeb6c7/



The undercloud and overcloud deployment were successfully, but we I try to
run command on the overcloud

I am getting the  keystone error "Could not determine a suitable URL for
the plugin"

See nova-list with debug info [1]

Do you know how to resolve this? Help in troubleshooting this issue will be
appreciated.





[1]  http://paste.openstack.org/show/628240/









__
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][l2gw] Preventing DB out-of-sync

[Peng Liu]

Hi,

During working on this patch[0], I encounter some DB out-of-sync problem. I
think maybe the design can be improved. Here is my thought, all comments
are welcome.

In plugin code, I found all the resource operations follow the pattern in
[1]. It is a very misleading design compare to [2].

"For every action that can be taken on a resource, the mechanism driver
exposes two methods - ACTION_RESOURCE_precommit, which is called within the
database transaction context, and ACTION_RESOURCE_postcommit, called after
the database transaction is complete."

In result, if we focus on the out-of-sync between plugin DB and
driver/backend DB:

1) In RPC driver, only methods Action_Resource and are implemented. Which
means the action is token before it was written in plugin DB. In case of
action partial succeed (especially for update case) or plugin DB operation
failure, it will cause DB out-of-sync.
2) In ODL driver, only methods Action_Resource_postcommit are implemented,
which means there is no validation in ODL level before the record is
written in the plugin DB. In case of, ODL side failure, there is no
rollback for plugin DB.

So, to fix this issue is costly. Both plugin and driver sides need to be
altered.

The other side of this issue is a period db monitor mechanism between
plugin and drivers, and it is another story.


[0] https://review.openstack.org/#/c/516256
[1]
...
def Action_Resource
self.validate_Resource_for_Action
self.driver.Action_Resource
with context.session.begin(subtransactions=True):
super.Action_Resource
self.driver.Action_Resource_precommit
try:
self.driver.Action_Resource_postcommit
...
[2] https://wiki.openstack.org/wiki/Neutron/ML2

-- 
Peng Liu
__
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] [nova] Boot from volume 's instance of rebuild operation

[李杰]

Hi,all


   Now the boot from volume 's instance of rebuild operation has a 
problem.For example,after the rebuild operation,the instance 's root disk is 
not replace.
I found the reason is that when we use the "_build_resources" function to 
prepare source,it obtains the block devices according to the previous instance 
's uuid and attaches them to instance.So boot from volume 's instance of 
rebuild operation doesn't update data.
   To solve it,I plan to use CLI 's "metadata" option,to increase a key 
name "source_type".The "source_type" includes "snapshot" and "image".We can 
judge from "source_type".If the "source_type" is "snapshot",we can transform 
the given snapshot to a volume and attach this volume to instance.If the 
"source_type" is "image",we don't handle it.
   Can you give me some advice?Help in troubleshooting this issue will be 
appreciated.












Best Regards
Lijie__
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