Re: [openstack-dev] [puppet][qa][ubuntu][neutron] Xenial Neutron Timeouts

[Tobias Urdin]

Hello,

Same here, I will continue looking at this aswell.

Would be great if we could get some input from a neutron dev with good insight 
into the project.


Can we backtrace the timed out message from where it's thrown/returned.

Error: Request to 
https://127.0.0.1:9696/v2.0/floatingips/2e3fa334-d6ac-443c-b5ba-eeb521d6324c 
timed out', u'code': 400}

I'm interested why we would get 400 code back, the floating ip operations 
should be async right so this would be the response from the API layer with 
information from the database that should

return more information.


Best regards

On 11/14/2017 07:41 AM, Arnaud MORIN wrote:
Hey,
Do you know if the bug appears on a specific Ubuntu / openstack version?
As far as I remember it was not related to the puppet branch?  I mean the bug 
is existing on master but also on newton puppet branches, right?

We are using Ubuntu in my company so we would love to see that continue ;)
I'll try to take a look again.

Cheers.

Le 14 nov. 2017 00:00, "Mohammed Naser" 
> a écrit :
Hi,

Hope that everyone had safe travels and enjoyed their time at Sydney
(and those who weren't there enjoyed a bit of quiet time!).  I'm just
sending this email if anyone had a chance to look more into this (or
perhaps we can get some help if there are any Canonical folks on the
list?)

I would be really sad if we had to drop Ubuntu/Debian support because
we cannot test it.  I think there are a lot of users out there using
it!  I'd be more than happy to provide any assistance/information in
troubleshooting this.

Thank you,
Mohammed

On Thu, Nov 2, 2017 at 1:10 PM, Mohammed Naser 
> wrote:
> On Thu, Nov 2, 2017 at 1:02 PM, Tobias Urdin 
> > wrote:
>> I've been staring at this for almost an hour now going through all the logs
>> and I can't really pin a point from
>>
>> where that error message is generated. Cannot find any references for the
>> timed out message that the API returns or the unable to associate part.
>>
>>
>> What I'm currently staring at is why would the instance fixed ip 172.24.5.17
>> be references as a network:router_gateway port in the OVS agent logs.
>>
>> 2017-10-29 23:19:27.591 11856 INFO
>> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
>> [req-7274c6f7-18ef-420d-ad5a-9d0fe4eb35c6 - - - - -] Port
>> 053a625c-4227-41fb-9a26-45eda7bd2055 updated. Details: {'profile': {},
>> 'network_qos_policy_id': None, 'qos_policy_id': None,
>> 'allowed_address_pairs': [], 'admin_state_up': True, 'network_id':
>> 'f9647756-41ad-4ec5-af49-daefe410815e', 'segmentation_id': None,
>> 'fixed_ips': [{'subnet_id': 'a31c7115-1f3e-4220-8bdb-981b6df2e18c',
>> 'ip_address': '172.24.5.17'}], 'device_owner': u'network:router_gateway',
>> 'physical_network': u'external', 'mac_address': 'fa:16:3e:3b:ec:c3',
>> 'device': u'053a625c-4227-41fb-9a26-45eda7bd2055', 'port_security_enabled':
>> False, 'port_id': '053a625c-4227-41fb-9a26-45eda7bd2055', 'network_type':
>> u'flat', 'security_groups': []}
>>
>>
>> Anybody else seen anything interesting?
>
> Hi Tobias,
>
> Thanks for looking out.  I've spent a lot of time and I haven't
> successfully identified much, I can add the following
>
> - This issue is intermittent in CI
> - It does *not* happen on any specific providers, I've seen it fail on
> both OVH and Rackspace.
> - Not *all* floating iP assignments fail, if you look at the logs, you
> can see it attach a few successfully before failing
>
> But yeah, I'm still quite at a loss and not having this coverage isn't fun.
>
>>
>>
>> On 10/30/2017 11:08 PM, Brian Haley wrote:
>>
>> On 10/30/2017 05:46 PM, Matthew Treinish wrote:
>>
>>  From a quick glance at the logs my guess is that the issue is related
>> to this stack trace in the l3 agent logs:
>>
>> http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/logs/neutron/neutron-l3-agent.txt.gz?level=TRACE#_2017-10-29_23_11_15_146
>>
>> I'm not sure what's causing it to complain there. But, I'm on a plane
>> right now (which is why this is a top post, sorry) so I can't really dig
>> much more than that. I'll try to take a deeper look at things later when
>> I'm on solid ground. (hopefully someone will beat me to it by then though)
>>
>> I don't think that l3-agent trace is it, as the failure is coming from
>> the API.  It's actually a trace that's happening due to the async nature
>> of how the agent runs arping, fix is
>> https://review.openstack.org/#/c/507914/ but it only removes the log noise.
>>
>> http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/logs/neutron/neutron-server.txt.gz
>> has some tracebacks that look config related, possible missing DB table?
>>   But I haven't looked very closely.
>>
>> -Brian
>>
>>
>> On October 31, 2017 1:25:55 AM 

Re: [openstack-dev] [puppet][qa][ubuntu][neutron] Xenial Neutron Timeouts

[Arnaud MORIN]

Hey,
Do you know if the bug appears on a specific Ubuntu / openstack version?
As far as I remember it was not related to the puppet branch?  I mean the
bug is existing on master but also on newton puppet branches, right?

We are using Ubuntu in my company so we would love to see that continue ;)
I'll try to take a look again.

Cheers.

Le 14 nov. 2017 00:00, "Mohammed Naser"  a écrit :

> Hi,
>
> Hope that everyone had safe travels and enjoyed their time at Sydney
> (and those who weren't there enjoyed a bit of quiet time!).  I'm just
> sending this email if anyone had a chance to look more into this (or
> perhaps we can get some help if there are any Canonical folks on the
> list?)
>
> I would be really sad if we had to drop Ubuntu/Debian support because
> we cannot test it.  I think there are a lot of users out there using
> it!  I'd be more than happy to provide any assistance/information in
> troubleshooting this.
>
> Thank you,
> Mohammed
>
> On Thu, Nov 2, 2017 at 1:10 PM, Mohammed Naser 
> wrote:
> > On Thu, Nov 2, 2017 at 1:02 PM, Tobias Urdin 
> wrote:
> >> I've been staring at this for almost an hour now going through all the
> logs
> >> and I can't really pin a point from
> >>
> >> where that error message is generated. Cannot find any references for
> the
> >> timed out message that the API returns or the unable to associate part.
> >>
> >>
> >> What I'm currently staring at is why would the instance fixed ip
> 172.24.5.17
> >> be references as a network:router_gateway port in the OVS agent logs.
> >>
> >> 2017-10-29 23:19:27.591 11856 INFO
> >> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> >> [req-7274c6f7-18ef-420d-ad5a-9d0fe4eb35c6 - - - - -] Port
> >> 053a625c-4227-41fb-9a26-45eda7bd2055 updated. Details: {'profile': {},
> >> 'network_qos_policy_id': None, 'qos_policy_id': None,
> >> 'allowed_address_pairs': [], 'admin_state_up': True, 'network_id':
> >> 'f9647756-41ad-4ec5-af49-daefe410815e', 'segmentation_id': None,
> >> 'fixed_ips': [{'subnet_id': 'a31c7115-1f3e-4220-8bdb-981b6df2e18c',
> >> 'ip_address': '172.24.5.17'}], 'device_owner':
> u'network:router_gateway',
> >> 'physical_network': u'external', 'mac_address': 'fa:16:3e:3b:ec:c3',
> >> 'device': u'053a625c-4227-41fb-9a26-45eda7bd2055',
> 'port_security_enabled':
> >> False, 'port_id': '053a625c-4227-41fb-9a26-45eda7bd2055',
> 'network_type':
> >> u'flat', 'security_groups': []}
> >>
> >>
> >> Anybody else seen anything interesting?
> >
> > Hi Tobias,
> >
> > Thanks for looking out.  I've spent a lot of time and I haven't
> > successfully identified much, I can add the following
> >
> > - This issue is intermittent in CI
> > - It does *not* happen on any specific providers, I've seen it fail on
> > both OVH and Rackspace.
> > - Not *all* floating iP assignments fail, if you look at the logs, you
> > can see it attach a few successfully before failing
> >
> > But yeah, I'm still quite at a loss and not having this coverage isn't
> fun.
> >
> >>
> >>
> >> On 10/30/2017 11:08 PM, Brian Haley wrote:
> >>
> >> On 10/30/2017 05:46 PM, Matthew Treinish wrote:
> >>
> >>  From a quick glance at the logs my guess is that the issue is related
> >> to this stack trace in the l3 agent logs:
> >>
> >> http://logs.openstack.org/47/514347/1/check/puppet-
> openstack-integration-4-scenario001-tempest-ubuntu-
> xenial/ed5a657/logs/neutron/neutron-l3-agent.txt.gz?level=
> TRACE#_2017-10-29_23_11_15_146
> >>
> >> I'm not sure what's causing it to complain there. But, I'm on a plane
> >> right now (which is why this is a top post, sorry) so I can't really dig
> >> much more than that. I'll try to take a deeper look at things later when
> >> I'm on solid ground. (hopefully someone will beat me to it by then
> though)
> >>
> >> I don't think that l3-agent trace is it, as the failure is coming from
> >> the API.  It's actually a trace that's happening due to the async nature
> >> of how the agent runs arping, fix is
> >> https://review.openstack.org/#/c/507914/ but it only removes the log
> noise.
> >>
> >> http://logs.openstack.org/47/514347/1/check/puppet-
> openstack-integration-4-scenario001-tempest-ubuntu-
> xenial/ed5a657/logs/neutron/neutron-server.txt.gz
> >> has some tracebacks that look config related, possible missing DB table?
> >>   But I haven't looked very closely.
> >>
> >> -Brian
> >>
> >>
> >> On October 31, 2017 1:25:55 AM GMT+04:00, Mohammed Naser
> >>  wrote:
> >>
> >> Hi everyone,
> >>
> >> I'm looking for some help regarding an issue that we're having with
> >> the Puppet OpenStack modules, we've had very inconsistent failures
> in
> >> the Xenial with the following error:
> >>
> >>
> >> http://logs.openstack.org/47/514347/1/check/puppet-
> openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/
> >>
> >> http://logs.openstack.org/47/514347/1/check/puppet-
> 

Re: [openstack-dev] [octavia] amphora fails to send request to members

[Yipei Niu]

Hi, Michael,

Sorry about the typo in the last mail. Please just ignore the last mail.

In the environment where octavia and tricircle are installed together, I
created a router and attached subnet1 to it. Then I bind the mac address of
10.0.1.10 (real gateway) to ip of 10.0.1.1 in the amphora arp cache,
manually making amphora knows the mac address of 10.0.1.1 (actually it is
the mac of 10.0.1.10, since 10.0.1.1 does not exist), it works.

I also run the commands in this environment.

ubuntu@amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f:~$ sudo ip netns exec
amphora-haproxy ip route show table all
sudo: unable to resolve host amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f
default via 10.0.1.1 dev eth1  table 1 onlink
default via 10.0.1.10 dev eth1
10.0.1.0/24 dev eth1  proto kernel  scope link  src 10.0.1.8
broadcast 10.0.1.0 dev eth1  table local  proto kernel  scope link  src
10.0.1.8
local 10.0.1.4 dev eth1  table local  proto kernel  scope host  src
10.0.1.8
local 10.0.1.8 dev eth1  table local  proto kernel  scope host  src
10.0.1.8
broadcast 10.0.1.255 dev eth1  table local  proto kernel  scope link  src
10.0.1.8
fe80::/64 dev eth1  proto kernel  metric 256  pref medium
unreachable default dev lo  table unspec  proto kernel  metric 4294967295
error -101 pref medium
local fe80::f816:3eff:febe:5ad5 dev lo  table local  proto none  metric 0
pref medium
ff00::/8 dev eth1  table local  metric 256  pref medium
unreachable default dev lo  table unspec  proto kernel  metric 4294967295
error -101 pref medium
ubuntu@amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f:~$ sudo ip netns exec
amphora-haproxy ip rule show
sudo: unable to resolve host amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f
0: from all lookup local
100: from 10.0.1.4 lookup 1
32766: from all lookup main
32767: from all lookup default


To make the situation clear, I run the commands in the environment
installed octavia alone. Please note that in this environment, there is no
router. The results are as follows.

stack@stack-VirtualBox:~$ neutron lbaas-loadbalancer-list
neutron CLI is deprecated and will be removed in the future. Use openstack
CLI instead.
+--+--+-
-+-+-+--+
| id   | name | tenant_id
  | vip_address | provisioning_status | provider |
+--+--+-
-+-+-+--+
| d087d3b4-afbe-4af6-8b31-5e86fc97da1b | lb1  |
e59bb8f3bf9342aba02f9ba5804ed2fb | 10.0.1.9| ACTIVE  |
octavia  |
+--+--+-
-+-+-+--+

ubuntu@amphora-dcbff58a-d418-4271-9374-9de2fd063ce9:~$ sudo ip netns exec
amphora-haproxy ip addr
sudo: unable to resolve host amphora-dcbff58a-d418-4271-9374-9de2fd063ce9
1: lo:  mtu 65536 qdisc noop state DOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: eth1:  mtu 1450 qdisc pfifo_fast state
UP group default qlen 1000
link/ether fa:16:3e:dc:9e:61 brd ff:ff:ff:ff:ff:ff
inet 10.0.1.11/24 brd 10.0.1.255 scope global eth1
   valid_lft forever preferred_lft forever
inet 10.0.1.9/24 brd 10.0.1.255 scope global secondary eth1:0
   valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fedc:9e61/64 scope link
   valid_lft forever preferred_lft forever

ubuntu@amphora-dcbff58a-d418-4271-9374-9de2fd063ce9:~$ sudo ip netns exec
amphora-haproxy ip route show table all
sudo: unable to resolve host amphora-dcbff58a-d418-4271-9374-9de2fd063ce9
default via 10.0.1.1 dev eth1  table 1 onlink
default via 10.0.1.1 dev eth1 onlink
10.0.1.0/24 dev eth1  proto kernel  scope link  src 10.0.1.11
broadcast 10.0.1.0 dev eth1  table local  proto kernel  scope link  src
10.0.1.11
local 10.0.1.9 dev eth1  table local  proto kernel  scope host  src
10.0.1.11
local 10.0.1.11 dev eth1  table local  proto kernel  scope host  src
10.0.1.11
broadcast 10.0.1.255 dev eth1  table local  proto kernel  scope link  src
10.0.1.11
fe80::/64 dev eth1  proto kernel  metric 256  pref medium
unreachable default dev lo  table unspec  proto kernel  metric 4294967295
<0429%20496%207295>  error -101 pref medium
local fe80::f816:3eff:fedc:9e61 dev lo  table local  proto none  metric 0
pref medium
ff00::/8 dev eth1  table local  metric 256  pref medium
unreachable default dev lo  table unspec  proto kernel  metric 4294967295
<0429%20496%207295>  error -101 pref medium

ubuntu@amphora-dcbff58a-d418-4271-9374-9de2fd063ce9:~$ sudo ip netns exec
amphora-haproxy ip rule show
sudo: unable to resolve host amphora-dcbff58a-d418-4271-9374-9de2fd063ce9
0: from all lookup local
100: from 10.0.1.9 lookup 1
32766: from all lookup main
32767: from all lookup default

If there is no router, the packets are supposed to forwarded in layer 2, 

Re: [openstack-dev] [octavia] amphora fails to send request to members

[Yipei Niu]

Hi, Michael,

Thanks a lot for your comments.

In the environment where octavia and tricircle are installed together, I
created a router and attached subnet1 to it. Then I bind the mac address of
10.0.1.9 (real gateway) to ip of 10.0.1.1 in the amphora arp cache,
manually making amphora knows the mac address of 10.0.1.1 (actually it is
the mac of 10.0.1.9, since 10.0.1.1 does not exist), it works.

To make the situation clear, I run the commands in the environment
installed octavia alone. Please note that in this environment, there is no
router. The results are as follows.

stack@stack-VirtualBox:~$ neutron lbaas-loadbalancer-list
neutron CLI is deprecated and will be removed in the future. Use openstack
CLI instead.
+--+--+--+-+-+--+
| id   | name | tenant_id
  | vip_address | provisioning_status | provider |
+--+--+--+-+-+--+
| d087d3b4-afbe-4af6-8b31-5e86fc97da1b | lb1  |
e59bb8f3bf9342aba02f9ba5804ed2fb | 10.0.1.9| ACTIVE  |
octavia  |
+--+--+--+-+-+--+

ubuntu@amphora-dcbff58a-d418-4271-9374-9de2fd063ce9:~$ sudo ip netns exec
amphora-haproxy ip addr
sudo: unable to resolve host amphora-dcbff58a-d418-4271-9374-9de2fd063ce9
1: lo:  mtu 65536 qdisc noop state DOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: eth1:  mtu 1450 qdisc pfifo_fast state
UP group default qlen 1000
link/ether fa:16:3e:dc:9e:61 brd ff:ff:ff:ff:ff:ff
inet 10.0.1.11/24 brd 10.0.1.255 scope global eth1
   valid_lft forever preferred_lft forever
inet 10.0.1.9/24 brd 10.0.1.255 scope global secondary eth1:0
   valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fedc:9e61/64 scope link
   valid_lft forever preferred_lft forever

ubuntu@amphora-dcbff58a-d418-4271-9374-9de2fd063ce9:~$ sudo ip netns exec
amphora-haproxy ip route show table all
sudo: unable to resolve host amphora-dcbff58a-d418-4271-9374-9de2fd063ce9
default via 10.0.1.1 dev eth1  table 1 onlink
default via 10.0.1.1 dev eth1 onlink
10.0.1.0/24 dev eth1  proto kernel  scope link  src 10.0.1.11
broadcast 10.0.1.0 dev eth1  table local  proto kernel  scope link  src
10.0.1.11
local 10.0.1.9 dev eth1  table local  proto kernel  scope host  src
10.0.1.11
local 10.0.1.11 dev eth1  table local  proto kernel  scope host  src
10.0.1.11
broadcast 10.0.1.255 dev eth1  table local  proto kernel  scope link  src
10.0.1.11
fe80::/64 dev eth1  proto kernel  metric 256  pref medium
unreachable default dev lo  table unspec  proto kernel  metric 4294967295
error -101 pref medium
local fe80::f816:3eff:fedc:9e61 dev lo  table local  proto none  metric 0
pref medium
ff00::/8 dev eth1  table local  metric 256  pref medium
unreachable default dev lo  table unspec  proto kernel  metric 4294967295
error -101 pref medium

ubuntu@amphora-dcbff58a-d418-4271-9374-9de2fd063ce9:~$ sudo ip netns exec
amphora-haproxy ip rule show
sudo: unable to resolve host amphora-dcbff58a-d418-4271-9374-9de2fd063ce9
0: from all lookup local
100: from 10.0.1.9 lookup 1
32766: from all lookup main
32767: from all lookup default

If there is no router, the packets are supposed to forwarded in layer 2, as
amphora is plugged with ports of every member's subnet. The priority of
“from 10.0.1.9 lookup 1” is higher than that of "from all lookup local".
Maybe this patch (https://review.openstack.org/#/c/501915/) affects the l2
traffic.

Best regards,
Yipei

On Sat, Nov 11, 2017 at 11:24 AM, Yipei Niu  wrote:

> Hi, Michael,
>
> I tried to run to command, and I think the amphora can connect to the
> member (10.0.1.3). The results are as follows.
>
> ubuntu@amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f:~$ sudo ip netns exec
> amphora-haproxy ping 10.0.1.3
> sudo: unable to resolve host amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f
> PING 10.0.1.3 (10.0.1.3) 56(84) bytes of data.
> 64 bytes from 10.0.1.3: icmp_seq=1 ttl=64 time=189 ms
> 64 bytes from 10.0.1.3: icmp_seq=2 ttl=64 time=1.72 ms
> ^C
> --- 10.0.1.3 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1006ms
> rtt min/avg/max/mdev = 1.722/95.855/189.989/94.134 ms
>
> ubuntu@amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f:~$ sudo ip netns exec
> amphora-haproxy curl 10.0.1.3
> sudo: unable to resolve host amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f
> Welcome to 10.0.1.3
>
> stack@devstack-1:~$ sudo ip netns exec 
> qdhcp-310fea4b-36ae-4617-b499-5936e8eda842
> curl 10.0.1.3
> Welcome to 10.0.1.3
>
> As mentioned in my previous mail, I also have an environment installed
> with octavia alone, where the error reproduces. In that environment, I also
> 

[openstack-dev] [docs] Next documentation meeting

[Petr Kovar]

Hi docs people,

Our next documentation meeting is scheduled for Wednesday, 15th November.
As I'm traveling this week, I'll be unable to host the meeting. Is
anybody available to run the meeting in my stead? 

If not, let's cancel it and meet in two weeks.

Thank you,
pk

__
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] [api] APIs schema consumption discussion

[Gilles Dubreuil]

Hi,

Follow-up conversation from our last "API SIG feedback and discussion 
session" at Sydney Summit [1], about APIs schema consumption.


Let's summarize the current situation.

Each OpenStack project has an "API-source" folder containing RST files 
describing its API structure ([2] for example). Those files are in turn 
consumed by the Sphinx library to generate each project's API reference 
manual which are then available in the API guide documentation [3]. Such 
effort has made the APIs harmoniously consistent across all OpenStack 
projects and has also created a "de-facto" API schema.


While the RST files are used by the documentation, they are not readily 
consumable by SDKs. Of course the APIs schema can be extracted by web 
crawling the Reference guides, which in turn can be used by any 
language. Such approach works [4] and help the Misty project [5] (Ruby 
SDK) started with more languages to exploit the same approach.


Therefore to allow better automation, the next step would be to have the 
APIs schema stored directly into each project's repo so the SDKs could 
consume them straight from the source. This is why we've started 
discussing how to have the schema either extracted from the RST files or 
alternatively having the API described directly into its own file. The 
latter would provide a different work flow: "Yaml -> RST -> Reference 
doco" instead of "RST -> Reference doco -> Yaml".


So the question at this stage is: "Which of the work flow to choose from?".

To clarify the needs, it's important to note that we found out that none 
of the SDKs project, besides OSC (OpenStack Client, thanks to Dean), 
have full time working teams to maintain each SDK, which besides the 
natural structural complexity inherent to the cloud context, makes the 
task of keeping a SDK up to date very difficult. Especially as projects 
moves forward. Automatically managing Openstack APIs is inevitable for 
consumers. Another example/feedback was provided by the presenters of 
"AT’s Strategy for Implementing a Next Generation OpenStack Cloud" 
session during Sydney Keynotes, as they don't handle the Openstack API 
manually!


APIs consumers and providers, any thoughts?

[1] 
https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20442/api-sig-feedback-and-discussion-session

[2] https://github.com/openstack/nova/tree/master/api-guide/source
[3] https://developer.openstack.org/api-guide/quick-start/index.html
[4] https://github.com/flystack/openstack-APIs
[5] https://github.com/flystack/misty

Regards,
Gilles

__
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] [puppet][qa][ubuntu][neutron] Xenial Neutron Timeouts

[Mohammed Naser]

Hi,

Hope that everyone had safe travels and enjoyed their time at Sydney
(and those who weren't there enjoyed a bit of quiet time!).  I'm just
sending this email if anyone had a chance to look more into this (or
perhaps we can get some help if there are any Canonical folks on the
list?)

I would be really sad if we had to drop Ubuntu/Debian support because
we cannot test it.  I think there are a lot of users out there using
it!  I'd be more than happy to provide any assistance/information in
troubleshooting this.

Thank you,
Mohammed

On Thu, Nov 2, 2017 at 1:10 PM, Mohammed Naser  wrote:
> On Thu, Nov 2, 2017 at 1:02 PM, Tobias Urdin  
> wrote:
>> I've been staring at this for almost an hour now going through all the logs
>> and I can't really pin a point from
>>
>> where that error message is generated. Cannot find any references for the
>> timed out message that the API returns or the unable to associate part.
>>
>>
>> What I'm currently staring at is why would the instance fixed ip 172.24.5.17
>> be references as a network:router_gateway port in the OVS agent logs.
>>
>> 2017-10-29 23:19:27.591 11856 INFO
>> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
>> [req-7274c6f7-18ef-420d-ad5a-9d0fe4eb35c6 - - - - -] Port
>> 053a625c-4227-41fb-9a26-45eda7bd2055 updated. Details: {'profile': {},
>> 'network_qos_policy_id': None, 'qos_policy_id': None,
>> 'allowed_address_pairs': [], 'admin_state_up': True, 'network_id':
>> 'f9647756-41ad-4ec5-af49-daefe410815e', 'segmentation_id': None,
>> 'fixed_ips': [{'subnet_id': 'a31c7115-1f3e-4220-8bdb-981b6df2e18c',
>> 'ip_address': '172.24.5.17'}], 'device_owner': u'network:router_gateway',
>> 'physical_network': u'external', 'mac_address': 'fa:16:3e:3b:ec:c3',
>> 'device': u'053a625c-4227-41fb-9a26-45eda7bd2055', 'port_security_enabled':
>> False, 'port_id': '053a625c-4227-41fb-9a26-45eda7bd2055', 'network_type':
>> u'flat', 'security_groups': []}
>>
>>
>> Anybody else seen anything interesting?
>
> Hi Tobias,
>
> Thanks for looking out.  I've spent a lot of time and I haven't
> successfully identified much, I can add the following
>
> - This issue is intermittent in CI
> - It does *not* happen on any specific providers, I've seen it fail on
> both OVH and Rackspace.
> - Not *all* floating iP assignments fail, if you look at the logs, you
> can see it attach a few successfully before failing
>
> But yeah, I'm still quite at a loss and not having this coverage isn't fun.
>
>>
>>
>> On 10/30/2017 11:08 PM, Brian Haley wrote:
>>
>> On 10/30/2017 05:46 PM, Matthew Treinish wrote:
>>
>>  From a quick glance at the logs my guess is that the issue is related
>> to this stack trace in the l3 agent logs:
>>
>> http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/logs/neutron/neutron-l3-agent.txt.gz?level=TRACE#_2017-10-29_23_11_15_146
>>
>> I'm not sure what's causing it to complain there. But, I'm on a plane
>> right now (which is why this is a top post, sorry) so I can't really dig
>> much more than that. I'll try to take a deeper look at things later when
>> I'm on solid ground. (hopefully someone will beat me to it by then though)
>>
>> I don't think that l3-agent trace is it, as the failure is coming from
>> the API.  It's actually a trace that's happening due to the async nature
>> of how the agent runs arping, fix is
>> https://review.openstack.org/#/c/507914/ but it only removes the log noise.
>>
>> http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/logs/neutron/neutron-server.txt.gz
>> has some tracebacks that look config related, possible missing DB table?
>>   But I haven't looked very closely.
>>
>> -Brian
>>
>>
>> On October 31, 2017 1:25:55 AM GMT+04:00, Mohammed Naser
>>  wrote:
>>
>> Hi everyone,
>>
>> I'm looking for some help regarding an issue that we're having with
>> the Puppet OpenStack modules, we've had very inconsistent failures in
>> the Xenial with the following error:
>>
>>
>> http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/
>>
>> http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/logs/testr_results.html.gz
>>  Details: {u'message': u'Unable to associate floating IP
>> 172.24.5.17   to fixed IP10.100.0.8
>>   for instance
>> d265626a-77c1-4d2f-8260-46abe548293e. Error: Request to
>>
>> https://127.0.0.1:9696/v2.0/floatingips/2e3fa334-d6ac-443c-b5ba-eeb521d6324c
>> timed out', u'code': 400}
>>
>> At this point, we're at a bit of a loss.  I've tried my best in order
>> to find the root cause however we have not been able to do this.  It
>> was persistent enough that we elected to go non-voting for our Xenial
>> 

Re: [openstack-dev] [glance] Does glance_store swift driver support range requests ?

[Nikhil Komawar]

I think it will a rather hard problem to solve. As swift store can be
configured to store objects in different configurations. I guess the next
question would be, what is your underlying problem -- multiple build
requests or is this for retry for a single download?

If the image is in image cache and you are hitting the glance node with
cached image (which is quite possible for tiny deployments), this feature
will be relatively easier.

On Mon, Nov 13, 2017 at 6:47 AM, Matt Keenan  wrote:

> Hi,
>
>  Just configured devstack on Fedora 26, and by default glance_store uses
> swift for image storage. When attempting to get a specific range from a
> glance stored image, it's reporting range requests are not supported e.g.:
>
> $ curl -i -X GET -r 0-32 -H "X-Auth-Token: $auth_token"
> http://10.169.104.255/image/v2/images/29b7aa
> 5e-3ec2-49b5-ab6b-d6cc5099f46c/file
> HTTP/1.1 400 Bad Request
> Date: Mon, 13 Nov 2017 10:43:23 GMT
> Server: Apache/2.4.27 (Fedora) OpenSSL/1.1.0f-fips mod_wsgi/4.5.15
> Python/2.7
> Content-Length: 205
> Content-Type: text/html; charset=UTF-8
> x-openstack-request-id: req-5ed2239f-165b-406f-969b-5cc4ab8c632d
> Connection: close
>
> 
>  
>   400 Bad Request
>  
>  
>   400 Bad Request
>   Getting images randomly from this store is not supported. Offset: 0,
> length: 33
>  
>
> Upon investigation, glance-api log is emitting:
>
> Nov 13 10:45:31 devstack@g-api.service[22783]: #033[01;31mERROR
> glance.location [#033[01;36mNone req-ad6da3f0-ead1-486a-a873-d301f02b0888
> #033[00;36mdemo demo#033[01;31m] 
> #033[01;35m#033[0│·1;31mGlance
> tried all active locations to get data for image
> 29b7aa5e-3ec2-49b5-ab6b-d6cc5099f46c but all have failed.#033[00m:
> StoreRandomGetNotSupported: Getting images randomly from this store is
> notMDg4OCAjMDMzWzAwOzM2bW supported. Offset: 0, length: 33
>
> The exception StoreRandomGetNotSupported is emitted by glance_store from
> glance_store/capabilities.py:
>
> op_exec_map = {
> 'get': (exceptions.StoreRandomGetNotSupported
> if kwargs.get('offset') or kwargs.get('chunk_size') else
> exceptions.StoreGetNotSupported),
> 'add': exceptions.StoreAddDisabled,
> 'delete': exceptions.StoreDeleteNotSupported}
>
> Looking at _driver/swift/store.py I think range requests are supported, it
> I've be unsuccessful in configuring it.
>
> Does the glance_store swift driver support range requests ?
>
> Can it be configured within a conf file, by somehow adding a capability ?
>
> 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
>



-- 
--
Thanks,
Nikhil
__
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] Please do not approve or recheck anything not related to CI alert bugs

[Wesley Hayutin]

On Sat, Nov 11, 2017 at 10:47 PM, Alex Schultz  wrote:

> Ok so here's the current status of things.  I've gone through some of
> the pending patches and sent them to the gate over the weekend since
> the gate was empty (yay!).  We've managed to land a bunch of patches.
> That being said for any patch for master with scenario jobs, please do
> not recheck/approve. Currently the non-containerized scenario001/004
> jobs are broken due to Bug 1731688[0] (these run on
> tripleo-quickstart-extras/tripleo-ci).  There is a patch[1] out for a
> revert of the breaking change. The scenario001-container job is super
> flaky due to Bug 1731063[2] and we could use some help figuring out
> what's going on.  We're also seeing some issues around heat
> interactions[3][4] but those seems to be less of a problem than the
> previously mentioned bugs.
>
> So at the moment any changes that don't have scenario jobs associated
> with them may be approved/rechecked freely.  We can discuss on Monday
> what to do about the scenario jobs if we still are running into issues
> without a solution in sight.  Also please keep an eye on the gate
> queue[5] and don't approve things if it starts getting excessively
> long.
>
> Thanks,
> -Alex
>
>
> [0] https://bugs.launchpad.net/tripleo/+bug/1731688
> [1] https://review.openstack.org/#/c/519041/
> [2] https://bugs.launchpad.net/tripleo/+bug/1731063
> [3] https://bugs.launchpad.net/tripleo/+bug/1731032
> [4] https://bugs.launchpad.net/tripleo/+bug/1731540
> [5] http://zuulv3.openstack.org/
>
> On Wed, Nov 8, 2017 at 3:39 PM, Alex Schultz  wrote:
> > So we have some good news and some bad news.  The good news is that
> > we've managed to get the gate queue[0] under control since we've held
> > off on pushing new things to the gate.  The bad news is that we've
> > still got some random failures occurring during the deployment of
> > master.  Since we're not seeing infra related issues, we should be OK
> > to merge things to stable/* branches.  Unfortunately until we resolve
> > the issues in master[1] we could potentially backup the queue.  Please
> > do not merge things that are not critical bugs.  I would ask that
> > folks please take a look at the open bugs and help figure out what is
> > going wrong. I've created two issues today that I've seen in the gate
> > that we don't appear to have open patches for. One appears to be an
> > issue in the heat deployment process[3] and the other is related to
> > the tempest verification of being able to launch a VM & ssh to it[4].
> >
> > Thanks,
> > -Alex
> >
> > [3] https://bugs.launchpad.net/tripleo/+bug/1731032
> > [4] https://bugs.launchpad.net/tripleo/+bug/1731063
> >
> > On Tue, Nov 7, 2017 at 8:33 AM, Alex Schultz 
> wrote:
> >> Hey Folks
> >>
> >> So we're at 24+ hours again in the gate[0] and the queue only
> >> continues to grow. We currently have 6 ci/alert bugs[1]. Please do not
> >> approve of recheck anything that isn't related to these bugs.  I will
> >> most likely need to go through the queue and abandon everything to
> >> clear it up as we are consistently hitting timeouts on various jobs
> >> which is preventing anything from merging.
> >>
> >> Thanks,
> >> -Alex
> >>
> > [0] http://zuulv3.openstack.org/
> > [1] https://bugs.launchpad.net/tripleo/+bugs?field.searchtext==-
> importance%3Alist=NEW%
> 3Alist=CONFIRMED%3Alist=TRIAGED%
> 3Alist=INPROGRESS%3Alist=CRITICAL&
> assignee_option=any=_reporter=&
> field.bug_commenter==_
> subscriber==ci+alert_combinator=
> ALL_cve.used=_dupes.used=_
> dupes=on_me.used=_patch.used=&
> field.has_branches.used=_branches=on
> has_no_branches.used=_no_branches=on_
> blueprints.used=_blueprints=on_no_
> blueprints.used=_no_blueprints=on=Search
>
> __
> 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
>


Thanks for continuing to push on this Alex!
__
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] [faas] [qinling] demo video

[Lingxian Kong]

On Tue, Nov 14, 2017 at 5:24 AM, Belmiro Moreira <
moreira.belmiro.email.li...@gmail.com> wrote:

> Hi,
> just started to look what's available as Functions as a Service in
> OpenStack.
> Thanks for the demo.
>
> What's the difference between "qinling" and "picasso"?
>

​Thanks for asking this question :-)​

​When I started to look at FaaS in OpenStack, picasso is the first thing I
evaluated. Technically, it's a very thin layer of picasso api, just
integrated with Keystone authentication, you still need to rely on
IronFunctions (open source version of the company Iron.io's commercial
product) service to make it work.​ What's more, I don't think that project
is actively maintained and the code style/python lib usage do not comply
with openstack 'best practise'.

Qinling is kind of 'neutral' project that can rely on different open source
container technologies (k8s, swarm, zun, etc.) using plugin mechanisam
rather than being locked in by 3rd party commercial products or open source
projects mainly maintained by one company. It's being developed tightly
with openstack community, it's using oslo libraries, zuul v3, openstack
style documenation, code style, irc channel, etc. Most importantly, it can
be integrated very well with other openstack services (Swift, Zaqar,
Ceilometer, Aodh, etc.)

I am developing this project because as an OpenStack based public cloud
provider we have FaaS requirement from our customers, and 'upstream first'
is our commitment as an open source company.
__
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] [ironic] this week's priorities and subteam reports

[Yeleswarapu, Ramamani]

Hi,

We are glad to present this week's priorities and subteam report for Ironic. As 
usual, this is pulled directly from the Ironic whiteboard[0] and formatted.

This Week's Priorities (as of the weekly ironic meeting)

1. CI migration to Zuul v3: take legacy jobs in tree: 
https://etherpad.openstack.org/p/ironic-zuulv3-intree-tracking
1.1. Clean up ironic-lib: https://review.openstack.org/518622 (jlvillal) 
MERGED
1.2. Clean up ironic-python-agent: https://review.openstack.org/#/c/518613/ 
(jlvillal)
1.3. Finish Bifrost (TheJulia)
2. Release ironic after oneview reverts below land (they are approved, waiting 
to merge). This is really for dtantsur to do.
3. Midcycle planning: https://etherpad.openstack.org/p/ironic-queens-midcycle
4. Rework keystone auth for Glance: https://review.openstack.org/#/c/467728/
5. BIOS interface spec: https://review.openstack.org/#/c/496481/
6. Rescue:
6.1. db https://review.openstack.org/#/c/509334/
6.2. driver interface https://review.openstack.org/#/c/509335/
6.3. RPC https://review.openstack.org/#/c/509336/
6.4. rescuewait timeout https://review.openstack.org/#/c/353156

Vendor priorities
-
cisco-ucs:
Patchs in works for SDK update, but not posted yet, currently rebuilding 
third party CI infra after a disaster...
idrac:

ilo:
https://review.openstack.org/207337 - Out-of-band Boot from UEFI iSCSI 
volume for HPE Proliant server
irmc:
SPEC to add a new hardware type for another FUJITSU server: PRIMEQUEST MMB:
https://review.openstack.org/#/c/515717/ 2x +2, awaits last-minute comments

oneview:
HIGH PRIORITY: need to revert changes that moved from python-oneviewclient 
to hpOneView library; this is blocking the ironic release (they're are already 
chained from 1 to 8. Ping ricardoas, nicodemos or fellypefca if there is some 
issue)
https://review.openstack.org/#/c/518766/
https://review.openstack.org/#/c/518768/
https://review.openstack.org/#/c/518769/
https://review.openstack.org/518770
https://review.openstack.org/518771
https://review.openstack.org/518772
https://review.openstack.org/518773
https://review.openstack.org/518774

Add validations for OneView ML2 driver -  
https://review.openstack.org/#/c/508946/

Subproject priorities
-
bifrost:
ironic-inspector (or its client):
dnsmasq-based inspector PXE filter driver: 
https://review.openstack.org/#/c/466448/ TL;DR: replaces iptables with a 
dynamic configuration of dnsmasq (pretty cool thing too ;)
folks might consider trying the test patch to experiment manually with this 
https://review.openstack.org/#/c/468712/54
networking-baremetal:
neutron baremetal agent https://review.openstack.org/#/c/456235/
sushy and the redfish driver:
(dtantsur) implement redfish sessions: 
https://review.openstack.org/#/c/471942/

Bugs (dtantsur, vdrok, TheJulia)

- Stats (diff between 06 Nov 2017 and 13 Nov 2017)
  - Ironic: 223 bugs (-13) + 247 wishlist items (-1). 13 new, 151 in progress 
(-15), 0 critical, 31 high (+1) and 34 incomplete (-1)
  - Inspector: 16 bugs + 31 wishlist items. 2 new, 16 in progress, 0 critical, 
4 high and 3 incomplete
  - Nova bugs with Ironic tag: 13 (+1). 1 new, 0 critical, 1 high
- HIGH bugs with patches to review:
  - Clean steps are not tested in gate 
https://bugs.launchpad.net/ironic/+bug/1523640: Add manual clean step ironic 
standalone test https://review.openstack.org/#/c/429770/15
  - prepare_instance() is not called for whole disk images with 'agent' deploy 
interface https://bugs.launchpad.net/ironic/+bug/1713916:
- Fix to return 'root_uuid' as part of command status 
https://review.openstack.org/#/c/500719/4
- Fix ``agent`` deploy interface to call ``boot.prepare_instance`` 
https://review.openstack.org/#/c/499050/
  - If provisioning network is changed, Ironic conductor does not behave 
correctly https://bugs.launchpad.net/ironic/+bug/1679260: Ironic conductor 
works correctly on changes of networks: https://review.openstack.org/#/c/462931/
- (rloo) needs some direction

CI refactoring and missing test coverage

- Zuul v3 jobs in-tree migration tracking 
https://etherpad.openstack.org/p/ironic-zuulv3-intree-tracking: everything 
migrated except for bifrost stable/ocata (tests failing, someone needs to look 
into it)
- not considered a priority, it's a 'do it always' thing
- Standalone CI tests (vsaienk0)
- next patch to be reviewed, needed for 3rd party CI: 
https://review.openstack.org/#/c/429770/
- localboot with partitioned image patches:
- IPA - build tinycore based partitioned image with grub 
https://review.openstack.org/#/c/504888/
- Ironic - add localboot partitioned image test: 
https://review.openstack.org/#/c/502886/
- when previous are merged TODO (vsaienko)
- Upload tinycore partitioned image to 

Re: [openstack-dev] [Release-job-failures][neutron] Tag of openstack/neutron-fwaas-dashboard failed

[Doug Hellmann]

Excerpts from zuul's message of 2017-11-13 20:37:18 +:
> Unable to freeze job graph: Unable to modify final job  publish-openstack-releasenotes branches: None source: 
> openstack-infra/project-config/zuul.d/jobs.yaml@master#26> attribute 
> required_projects={'openstack/horizon':  0x7ff848d06b70>} with variant  None source: 
> openstack-infra/openstack-zuul-jobs/zuul.d/project-templates.yaml@master#285>
> 

It looks like there is a configuration issue with
neutron-fwaas-dashboard.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra] support graphviz in document publishing

[Antoine Musso]

On 13/11/2017 10:16, Yujun Zhang (ZTE) wrote:
> Hi, all
> 
> Sometimes a picture worths thousands word. I wonder if it is possible to
> support graphviz in https://docs.openstack.org/
> 
> What I expect is to include a dot file and render it as a picture in
> HTML output. The syntax is simple
> 
> .. graphviz:: aggregate-equivalent-alarms.files/example.dot
> 
> And should be supported by sphinx graphviz plugin[2]
> 
> See full example[1]. Currently I render the picture offline and include
> it manually in the document. It would be much more convenient for
> developer if the extension is added to document build job.
> 
> [1]:
> https://review.openstack.org/#/c/518196/5/proposals/aggregate-equivalent-alarms.rst
> [2]: http://www.sphinx-doc.org/en/stable/ext/graphviz.html

Hello,

I had some success with http://blockdiag.com/ which, IIRC, is pure
python. It supports various kind of graphs (block, sequences, network ...).

The few I did were for Zuul:
https://docs.openstack.org/infra/zuul/user/gating.html

In sphinx that looks like:

.. blockdiag::

  blockdiag foo {
node_width = 40;
span_width = 40;
A <- B <- C <- D <- E;
  }


sphinxcontrib-blockdiag
https://pypi.python.org/pypi/sphinxcontrib-blockdiag

Might be worth looking at if you want something simpler than graphviz
and to not depend on it.

-- 
Antoine "hashar" Musso

__
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] Bug deputy report

[Sławek Kapłoński]

Hi all,

I was on bug deputy last week. There was no any high or critical bugs reported 
during this time.
Below is short summary about reported bugs:

L3 HA related bug:
* https://bugs.launchpad.net/neutron/+bug/1731595 - it needs some attention 
from L3 sub team IMO

OVS related bugs:
* https://bugs.launchpad.net/neutron/+bug/1731953 - it’s new one about ovs-fw 
and I want to check it more,
* https://bugs.launchpad.net/neutron/+bug/1730407 - this one has got already 
fix merged to master and pike,
* https://bugs.launchpad.net/neutron/+bug/1730552 - patch in review, also 
related to ovs-fw,
* https://bugs.launchpad.net/neutron/+bug/1731494 - this one I didn’t know what 
priority it should have, but it has already some patch in review also,

One bug related to linuxbridge:
* https://bugs.launchpad.net/neutron/+bug/1728080 - already assigned to Brian 
Haley.

Bugs related to QoS:
* https://bugs.launchpad.net/neutron/+bug/1730605 - this one I was waiting for 
more info and now I want to check it, but I didn’t know what priority it should 
have (medium?)
* https://bugs.launchpad.net/neutron/+bug/1730896 - it’s about QoS docs,

One bug related to Quotas:
* https://bugs.launchpad.net/neutron/+bug/1731250 - but it was reported only 
for Ocata so I wanted to test it for master but I didn’t have time yet.

There is one more for docs:
* https://bugs.launchpad.net/neutron/+bug/1731713 - I marked it as „Invalid” as 
it was probably created automatically because of flag „docimpact” in commit 
message. Maybe we should consider disable/remove this script which is creating 
such bug reports as „DocImpact” is already removed?

One bug about neutronclient: https://bugs.launchpad.net/neutron/+bug/1731597 
but do we still should fix such bugs? I’m not sure about current status of it.

And there is also one RFE bug: https://bugs.launchpad.net/neutron/+bug/1730959 
but as it is something for LBaaS I didn’t add „rfe” tag because I’m not sure if 
it should be discussed by Neutron’s drivers team.

That’s all on my side for this week.

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






signature.asc
Description: Message signed with OpenPGP
__
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] [puppet][ci] PTI jobs for Puppet modules

[Mohammed Naser]

Hi everyone,

With a few languages getting PTI jobs which are defined in
project-config, I think Puppet should be a candidate as the build and
release process of Puppet modules is the same across all modules.

Given that Puppet OpenStack has a large number of modules, in addition
to Infra's puppet modules, it would be good to have a project-template
specific for build and release of Puppet modules.

Most of the work is already done (the build and release jobs are
there).  The main work which is left is simply to create a
project-template for project-config (say openstack-puppet-jobs) and
then update project-config for all puppet modules to use this template
and make sure it gets removed from the specific repos.

If no one is opposed to this (or perhaps has any ideas on how we can
do this in a better way), I will start the work and push up a change
shortly that takes care of this.

Thanks!
Mohammed

__
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] [octavia] amphora fails to send request to members

[Michael Johnson]

Yipei,

I am struggling to follow some of the details as I see different information:

+---+-+
| Field | Value   |
+---+-+
| allocation_pools  | {"start": "10.0.1.1", "end": "10.0.1.9"}|
|   | {"start": "10.0.1.11", "end": "10.0.1.254"} |
| cidr  | 10.0.1.0/24 |
| created_at| 2017-11-05T12:37:56Z|
| description   | |
| dns_nameservers   | |
| enable_dhcp   | True|
| gateway_ip| 10.0.1.10   |
| host_routes   | |
| id| cbcf4f04-da6d-4800-8b40-4b141972c2bf|
| ip_version| 4   |
| ipv6_address_mode | |
| ipv6_ra_mode  | |
| name  | subnet1 |
| network_id| 310fea4b-36ae-4617-b499-5936e8eda842|
| project_id| c2a97a04cb6d4f25bdcb8b3f263c869e|
| revision_number   | 0   |
| service_types | |
| subnetpool_id | |
| tags  | |
| tenant_id | c2a97a04cb6d4f25bdcb8b3f263c869e|
| updated_at| 2017-11-05T12:37:56Z|
+---+-+

and

+---++
| Field | Value  |
+---++
| allocation_pools  | {"start": "10.0.1.2", "end": "10.0.1.254"} |
| cidr  | 10.0.1.0/24|
| created_at| 2017-10-08T06:33:09Z   |
| description   ||
| dns_nameservers   ||
| enable_dhcp   | True   |
| gateway_ip| 10.0.1.1   |
| host_routes   ||
| id| 37023e56-a8bf-4070-8022-f6b6bb7b8e82   |
| ip_version| 4  |
| ipv6_address_mode ||
| ipv6_ra_mode  ||
| name  | subnet1|
| network_id| 13185eec-0996-4a08-b353-6775d5926b4c   |
| project_id| e59bb8f3bf9342aba02f9ba5804ed2fb   |
| revision_number   | 0  |
| service_types ||
| subnetpool_id ||
| tags  ||
| tenant_id | e59bb8f3bf9342aba02f9ba5804ed2fb   |
| updated_at| 2017-10-08T06:33:09Z   |
+---++

That said, the comment about the version of the amphora is
interesting. We did this patch:
https://review.openstack.org/#/c/501915/ that may be playing a role
here.
It should just be adding a default route for traffic originating from
the VIP, which would not impact local subnet traffic, but it is the
only change I can think of that might be related.

Can you send the output of:
sudo ip netns exec amphora-haproxy ip route show table all

and

sudo ip netns exec amphora-haproxy ip rule show

from the failing amphora?

Michael

On Fri, Nov 10, 2017 at 7:24 PM, Yipei Niu  wrote:
> Hi, Michael,
>
> I tried to run to command, and I think the amphora can connect to the member
> (10.0.1.3). The results are as follows.
>
> ubuntu@amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f:~$ sudo ip netns exec
> amphora-haproxy ping 10.0.1.3
> sudo: unable to resolve host amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f
> PING 10.0.1.3 (10.0.1.3) 56(84) bytes of data.
> 64 bytes from 10.0.1.3: icmp_seq=1 ttl=64 time=189 ms
> 64 bytes from 10.0.1.3: icmp_seq=2 ttl=64 time=1.72 ms
> ^C
> --- 10.0.1.3 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1006ms
> rtt min/avg/max/mdev = 1.722/95.855/189.989/94.134 ms
>
> ubuntu@amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f:~$ sudo ip netns exec
> amphora-haproxy curl 10.0.1.3
> sudo: unable to resolve host amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f
> Welcome to 10.0.1.3
>
> 

Re: [openstack-dev] [python-openstacksdk][shade] Reviewing the merge-shade patches

[David Shrewsbury]

Hi!

Thanks for the explanations.

On Mon, Nov 13, 2017 at 11:30 AM, Monty Taylor  wrote:



I also think that the OpenStackCloud/OperatorCloud split from shade wound
> up being more confusing than helpful.
>

Yep. At the time, the classes were doing different auth things, so it at
least made a little sense. Now, not so much.


-Dave
-- 
David Shrewsbury (Shrews)
__
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] Nominate chem and matbu for tripleo-core !

[Dan Prince]

+1

On Thu, Nov 9, 2017 at 3:44 AM, Marios Andreou  wrote:

> Hello fellow owls,
>
> I would like to nominate (and imo these are both long overdue already):
>
> Sofer Athlan Guyot (chem)  and
>
> Mathieu Bultel (matbu)
>
> to tripleo-core. They have both made many many core contributions to the
> upgrades & updates over the last 3 cycles touching many of the tripleo
> repos (tripleo-heat-templates, tripleo-common, python-tripleoclient,
> tripleo-ci, tripleo-docs and others tripleo-quickstart/extras too unless am
> mistaken).
>
> IMO their efforts and contributions are invaluable for the upgrades squad
> (and beyond - see openstack overcloud config download for example) and we
> will be very lucky to have them as fully voting cores.
>
> Please vote with +1 or -1 for either or both chem and matbu - I'll keep it
> open for a week as customary,
>
> thank you,
>
> marios
>
> __
> 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 John Fulton core on TripleO

[Dan Prince]

+1

On Wed, Nov 8, 2017 at 5:24 PM, Giulio Fidente  wrote:

> Hi,
>
> I would like to propose John Fulton core on TripleO.
>
> I think John did an awesome work during the Pike cycle around the
> integration of ceph-ansible as a replacement for puppet-ceph, for the
> deployment of Ceph in containers.
>
> I think John has good understanding of many different parts of TripleO
> given that the ceph-ansible integration has been a complicated effort
> involving changes in heat/tht/mistral workflows/ci and last but not
> least, docs and he is more recently getting busier with reviews outside
> his main comfort zone.
>
> I am sure John would be a great addition to the team and I welcome him
> first to tune into radioparadise with the rest of us when joining #tripleo
>
> Feedback is welcomed!
> --
> Giulio Fidente
> GPG KEY: 08D733BA
>
> __
> 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] [keystone] Bug Smash Reminder

[Lance Bragstad]

Hey all,

Just a friendly reminder that this will be happening in APAC timezones
next week [0]. Sounds like a good opportunity to catch up on reviews and
get things merged if you're interested.

Thanks,

Lance


[0]
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124453.html




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] [Release-job-failures] Release of openstack/puppet-swift failed

[Doug Hellmann]

Excerpts from Alex Schultz's message of 2017-11-13 09:45:20 -0700:
> On Mon, Nov 13, 2017 at 8:02 AM, Doug Hellmann  wrote:
> > Excerpts from zuul's message of 2017-11-13 09:24:15 +:
> >> Build failed.
> >>
> >> - release-openstack-puppet 
> >> http://logs.openstack.org/08/087081b12493632186b60dc2c5ab6c95ade61ef6/release/release-openstack-puppet/a7bbd5c/
> >>  : POST_FAILURE in 1m 33s
> >> - announce-release announce-release : SKIPPED
> >>
> >
> > Another missing file:
> >
> > 2017-11-13 09:23:42.407283 | TASK [Build puppet module]
> > 2017-11-13 09:23:43.527939 | ubuntu-xenial | ERROR
> > 2017-11-13 09:23:43.528350 | ubuntu-xenial | {
> > 2017-11-13 09:23:43.528449 | ubuntu-xenial |   "failed": true,
> > 2017-11-13 09:23:43.528538 | ubuntu-xenial |   "msg": "[Errno 2] No such 
> > file or directory",
> > 2017-11-13 09:23:43.528632 | ubuntu-xenial |   "rc": 2
> > 2017-11-13 09:23:43.528716 | ubuntu-xenial | }
> >
> 
> So i think this is because the release hash is missing the change that
> included the bindep.txt to pull in puppet.  Same for the other module
> failures.  Have these been tagged or should we resubmit with updated
> hashes for the failed modules?
> 
> Thanks,
> -Alex

These failures are from the jobs triggered when the tags were added, so
we need new tags with new versions for the commits with the bindep
files.

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-dev] [python-openstacksdk] Existential question about Service/ServiceFilter

[Monty Taylor]

Hey everybody,

In the shade stack, one of the main changes is making Proxy a subclass 
of keystoneauth1.adapter.Adapter. This means we don't have to carry 
endpoint_override dicts around to pass to rest calls on the session, but 
instead let ksa handle that for us inside the Adapter structure. With 
that change, it means that Service/ServiceFilter is now *essentially* 
just doing the same job as the *_api_version code from os-client-config.


That logic is still important because we need to, at Connection 
construction time, know what version of a given service's Proxy object 
to instantiate and attach to the connection. (so that conn.image is 
openstack.image.v2._proxy.Proxy on v2 clouds and 
openstack.image.v1._proxy.Proxy on v1 clods)


We could just remove them and let the OCC CloudConfig object and config 
settings handle it, since we currently have default versions set there.


HOWEVER - I'm writing this because we'd also like to stop having default 
versions encoded in config and instead rely on doing version discovery 
properly to find the right versions, leaving *_api_version settings as 
overrides, not required config.


This brings us to the issue:

* In the current structure, if we use version discovery, we'd need to 
run it - for every service on the cloud - in the Connection constructor. 
That'll be unworkably slow.


* If we don't use version discovery, we can't remove the default version 
settings from openstack.config/clouds.yaml - and private clouds or other 
clouds that don't have vendor settings files will require the user to 
set overrides (that could be detected) on clouds that did not have the 
version of a service that we have set as our default.


* We could add a magic multi-version Proxy object that only does version 
discovery when someone tries to use it, and once it has done discovery 
creates the correct versioned Proxy object and does getattribute 
passthrough to it. This has the potential benefit of also being able to 
have the 'magic' Proxy have a copy of each known version. For instance:


  conn = Connection(cloud='example')
  # On this access, Connection has a magic Proxy Image object at
  # conn.image. When conn.image.__getattribute__ is run, it is
  # discovered that there is no 'real' proxy. ksa discovery is run,
  # v1 and v2 are discovered and openstack.image.v2._proxy.Proxy
  # is created and added the 'real' proxy attribute. Subsequent
  # __getattribute__ calls on conn.image get passed through to the
  # v2 proxy:
  conn.image.images()
  # If someone knows they want a specific version for a call, the
  # magic proxy can also add instances for each found version as
  # attributes, allowing:
  conn.image.v1.images()
  # or
  conn.image.v2.images()

* We could add magic __getattribute__ stuff to Connection itself so that 
the first time someone tries to touch one of the service proxy 
attributes we do version discovery for that and then just attach the 
correct proxy object in place the first time. It could also attach 
versioned attributes as above:


  conn = Connection(cloud='example')
  # On this access, conn.__getattribute__ looks for image, sees
  # that it's in the list of service-types but doesn't have a
  # Proxy object yet. It does ksa discovery, finds that
  # v1 and v2 exist and makes a openstack.image.v2._proxy.Proxy
  # object that it attaches to conn.image. Subsequent
  # __getattribute__ calls on conn note that conn.image exists
  # so just work as normal.
  conn.image.images()
  # If someone knows they want a specific version for a call, the
  # original __getattribute__ call can also add instances for each
  # found version as attributes on the 'main' proxy, allowing:
  conn.image.v1.images()
  # or
  conn.image.v2.images()

* We could do neither of those things and instead rely on persistent 
caching of version discovery. Perhaps add a 'login' command to OSC that 
will do an auth, grab the catalog and locally cache all the version 
discovery. If we find that cached data we'll use it, otherwise we'll 
generate it and cache it on our first use. I'm a bit skeptical that this 
is entirely the right call, as it would potentially be a large startup 
cost at times the user isn't expecting, and without cooperative remote 
content (such as the proposed profile document) invalidation becomes 
super hard to get right. (I DO think we should add persistent caching of 
version discovery documents to lower cost when using OSC on to of SDK - 
but I worry about having basic functionality depend on such code.


Does anyone have a preference of one approach over the other? Or other 
suggestions?


__
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] [Release-job-failures] Release of openstack/puppet-swift failed

[Alex Schultz]

On Mon, Nov 13, 2017 at 8:02 AM, Doug Hellmann  wrote:
> Excerpts from zuul's message of 2017-11-13 09:24:15 +:
>> Build failed.
>>
>> - release-openstack-puppet 
>> http://logs.openstack.org/08/087081b12493632186b60dc2c5ab6c95ade61ef6/release/release-openstack-puppet/a7bbd5c/
>>  : POST_FAILURE in 1m 33s
>> - announce-release announce-release : SKIPPED
>>
>
> Another missing file:
>
> 2017-11-13 09:23:42.407283 | TASK [Build puppet module]
> 2017-11-13 09:23:43.527939 | ubuntu-xenial | ERROR
> 2017-11-13 09:23:43.528350 | ubuntu-xenial | {
> 2017-11-13 09:23:43.528449 | ubuntu-xenial |   "failed": true,
> 2017-11-13 09:23:43.528538 | ubuntu-xenial |   "msg": "[Errno 2] No such file 
> or directory",
> 2017-11-13 09:23:43.528632 | ubuntu-xenial |   "rc": 2
> 2017-11-13 09:23:43.528716 | ubuntu-xenial | }
>

So i think this is because the release hash is missing the change that
included the bindep.txt to pull in puppet.  Same for the other module
failures.  Have these been tagged or should we resubmit with updated
hashes for the failed modules?

Thanks,
-Alex

> __
> 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] [infra] support graphviz in document publishing

[Michael Johnson]

The Octavia project has a few graphviz diagrams in it's documentation.
You can reference that project to see how it is done.
That said, we have seen a decline in the stability of the graphviz
code over the last few years (cylinder object disappeared, graphviz
dot crashes on Ubuntu, etc.) that we have had to work around to get
the diagrams to continue to render. Because of that I would recommend
you use it sparingly.

Michael


On Mon, Nov 13, 2017 at 2:08 AM, Sean McGinnis  wrote:
> On Mon, Nov 13, 2017 at 09:16:59AM +, Yujun Zhang (ZTE) wrote:
>> Hi, all
>>
>> Sometimes a picture worths thousands word. I wonder if it is possible to
>> support graphviz in https://docs.openstack.org/
>>
>> What I expect is to include a dot file and render it as a picture in HTML
>> output. The syntax is simple
>>
>> .. graphviz:: aggregate-equivalent-alarms.files/example.dot
>>
>> And should be supported by sphinx graphviz plugin[2]
>>
>
> Hey Yujun,
>
> The graphviz directive is currently supported [0]. Though the control over the
> output leaves a little to be desired [1].
>
> I'm not sure about referencing dotfiles, but most needs are fairly small and
> can be done inline like the example above.
>
> [0] 
> https://git.openstack.org/cgit/openstack/cinder/tree/doc/source/contributor/api_microversion_dev.rst#n81
> [1] 
> https://docs.openstack.org/cinder/latest/contributor/api_microversion_dev.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [python-openstacksdk][shade] Reviewing the merge-shade patches

[Monty Taylor]

On 11/13/2017 09:06 AM, David Shrewsbury wrote:

Hi!

On Mon, Nov 13, 2017 at 9:54 AM, Monty Taylor > wrote:


Hey everybody,

You may have noticed a giant patch series up:

https://review.openstack.org/#/q/topic:merge-shade




One thing I don't see covered here is the current set of Ansible module 
tests. Unless I've missed it,
I don't see any migration of those, nor any reference of the plan for 
them in the future. I know that
we were waiting for Zuulv3 to do some cool github integration things. 
And since the modules import
shade, not this code, we won't be breaking them. But, what's the plan 
for that?


That's a great question. I actually did add the ansible functional tests 
to the "add zuulv3 jobs" patch - but as you say, those aren't really 
testing anything yet since the ansible modules do "import shade"


That brings up a few really good things that should be pointed out:

1) The intent is to turn the code in the shade repo into a thin compat 
shim that imports python-openstacksdk and subclasses/wraps the sdk 
object. That'll let us fix some of the interface mistakes we made in 
shade but are stuck with for compat reasons in the sdk version of the 
code ... but can still keep the old defaults/behavior in the shade code. 
For instance ... we've learned that fetching extra_specs on flavors in 
shade was ... stupid. We can have the sdk version NOT fetch by default, 
then in shade do:


def list_flavors(self, fetch_extra_specs=True):
return super(OpenStackCloud, self).list_flavors(
fetch_extra_specs=fetch_extra_specs)

With this in place, it should mean that shade users can continue on 
without being broken.


2) Once we have a release of openstacksdk that has the shade code in a 
place we're happy with, we should update the ansible modules to do 
import openstack instead of import shade


3) Cross-testing shade, os-client-config and openstacksdk is essential, 
so that we can make sure we're not breaking anything as we work on 
compat shims. The same goes with python-openstackclient, but current v3 
and the v4 branch dean is working on. We should probably add a shared 
change queue to the zuul v3 config for each of them. We can't add 
python-openstackclient to that shared queue since I'm pretty sure it's 
in the integrated-gate change queue. We COULD add shade, sdk and occ to 
the integrated-gate queue ... but that might slow us down at the moment, 
so maybe once it's all tied in together like we want it ...


4) openstack.cloud is the wrong home for the shade code. It's just there 
for expedience sake for now (let's not change TOO many things all at 
once) I'm *pretty* sure the shade methods want to just live on the 
Connection object, so that we wind up with:


  conn = openstack.connection.Connection(cloud='example')
  conn.list_servers() # shade version
  conn.compute.servers() # sdk version
  conn.compute.get('/servers') # REST version

We could alternately put it as a sub-resource, but since the shade 
methods are intended to be the 'easy' methods, doing this:


  conn = openstack.connection.Connection(cloud='example')
  conn.cloud.list_servers() # shade version
  conn.compute.servers() # sdk version
  conn.compute.get('/servers') # REST version

feels wrong. Maybe keeping the code in openstack/cloud is fine and just 
making it a mixin class (kind of like how we do in shade today with the 
normalize methods) would allow for some better source-code organization.


I also think that the OpenStackCloud/OperatorCloud split from shade 
wound up being more confusing than helpful.


Finally - while I'm rambling here ... after we finish the Resource -> 
Resource2 migration, I'd love to ponder whether or not we can make 
Resource2 be a subclass of munch.Munch. shade needs to be able to return 
objects that are directly json serializable (so that the ansible layer 
works easily/well) - it would be awesome if we didn't have to shove a 
to_dict() into every return on that layer. I haven't dug in to the magic 
guts of Resource2 fully, so I'm not 100% sure doing that will work. 
Since Resource2 is already doing data model definition via object 
parameters the munch part may not be super useful. We'll have to think 
about how we can pass through something so that shade users get things 
that are isinstance(munch.Munch) though - which is maybe a metaclass if 
we can't do it directly at the Resource layer.


Monty

__
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] [ironic] virtual midcycle planning

[Dmitry Tantsur]

Hi all!

We're slowly progressing from Queens M-2 to M-3, and it means that it's time for 
a virtual midcycle!


Please put proposed topics to 
https://etherpad.openstack.org/p/ironic-queens-midcycle. Please vote on a date 
on https://doodle.com/poll/wcqeu66fa6axusvw. We will pick 1-2 days, depending on 
the number of accepted topics.


Please try to finish voting by end of this week.

Thanks,
Dmitry

__
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] [faas] [qinling] demo video

[Belmiro Moreira]

Hi,
just started to look what's available as Functions as a Service in
OpenStack.
Thanks for the demo.

What's the difference between "qinling" and "picasso"?

https://github.com/openstack/qinling
https://github.com/openstack/picasso

cheers,
Belmiro

On Mon, Nov 13, 2017 at 11:03 AM, Lingxian Kong 
wrote:

> Hi, all
>
> For those who are interested in Qinling project (and its integration with
> other OpenStack services), I recorded the demo in my summit
> presentation[1], which is very similar to the use case of integration
> between AWS Lambda and S3.
>
> https://youtu.be/K2SiMZllN_A
>
> If you have any questions about Qinling, feel free to ask in
> #openstack-qinling irc channel, my irc name is kong. I am always online
> from UTC 20:30 to UTC 04:00, but you can leave messages to me anyway.
>
> [1]: https://www.openstack.org/videos/sydney-2017/make-
> your-application-serverless
>
> Cheers,
> Lingxian Kong (Larry)
>
> __
> 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] Building Openstack Trove Images

[Sam Matzek]

As Amrith stated, you need to look at the Neutron logs as the message about
port binding suggests:

PortBindingFailed: Binding failed for port
26b727dd-52b4-4b34-b484-6ea3fd571c8d,
please check neutron logs for more information.

On Mon, Nov 13, 2017 at 8:22 AM, Debojyoti Das  wrote:

> Hi All,
>
> Please help us regarding the Openstack Issue, we are facing the following
> error in our Openstack Environment, and we had tried almost every solution
> found at internet but not able to resolve the issue.
>
> we have added one compute node to our Openstack controller which is
> showing in the openstack dashboard however the when we launch any VM, the
> VM goes into error state. We have gone through most of the things available
> on the internet but nothing sorts it out. Below are the logs for the error:
>
>
>
> ERROR nova.compute.manager [instance: 054229be-3467-490d-b407-dc256a8747c8]
> File "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py",
> line 984, in _update_ports_for_instance
>
> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
> 054229be-3467-490d-b407-dc256a8747c8] port_client, instance, port_id,
> port_req_body)
>
> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
> 054229be-3467-490d-b407-dc256a8747c8]   File
> "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line
> 445, in _update_port
>
> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
> 054229be-3467-490d-b407-dc256a8747c8] _ensure_no_port_binding_failur
> e(port)
>
> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
> 054229be-3467-490d-b407-dc256a8747c8]   File
> "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line
> 191, in _ensure_no_port_binding_failure
>
> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
> 054229be-3467-490d-b407-dc256a8747c8] raise
> exception.PortBindingFailed(port_id=port['id'])
>
> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
> 054229be-3467-490d-b407-dc256a8747c8] PortBindingFailed: Binding failed
> for port 26b727dd-52b4-4b34-b484-6ea3fd571c8d, please check neutron logs
> for more information.
>
>
>
>
> Can you throw some light or give us some guidance on this as it has halted
> the implementation of our Production Openstack Pike.
>
> Your support and co-operation is highly appreciated.
>
>
> FYI: Controller and compute node are running CentOS7.
>
> On Mon, Nov 13, 2017 at 6:41 PM, Debojyoti Das <
> debojyoti@indusnet.co.in> wrote:
>
>> Hi Amrith,
>>
>> Please throw some light to the issue, we have stuck at a serious point of
>> our Production migration from Cloudstack to Openstack. So Please help us,
>> you co-operation is highly appreciated.
>>
>> On Mon, Nov 13, 2017 at 6:10 PM, Debojyoti Das <
>> debojyoti@indusnet.co.in> wrote:
>>
>>> Hi Amrith,
>>>
>>> Please throw some light to the issue, we have stuck at a serious point
>>> of our Production migration from Cloudstack to Openstack. So Please help
>>> us, you co-operation is highly appreciated.
>>>
>>> On Mon, Nov 13, 2017 at 1:29 PM, Ritesh Vishwakarma <
>>> ritesh.vishwaka...@indusnet.co.in> wrote:
>>>
 Hi Amirth,



 Many thanks for your response coz of which I was able to build a MySQL
 image from Ubuntu Xenial.

 However, I am facing another obstacle now, we have added one compute
 node to our Openstack controller which is showing in the openstack
 dashboard however the when we launch any VM, the VM goes into error state.
 We have gone through most of the things available on the internet but
 nothing sorts it out. Below are the logs for the error:



 ERROR nova.compute.manager [instance: 054229be-3467-490d-b407-dc256a8747c8]
 File "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py",
 line 984, in _update_ports_for_instance

 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
 054229be-3467-490d-b407-dc256a8747c8] port_client, instance,
 port_id, port_req_body)

 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
 054229be-3467-490d-b407-dc256a8747c8]   File
 "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line
 445, in _update_port

 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
 054229be-3467-490d-b407-dc256a8747c8]
 _ensure_no_port_binding_failure(port)

 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
 054229be-3467-490d-b407-dc256a8747c8]   File
 "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line
 191, in _ensure_no_port_binding_failure

 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
 054229be-3467-490d-b407-dc256a8747c8] raise
 exception.PortBindingFailed(port_id=port['id'])

 2017-11-12 02:58:57.551 2372 ERROR 

Re: [openstack-dev] [Release-job-failures] Release of openstack/puppet-swift failed

[Doug Hellmann]

Excerpts from zuul's message of 2017-11-13 09:24:15 +:
> Build failed.
> 
> - release-openstack-puppet 
> http://logs.openstack.org/08/087081b12493632186b60dc2c5ab6c95ade61ef6/release/release-openstack-puppet/a7bbd5c/
>  : POST_FAILURE in 1m 33s
> - announce-release announce-release : SKIPPED
> 

Another missing file:

2017-11-13 09:23:42.407283 | TASK [Build puppet module]
2017-11-13 09:23:43.527939 | ubuntu-xenial | ERROR
2017-11-13 09:23:43.528350 | ubuntu-xenial | {
2017-11-13 09:23:43.528449 | ubuntu-xenial |   "failed": true,
2017-11-13 09:23:43.528538 | ubuntu-xenial |   "msg": "[Errno 2] No such file 
or directory",
2017-11-13 09:23:43.528632 | ubuntu-xenial |   "rc": 2
2017-11-13 09:23:43.528716 | ubuntu-xenial | }

__
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] [python-openstacksdk][shade] Reviewing the merge-shade patches

[David Shrewsbury]

Hi!

On Mon, Nov 13, 2017 at 9:54 AM, Monty Taylor  wrote:

> Hey everybody,
>
> You may have noticed a giant patch series up:
>
>   https://review.openstack.org/#/q/topic:merge-shade
>
> 

One thing I don't see covered here is the current set of Ansible module
tests. Unless I've missed it,
I don't see any migration of those, nor any reference of the plan for them
in the future. I know that
we were waiting for Zuulv3 to do some cool github integration things. And
since the modules import
shade, not this code, we won't be breaking them. But, what's the plan for
that?

-- 
David Shrewsbury (Shrews)
__
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] [Release-job-failures][puppet] Release of openstack/puppet-ceilometer failed

[Doug Hellmann]

Excerpts from zuul's message of 2017-11-13 09:17:54 +:
> Build failed.
> 
> - release-openstack-puppet 
> http://logs.openstack.org/0d/0d3bfc02991ac28527980462e709d796e3305c50/release/release-openstack-puppet/ddcbbb6/
>  : POST_FAILURE in 1m 33s
> - announce-release announce-release : SKIPPED
> 

Same again.

__
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] [Release-job-failures][puppet] Release of openstack/puppet-gnocchi failed

[Doug Hellmann]

Excerpts from zuul's message of 2017-11-13 09:21:31 +:
> Build failed.
> 
> - release-openstack-puppet 
> http://logs.openstack.org/dc/dce26ec244199a83724bdcbfbb4665652ea37698/release/release-openstack-puppet/6d26826/
>  : POST_FAILURE in 2m 18s
> - announce-release announce-release : SKIPPED
> 

Same error.

__
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] [Release-job-failures][puppet] Release of openstack/puppet-glance failed

[Doug Hellmann]

Excerpts from zuul's message of 2017-11-13 09:23:16 +:
> Build failed.
> 
> - release-openstack-puppet 
> http://logs.openstack.org/7a/7a2e3aa6531521076b4b785dbdc2943f67953db6/release/release-openstack-puppet/5bcb484/
>  : POST_FAILURE in 1m 29s
> - announce-release announce-release : SKIPPED
> 

This is another missing file error.

__
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] [Release-job-failures][puppet] Release of openstack/puppet-magnum failed

[Mohammed Naser]

Sorry for the top post, looks like it was puppet-magnum that might be missing 
adding “puppet” to its bindep file. 

I’ll look into this shortly

Sent from my iPhone

> On Nov 13, 2017, at 9:57 AM, Doug Hellmann  wrote:
> 
> Excerpts from zuul's message of 2017-11-13 09:25:04 +:
>> Build failed.
>> 
>> - release-openstack-puppet 
>> http://logs.openstack.org/52/5294a365d29a7c6745856aae5d78f09c709f7fc1/release/release-openstack-puppet/fd776d7/
>>  : POST_FAILURE in 1m 36s
>> - announce-release announce-release : SKIPPED
>> 
> 
> The error for this one is:
> 
> 2017-11-13 09:24:26.571661 | TASK [Build puppet module]
> 2017-11-13 09:24:27.661667 | ubuntu-xenial | ERROR
> 2017-11-13 09:24:27.662090 | ubuntu-xenial | {
> 2017-11-13 09:24:27.662189 | ubuntu-xenial |   "failed": true,
> 2017-11-13 09:24:27.662277 | ubuntu-xenial |   "msg": "[Errno 2] No such file 
> or directory",
> 2017-11-13 09:24:27.662363 | ubuntu-xenial |   "rc": 2
> 2017-11-13 09:24:27.662458 | ubuntu-xenial | }
> 
> It's not clear from the error output what file is missing.
> 
> 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] [Release-job-failures][puppet] Release of openstack/puppet-magnum failed

[Doug Hellmann]

Excerpts from zuul's message of 2017-11-13 09:25:04 +:
> Build failed.
> 
> - release-openstack-puppet 
> http://logs.openstack.org/52/5294a365d29a7c6745856aae5d78f09c709f7fc1/release/release-openstack-puppet/fd776d7/
>  : POST_FAILURE in 1m 36s
> - announce-release announce-release : SKIPPED
> 

The error for this one is:

2017-11-13 09:24:26.571661 | TASK [Build puppet module]
2017-11-13 09:24:27.661667 | ubuntu-xenial | ERROR
2017-11-13 09:24:27.662090 | ubuntu-xenial | {
2017-11-13 09:24:27.662189 | ubuntu-xenial |   "failed": true,
2017-11-13 09:24:27.662277 | ubuntu-xenial |   "msg": "[Errno 2] No such file 
or directory",
2017-11-13 09:24:27.662363 | ubuntu-xenial |   "rc": 2
2017-11-13 09:24:27.662458 | ubuntu-xenial | }

It's not clear from the error output what file is missing.

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-dev] [python-openstacksdk][shade] Reviewing the merge-shade patches

[Monty Taylor]

Hey everybody,

You may have noticed a giant patch series up:

  https://review.openstack.org/#/q/topic:merge-shade

It's a big beastie, so I thought a synopsis of what's going would be 
useful. Also, there's a pile of patches towards the end that we want to 
squash before landing but which have been pushed up in smaller patches 
because reading it all as one patch would be unpossible - but reworking 
the unittest mocks for each step would be wasted energy.


Any of the patches in this email that are green from Zuul are ready for 
review/merge.


The easy patches:

These next patches are easy because they're just mechanical - nothing 
really will have changed in SDK because of them.


https://review.openstack.org/#/c/518128 - Merge shade and 
os-client-config into the tree


You can't see the whole picture in gerrit. This merges in shade and 
os-client-config, including their entire git history. Most of that merge 
got pushed up to a throwaway branch so that the review in gerrit would 
be a single patch containing the merge. It's best to just grab the repo 
at that branch and take a look.


It's also important to note here that I'm pretty sure openstack.cloud is 
not actually where shade wants to live and that openstack.config needs a 
refactor - but we can do that after this stack, as the stack is too big 
already.


https://review.openstack.org/#/c/518129/ - Merge in recent fixes from 
the shade repo


Merges patches that already landed in shade between the time I made the 
first merge commit and proposed it. No need to actually review the 
content itself.


https://review.openstack.org/#/c/518130 - Add jobs for Zuul v3

Adds functional zuulv3 native test jobs that match what shade was doing. 
These run both shade and sdk's functional tests (they're one set of tests)


https://review.openstack.org/#/c/518946 - Fix magnum functional test

Fixes the previous one.

https://review.openstack.org/#/c/518131 - Handle glance image pagination 
links better
https://review.openstack.org/#/c/518132 - Fix regression for 
list_router_interfaces
https://review.openstack.org/#/c/518133 - Support filtering servers in 
list_servers using arbitrary parameters


Patches landed in shade in the interim. No need to review content.

Once those are landed we're ready for some fun:

https://review.openstack.org/#/c/518799 - Migrate to testtools for 
functional tests


Reworks the functional base class to use the testtools based functional 
base class from shade, along with the logger fakes and whatnot. The 
biggest change here is the move to using setUp/tearDown instead of 
setUpClass/tearDownClass.


This patch is annoyingly large, but it's also important so that we have 
one consistent approach to these things across the combined codebase.


https://review.openstack.org/#/c/519029 - Rework config and rest layers

The squahsed/rollup patch. It can be viewed broken out by looking at the 
other patches that have https://review.openstack.org/#/c/518799 as a parent.


This is where all of the invasive breaking-changes happen. Most notably 
stepping away from Profile, Session and Authenticator in favor of using 
openstack.config/os-client-config and the Adapter class from 
keystoneauth so that we can rely on ksa for discovery and whatnot. It 
also adds a pure-rest interface on each service, removes the plugin 
entrypoints structure and and renames 4 of the service objects to match 
their official service-type (although it also keeps aliases so that 
shouldn't cause too much carnage for people)


Removal of profile/authenticator is the biggest user-visible breaking 
change, and it's not ACTUALLY removed in this patch (although it was at 
one point) We have to keep Profile around long enough to remove its use 
from OSC - including osc3, since OSC is used to set up resources as part 
of devstack. It might be worthwhile to consider fleshing out the 
backwards compat for allowing profiles to be passed in for a short time 
since it's there now.


There's still a little more plumbing to do before we can start working 
on using this layer under the shade code - most notably we need to plumb 
in the task manager ... but to my knowledge this stack works with Dean's 
OSC4 branch so we should be in good shape.


https://review.openstack.org/#/c/501438 - Add notes about moving forward

A document with some thoughts - some of which are a good idea and some 
not - about next steps and what we need to get done.


Thanks for the patience in reading these ... they're SUPER long. In many 
cases it's about letting the test suites let us know they're ok.


Monty

__
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] Building Openstack Trove Images

[Debojyoti Das]

Hi All,

Please help us regarding the Openstack Issue, we are facing the following
error in our Openstack Environment, and we had tried almost every solution
found at internet but not able to resolve the issue.

we have added one compute node to our Openstack controller which is showing
in the openstack dashboard however the when we launch any VM, the VM goes
into error state. We have gone through most of the things available on the
internet but nothing sorts it out. Below are the logs for the error:



ERROR nova.compute.manager [instance: 054229be-3467-490d-b407-dc256a8747c8]
File "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line
984, in _update_ports_for_instance

2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
054229be-3467-490d-b407-dc256a8747c8] port_client, instance, port_id,
port_req_body)

2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
054229be-3467-490d-b407-dc256a8747c8]   File "/usr/lib/python2.7/site-
packages/nova/network/neutronv2/api.py", line 445, in _update_port

2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
054229be-3467-490d-b407-dc256a8747c8] _ensure_no_port_binding_
failure(port)

2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
054229be-3467-490d-b407-dc256a8747c8]   File "/usr/lib/python2.7/site-
packages/nova/network/neutronv2/api.py", line 191, in
_ensure_no_port_binding_failure

2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
054229be-3467-490d-b407-dc256a8747c8] raise exception.PortBindingFailed(
port_id=port['id'])

2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
054229be-3467-490d-b407-dc256a8747c8] PortBindingFailed: Binding failed for
port 26b727dd-52b4-4b34-b484-6ea3fd571c8d, please check neutron logs for
more information.




Can you throw some light or give us some guidance on this as it has halted
the implementation of our Production Openstack Pike.

Your support and co-operation is highly appreciated.


FYI: Controller and compute node are running CentOS7.

On Mon, Nov 13, 2017 at 6:41 PM, Debojyoti Das  wrote:

> Hi Amrith,
>
> Please throw some light to the issue, we have stuck at a serious point of
> our Production migration from Cloudstack to Openstack. So Please help us,
> you co-operation is highly appreciated.
>
> On Mon, Nov 13, 2017 at 6:10 PM, Debojyoti Das <
> debojyoti@indusnet.co.in> wrote:
>
>> Hi Amrith,
>>
>> Please throw some light to the issue, we have stuck at a serious point of
>> our Production migration from Cloudstack to Openstack. So Please help us,
>> you co-operation is highly appreciated.
>>
>> On Mon, Nov 13, 2017 at 1:29 PM, Ritesh Vishwakarma <
>> ritesh.vishwaka...@indusnet.co.in> wrote:
>>
>>> Hi Amirth,
>>>
>>>
>>>
>>> Many thanks for your response coz of which I was able to build a MySQL
>>> image from Ubuntu Xenial.
>>>
>>> However, I am facing another obstacle now, we have added one compute
>>> node to our Openstack controller which is showing in the openstack
>>> dashboard however the when we launch any VM, the VM goes into error state.
>>> We have gone through most of the things available on the internet but
>>> nothing sorts it out. Below are the logs for the error:
>>>
>>>
>>>
>>> ERROR nova.compute.manager [instance: 054229be-3467-490d-b407-dc256a8747c8]
>>> File "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py",
>>> line 984, in _update_ports_for_instance
>>>
>>> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
>>> 054229be-3467-490d-b407-dc256a8747c8] port_client, instance,
>>> port_id, port_req_body)
>>>
>>> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
>>> 054229be-3467-490d-b407-dc256a8747c8]   File
>>> "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line
>>> 445, in _update_port
>>>
>>> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
>>> 054229be-3467-490d-b407-dc256a8747c8] _ensure_no_port_binding_failur
>>> e(port)
>>>
>>> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
>>> 054229be-3467-490d-b407-dc256a8747c8]   File
>>> "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line
>>> 191, in _ensure_no_port_binding_failure
>>>
>>> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
>>> 054229be-3467-490d-b407-dc256a8747c8] raise
>>> exception.PortBindingFailed(port_id=port['id'])
>>>
>>> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
>>> 054229be-3467-490d-b407-dc256a8747c8] PortBindingFailed: Binding failed
>>> for port 26b727dd-52b4-4b34-b484-6ea3fd571c8d, please check neutron
>>> logs for more information.
>>>
>>>
>>>
>>>
>>>
>>> Can you throw some light or give us some guidance on this as it has
>>> halted the implementation of our Production Openstack Pike.
>>>
>>> Your support and co-operation is highly appreciated.
>>>
>>>
>>> FYI: Controller and compute node are 

[openstack-dev] [mistral] No team meeting today - 11/13/2017

[Renat Akhmerov]

Hi, we’re cancelling the team meeting today because a number of key members 
won’t attend.

Thanks

Renat Akhmerov
@Nokia
__
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] OpenStack Bug Smash for Queens

[Fred Li]

Hi all,

Just to remind that Bug Smash Queens will happen next week.

In this week's weekly meeting, hope you can inform projects team and
list bugs expected to be fixed in [5]. And if you can assign core
reviewers to take care of the bugs from Nov 22 to 24, that would be
fantastic.


On Mon, Oct 23, 2017 at 10:10 AM, ChangBo Guo  wrote:
> Thanks Fred  for raising this.
>
> BWT ,  we have a session about the Bug Smash event in Sydney Summit [1],
> please join us if you're interested.
>
>
> [1]
> https://www.openstack.org/summit/sydney-2017/summit-schedule/events/19746/what-china-developers-brought-to-community-after-6-openstack-bug-smash-events
>
> 2017-10-21 15:40 GMT+08:00 Fred Li :
>>
>> Hi all OpenStackers,
>>
>> Since April 2015, there have been 6 OpenStack Bug Smash events in
>> China. OpenStack Bug Smash has been a routine and exciting event by
>> OpenStacker expects. In the past 5 bug smashes, over 300 top
>> developers from many companies(Huawei,Intel,CMCC, IBM, Mirantis,
>> Awcloud, 99cloud, UnitedStack, EasyStack, LeTV, ZTE, and etc.)
>> contributed 600+ bugs to community. This achievement significantly
>> demonstrated the technical strength of Chinese engineers. Huawei,
>> Intel and those companies show the commitment of OpenStack Stability
>> to enterprise customers.
>>
>> Now, the 7th OpenStack bug smash is coming. Intel, Huawei, Fiberhome
>> and CESI will host this event. Intel, Huawei and Fiberhome are all
>> OpenStack members[1].
>> Come to join other OpenStackers to make Queens a grand success!
>> Come to learn tips and gain a better understanding by working closely
>> with other talents.
>> Each focused project will have a core on standby to review patches and
>> vote for merges.
>>
>> Queens Bug SmashObject: smash the critical and high bugs in key
>> projects. Focused projects: Nova, Neutron, Cinder, Keystone, Manila,
>> Heat, Telemetry, Karbor, Tricircle, and the ones you want to add.
>>
>> To all the projects team leaders, you can discuss with your team
>> members in the project meeting and mark the bugs you expect OpenStack
>> Bug Smash Queens to fix. If you can arrange core reviewers to take
>> care of the patches during that week, that will be more efficient.
>>
>> Date: from Nov 22 to Nov 24, which is 2 weeks prior to Queens-2
>> milestone[2].
>>
>> Location: 中国湖北省武汉市洪山区邮科院路88号，烽火创新谷武汉国际创客中心五楼一号会议室 [3]
>>
>>
>> Please start to register in [4].
>> And start to list the bugs to be fixed in [5].
>>
>> [1] https://www.openstack.org/foundation/companies/
>> [2] https://releases.openstack.org/queens/schedule.html
>> [3]
>> https://www.google.co.jp/maps/place/88+You+Ke+Yuan+Lu,+GuangGu+ShangQuan,+Hongshan+Qu,+Wuhan+Shi,+Hubei+Sheng,+China,+430073/@30.5107646,114.392814,17z/data=!3m1!4b1!4m5!3m4!1s0x342ea4ce1537ed17:0x52ff45d6b5dba38c!8m2!3d30.51076!4d114.395008?hl=en
>> [4] https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Queens-Wuhan
>> [5]
>> https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Queens-Wuhan-Bugs-List
>>
>>
>> Regards
>> Fred Li (李永乐)
>>
>> __
>> 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
>
>
>
>
> --
> ChangBo Guo(gcb)
> Community Director @EasyStack
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards
Fred Li (李永乐)

__
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] Building Openstack Trove Images

[Debojyoti Das]

Hi Amrith,

Please throw some light to the issue, we have stuck at a serious point of
our Production migration from Cloudstack to Openstack. So Please help us,
you co-operation is highly appreciated.

On Mon, Nov 13, 2017 at 6:10 PM, Debojyoti Das  wrote:

> Hi Amrith,
>
> Please throw some light to the issue, we have stuck at a serious point of
> our Production migration from Cloudstack to Openstack. So Please help us,
> you co-operation is highly appreciated.
>
> On Mon, Nov 13, 2017 at 1:29 PM, Ritesh Vishwakarma <
> ritesh.vishwaka...@indusnet.co.in> wrote:
>
>> Hi Amirth,
>>
>>
>>
>> Many thanks for your response coz of which I was able to build a MySQL
>> image from Ubuntu Xenial.
>>
>> However, I am facing another obstacle now, we have added one compute node
>> to our Openstack controller which is showing in the openstack dashboard
>> however the when we launch any VM, the VM goes into error state. We have
>> gone through most of the things available on the internet but nothing sorts
>> it out. Below are the logs for the error:
>>
>>
>>
>> ERROR nova.compute.manager [instance: 054229be-3467-490d-b407-dc256a8747c8]
>> File "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py",
>> line 984, in _update_ports_for_instance
>>
>> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
>> 054229be-3467-490d-b407-dc256a8747c8] port_client, instance,
>> port_id, port_req_body)
>>
>> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
>> 054229be-3467-490d-b407-dc256a8747c8]   File
>> "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line
>> 445, in _update_port
>>
>> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
>> 054229be-3467-490d-b407-dc256a8747c8] _ensure_no_port_binding_failur
>> e(port)
>>
>> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
>> 054229be-3467-490d-b407-dc256a8747c8]   File
>> "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line
>> 191, in _ensure_no_port_binding_failure
>>
>> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
>> 054229be-3467-490d-b407-dc256a8747c8] raise
>> exception.PortBindingFailed(port_id=port['id'])
>>
>> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
>> 054229be-3467-490d-b407-dc256a8747c8] PortBindingFailed: Binding failed
>> for port 26b727dd-52b4-4b34-b484-6ea3fd571c8d, please check neutron logs
>> for more information.
>>
>>
>>
>>
>>
>> Can you throw some light or give us some guidance on this as it has
>> halted the implementation of our Production Openstack Pike.
>>
>> Your support and co-operation is highly appreciated.
>>
>>
>> FYI: Controller and compute node are running CentOS7.
>>
>>
>>
>> Thanks and Regards,
>>
>> Ritesh
>>
>>
>>
>>
>>
>> On Thu, Nov 9, 2017 at 12:03 PM, Amrith Kumar 
>> wrote:
>>
>>> Sorry, I should have been more clear.
>>>
>>> You shouldn't use redstack.
>>>
>>> And you should not be using trovestack with trusty.
>>>
>>> All of the gate moved to Xenial a while back and I don't know that
>>> anyone is verifying trusty any longer. But, YMMV, set the force flag and
>>> try again if you want. I am not able to verify with Trusty, don't have a
>>> trusty env.
>>>
>>> Apologies for the back and forth. It has been a long week at summit.
>>>
>>>
>>>
>>> -amrith
>>>
>>>
>>> On Thu, Nov 9, 2017 at 1:24 AM, Ritesh Vishwakarma <
>>> ritesh.vishwaka...@indusnet.co.in> wrote:
>>>
 Hi Amrith,

 This time I followed the https://github.com/opensta
 ck/trove/tree/master/integration/ however, it still throws me the same
 error. Please find the log file attached.


 Regards,
 Ritesh

 On Wed, Nov 8, 2017 at 4:44 PM, Amrith Kumar 
 wrote:

> Please see inline below.
>
> -amrith
>
>
> On Wed, Nov 8, 2017 at 9:52 PM, Ritesh Vishwakarma <
> ritesh.vishwaka...@indusnet.co.in> wrote:
>
>>
>>
>> Hi Amrith,
>>
>>
>>
>> Please find my response to your queries below:
>>
>>
>>
>>
>>
>> 1.   What (exact) version of OpenStack are you using? Is it from
>> upstream or a vendor, if it is the latter, which vendor?
>>
>> We are using Openstack Pike installed on CentOS7.
>>
>> 2.   What database (exact version) are you trying to create an
>> image for?
>>
>> We want to build images for mysql5.7 as of now.
>>
>> 3.   What operating system (exact version) are you attempting to
>> perform this   on?
>>
>> We have tried it from CentOS7 & Ubuntu 14.04.
>>
>> 4.   What command(s) are you executing?
>>
>> I am step-by-step following the 
>> *https://github.com/openstack/trove-integration
>> * and the
>> “./redstack install” command. Also, I want to confirm that as this 

Re: [openstack-dev] [kolla] Host networking in Kolla

[Goutham Pratapa]

Hi Eduardo,


Thanks, this helps we will get back to you in case of any doubts

Thanks,
Goutham.

On Mon, Nov 13, 2017 at 6:20 PM, Eduardo Gonzalez 
wrote:

> Hi Akshay.
>
> Yes, kolla support segregate almost all traffic in different interfaces.
> By default all traffic uses network_interface, but you can specify any of
> the following variables under Network configuration section.
> https://docs.openstack.org/kolla-ansible/latest/admin/
> production-architecture-guide.html
>
> Regards
>
> On Mon, Nov 13, 2017, 1:30 PM Goutham Pratapa 
> wrote:
>
>> Hi all,
>>
>> Does OpenStack-Kolla support Host-networking (separate network for
>> management, traffic, and storage)
>> ( 
>> https://docs.openstack.org/newton/install-guide-rdo/environment-networking.html
>> )
>>
>> Any ideas ??
>>
>>
>> Thanks in advance
>>
>> --
>> Thanks !!!
>> 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 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
>
>


-- 
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

Re: [openstack-dev] [kolla] Host networking in Kolla

[Eduardo Gonzalez]

Hi Akshay.

Yes, kolla support segregate almost all traffic in different interfaces. By
default all traffic uses network_interface, but you can specify any of the
following variables under Network configuration section.
https://docs.openstack.org/kolla-ansible/latest/admin/production-architecture-guide.html

Regards

On Mon, Nov 13, 2017, 1:30 PM Goutham Pratapa 
wrote:

> Hi all,
>
> Does OpenStack-Kolla support Host-networking (separate network for
> management, traffic, and storage)
> ( 
> https://docs.openstack.org/newton/install-guide-rdo/environment-networking.html
> )
>
> Any ideas ??
>
>
> Thanks in advance
>
> --
> Thanks !!!
> 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 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] [kolla] Host networking in Kolla

[Goutham Pratapa]

Hi all,

Does OpenStack-Kolla support Host-networking (separate network for
management, traffic, and storage)
( 
https://docs.openstack.org/newton/install-guide-rdo/environment-networking.html
)

Any ideas ??


Thanks in advance

-- 
Thanks !!!
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

Re: [openstack-dev] Building Openstack Trove Images

[Ritesh Vishwakarma]

Hi Amrith,



We are trying to replicate the issue again for troubleshooting


Are there any necessary pointers that can filter out other possibilities
and help us pinpoint the issue…..like the logs and functionality of other
services, output of some commands.



I assume the issue is related to the authentication and communication
between controller and compute node as it is working fine in single node
environment.



We will share our findings with you also, so in case you require any
command outputs or other info, kindly let us know.



Thanks for your support.



Regards,

Ritesh



On Mon, Nov 13, 2017 at 4:48 PM, Amrith Kumar 
wrote:

> I would start here:
>
> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
> 054229be-3467-490d-b407-dc256a8747c8] PortBindingFailed: Binding failed
> for port 26b727dd-52b4-4b34-b484-6ea3fd571c8d, please check neutron logs
> for more information.
>
>
> -amrith
>
>
> On Mon, Nov 13, 2017 at 2:59 AM, Ritesh Vishwakarma <
> ritesh.vishwaka...@indusnet.co.in> wrote:
>
>> Hi Amirth,
>>
>>
>>
>> Many thanks for your response coz of which I was able to build a MySQL
>> image from Ubuntu Xenial.
>>
>> However, I am facing another obstacle now, we have added one compute node
>> to our Openstack controller which is showing in the openstack dashboard
>> however the when we launch any VM, the VM goes into error state. We have
>> gone through most of the things available on the internet but nothing sorts
>> it out. Below are the logs for the error:
>>
>>
>>
>> ERROR nova.compute.manager [instance: 054229be-3467-490d-b407-dc256a8747c8]
>> File "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py",
>> line 984, in _update_ports_for_instance
>>
>> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
>> 054229be-3467-490d-b407-dc256a8747c8] port_client, instance,
>> port_id, port_req_body)
>>
>> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
>> 054229be-3467-490d-b407-dc256a8747c8]   File
>> "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line
>> 445, in _update_port
>>
>> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
>> 054229be-3467-490d-b407-dc256a8747c8] _ensure_no_port_binding_failur
>> e(port)
>>
>> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
>> 054229be-3467-490d-b407-dc256a8747c8]   File
>> "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line
>> 191, in _ensure_no_port_binding_failure
>>
>> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
>> 054229be-3467-490d-b407-dc256a8747c8] raise
>> exception.PortBindingFailed(port_id=port['id'])
>>
>> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
>> 054229be-3467-490d-b407-dc256a8747c8] PortBindingFailed: Binding failed
>> for port 26b727dd-52b4-4b34-b484-6ea3fd571c8d, please check neutron logs
>> for more information.
>>
>>
>>
>>
>>
>> Can you throw some light or give us some guidance on this as it has
>> halted the implementation of our Production Openstack Pike.
>>
>> Your support and co-operation is highly appreciated.
>>
>>
>> FYI: Controller and compute node are running CentOS7.
>>
>>
>>
>> Thanks and Regards,
>>
>> Ritesh
>>
>>
>>
>>
>>
>> On Thu, Nov 9, 2017 at 12:03 PM, Amrith Kumar 
>> wrote:
>>
>>> Sorry, I should have been more clear.
>>>
>>> You shouldn't use redstack.
>>>
>>> And you should not be using trovestack with trusty.
>>>
>>> All of the gate moved to Xenial a while back and I don't know that
>>> anyone is verifying trusty any longer. But, YMMV, set the force flag and
>>> try again if you want. I am not able to verify with Trusty, don't have a
>>> trusty env.
>>>
>>> Apologies for the back and forth. It has been a long week at summit.
>>>
>>>
>>>
>>> -amrith
>>>
>>>
>>> On Thu, Nov 9, 2017 at 1:24 AM, Ritesh Vishwakarma <
>>> ritesh.vishwaka...@indusnet.co.in> wrote:
>>>
 Hi Amrith,

 This time I followed the https://github.com/opensta
 ck/trove/tree/master/integration/ however, it still throws me the same
 error. Please find the log file attached.


 Regards,
 Ritesh

 On Wed, Nov 8, 2017 at 4:44 PM, Amrith Kumar 
 wrote:

> Please see inline below.
>
> -amrith
>
>
> On Wed, Nov 8, 2017 at 9:52 PM, Ritesh Vishwakarma <
> ritesh.vishwaka...@indusnet.co.in> wrote:
>
>>
>>
>> Hi Amrith,
>>
>>
>>
>> Please find my response to your queries below:
>>
>>
>>
>>
>>
>> 1.   What (exact) version of OpenStack are you using? Is it from
>> upstream or a vendor, if it is the latter, which vendor?
>>
>> We are using Openstack Pike installed on CentOS7.
>>
>> 2.   What database (exact version) are you trying to create an
>> image for?
>>
>> We want to build images for mysql5.7 as of now.

[openstack-dev] [glance] Does glance_store swift driver support range requests ?

[Matt Keenan]

Hi,

 Just configured devstack on Fedora 26, and by default glance_store 
uses swift for image storage. When attempting to get a specific range 
from a glance stored image, it's reporting range requests are not 
supported e.g.:


    $ curl -i -X GET -r 0-32 -H "X-Auth-Token: $auth_token" 
http://10.169.104.255/image/v2/images/29b7aa

    5e-3ec2-49b5-ab6b-d6cc5099f46c/file
    HTTP/1.1 400 Bad Request
    Date: Mon, 13 Nov 2017 10:43:23 GMT
    Server: Apache/2.4.27 (Fedora) OpenSSL/1.1.0f-fips mod_wsgi/4.5.15 
Python/2.7

    Content-Length: 205
    Content-Type: text/html; charset=UTF-8
    x-openstack-request-id: req-5ed2239f-165b-406f-969b-5cc4ab8c632d
    Connection: close

    
 
  400 Bad Request
 
 
  400 Bad Request
  Getting images randomly from this store is not supported. Offset: 
0, length: 33

 

Upon investigation, glance-api log is emitting:

    Nov 13 10:45:31 devstack@g-api.service[22783]: #033[01;31mERROR 
glance.location [#033[01;36mNone 
req-ad6da3f0-ead1-486a-a873-d301f02b0888 #033[00;36mdemo 
demo#033[01;31m] #033[01;35m#033[0│·1;31mGlance 
tried all active locations to get data for image 
29b7aa5e-3ec2-49b5-ab6b-d6cc5099f46c but all have failed.#033[00m: 
StoreRandomGetNotSupported: Getting images randomly from this store is 
notMDg4OCAjMDMzWzAwOzM2bW supported. Offset: 0, length: 33


The exception StoreRandomGetNotSupported is emitted by glance_store from 
glance_store/capabilities.py:


    op_exec_map = {
    'get': (exceptions.StoreRandomGetNotSupported
    if kwargs.get('offset') or kwargs.get('chunk_size') else
    exceptions.StoreGetNotSupported),
    'add': exceptions.StoreAddDisabled,
    'delete': exceptions.StoreDeleteNotSupported}

Looking at _driver/swift/store.py I think range requests are supported, 
it I've be unsuccessful in configuring it.


Does the glance_store swift driver support range requests ?

Can it be configured within a conf file, by somehow adding a capability ?

thanks

Matt

--


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Notification update week 46

[Balazs Gibizer]

Hi,

Here is the status update / focus settings mail for w46

Bugs

[Undecided] https://bugs.launchpad.net/nova/+bug/1535254 illustration
of 'notify_on_state_change' are different from implementation
As the behavior is unchanged in the last 5 years a patch is proposed to
update the documentation to reflect this long standing behavior.
Matt's comments needs to be addressed on the patch.

[Undecided] https://bugs.launchpad.net/nova/+bug/1728884 A missing 
versioned notification sample
Fix has been proposed, needs a second +2: 
https://review.openstack.org/#/c/516582/



Versioned notification transformation
-
Live migration abort patch has been merged last week but the pre 
livemigration notification patch unovered a bug in that patch later so 
there will be some fix proposed soon. This means the livemigration 
series ca
nnot move forward until that fix. So besides that fix we the review 
focus should be on another patches:

* https://review.openstack.org/#/c/410297 Transform missing delete
notifications
* https://review.openstack.org/#/c/476459 Send soft_delete from context
manager
* https://review.openstack.org/#/c/403660 Transform instance.exists 
notification



Service create and destroy notifications

https://blueprints.launchpad.net/nova/+spec/service-create-destroy-notification
https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/service-create-destroy-notification.html

Still waiting for the implementation to be proposed. I pinged the spec 
author about the coming milestone 2 deadline.



Factor out duplicated notification sample
--
https://review.openstack.org/#/q/topic:refactor-notification-samples

The first set of patches have been merged. \o/ Now every new 
notification transformation needs to use the common json fragments when 
adding new sample files. I will continue proposing de-duplication 
patches for the already merged sample files but If somebody wants to 
help with this easy work then just ping me on IRC and we can distribute 
the work.


Weekly meeting
--
Next subteam meeting will be held on 14th of November, Tuesday 17:00 
UTC on openstack-meeting-4.

https://www.timeanddate.com/worldclock/fixedtime.html?iso=20171114T17


Cheers,
gibi




__
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] Building Openstack Trove Images

[Amrith Kumar]

I would start here:

2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
054229be-3467-490d-b407-dc256a8747c8] PortBindingFailed: Binding failed for
port 26b727dd-52b4-4b34-b484-6ea3fd571c8d, please check neutron logs for
more information.


-amrith


On Mon, Nov 13, 2017 at 2:59 AM, Ritesh Vishwakarma <
ritesh.vishwaka...@indusnet.co.in> wrote:

> Hi Amirth,
>
>
>
> Many thanks for your response coz of which I was able to build a MySQL
> image from Ubuntu Xenial.
>
> However, I am facing another obstacle now, we have added one compute node
> to our Openstack controller which is showing in the openstack dashboard
> however the when we launch any VM, the VM goes into error state. We have
> gone through most of the things available on the internet but nothing sorts
> it out. Below are the logs for the error:
>
>
>
> ERROR nova.compute.manager [instance: 054229be-3467-490d-b407-dc256a8747c8]
> File "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py",
> line 984, in _update_ports_for_instance
>
> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
> 054229be-3467-490d-b407-dc256a8747c8] port_client, instance, port_id,
> port_req_body)
>
> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
> 054229be-3467-490d-b407-dc256a8747c8]   File "/usr/lib/python2.7/site-
> packages/nova/network/neutronv2/api.py", line 445, in _update_port
>
> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
> 054229be-3467-490d-b407-dc256a8747c8] _ensure_no_port_binding_
> failure(port)
>
> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
> 054229be-3467-490d-b407-dc256a8747c8]   File "/usr/lib/python2.7/site-
> packages/nova/network/neutronv2/api.py", line 191, in
> _ensure_no_port_binding_failure
>
> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
> 054229be-3467-490d-b407-dc256a8747c8] raise
> exception.PortBindingFailed(port_id=port['id'])
>
> 2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
> 054229be-3467-490d-b407-dc256a8747c8] PortBindingFailed: Binding failed
> for port 26b727dd-52b4-4b34-b484-6ea3fd571c8d, please check neutron logs
> for more information.
>
>
>
>
>
> Can you throw some light or give us some guidance on this as it has halted
> the implementation of our Production Openstack Pike.
>
> Your support and co-operation is highly appreciated.
>
>
> FYI: Controller and compute node are running CentOS7.
>
>
>
> Thanks and Regards,
>
> Ritesh
>
>
>
>
>
> On Thu, Nov 9, 2017 at 12:03 PM, Amrith Kumar 
> wrote:
>
>> Sorry, I should have been more clear.
>>
>> You shouldn't use redstack.
>>
>> And you should not be using trovestack with trusty.
>>
>> All of the gate moved to Xenial a while back and I don't know that anyone
>> is verifying trusty any longer. But, YMMV, set the force flag and try again
>> if you want. I am not able to verify with Trusty, don't have a trusty env.
>>
>> Apologies for the back and forth. It has been a long week at summit.
>>
>>
>>
>> -amrith
>>
>>
>> On Thu, Nov 9, 2017 at 1:24 AM, Ritesh Vishwakarma <
>> ritesh.vishwaka...@indusnet.co.in> wrote:
>>
>>> Hi Amrith,
>>>
>>> This time I followed the https://github.com/opensta
>>> ck/trove/tree/master/integration/ however, it still throws me the same
>>> error. Please find the log file attached.
>>>
>>>
>>> Regards,
>>> Ritesh
>>>
>>> On Wed, Nov 8, 2017 at 4:44 PM, Amrith Kumar 
>>> wrote:
>>>
 Please see inline below.

 -amrith


 On Wed, Nov 8, 2017 at 9:52 PM, Ritesh Vishwakarma <
 ritesh.vishwaka...@indusnet.co.in> wrote:

>
>
> Hi Amrith,
>
>
>
> Please find my response to your queries below:
>
>
>
>
>
> 1.   What (exact) version of OpenStack are you using? Is it from
> upstream or a vendor, if it is the latter, which vendor?
>
> We are using Openstack Pike installed on CentOS7.
>
> 2.   What database (exact version) are you trying to create an
> image for?
>
> We want to build images for mysql5.7 as of now.
>
> 3.   What operating system (exact version) are you attempting to
> perform this   on?
>
> We have tried it from CentOS7 & Ubuntu 14.04.
>
> 4.   What command(s) are you executing?
>
> I am step-by-step following the 
> *https://github.com/openstack/trove-integration
> * and the “./redstack
> install” command. Also, I want to confirm that as this code installs its
> own devstack cloud, will we be able to use the images created using
> it in our Openstack Pike trove environment.
>


 ​The Trove Integration repository is dead and gone for a couple of
 releases now and you should be using the stuff from the trove repository as
 the documentation indicates.​



> 5.   What exact 

Re: [openstack-dev] [infra] support graphviz in document publishing

[Sean McGinnis]

On Mon, Nov 13, 2017 at 09:16:59AM +, Yujun Zhang (ZTE) wrote:
> Hi, all
> 
> Sometimes a picture worths thousands word. I wonder if it is possible to
> support graphviz in https://docs.openstack.org/
> 
> What I expect is to include a dot file and render it as a picture in HTML
> output. The syntax is simple
> 
> .. graphviz:: aggregate-equivalent-alarms.files/example.dot
> 
> And should be supported by sphinx graphviz plugin[2]
> 

Hey Yujun,

The graphviz directive is currently supported [0]. Though the control over the
output leaves a little to be desired [1].

I'm not sure about referencing dotfiles, but most needs are fairly small and
can be done inline like the example above.

[0] 
https://git.openstack.org/cgit/openstack/cinder/tree/doc/source/contributor/api_microversion_dev.rst#n81
[1] 
https://docs.openstack.org/cinder/latest/contributor/api_microversion_dev.html

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [faas] [qinling] demo video

[Lingxian Kong]

Hi, all

For those who are interested in Qinling project (and its integration with
other OpenStack services), I recorded the demo in my summit
presentation[1], which is very similar to the use case of integration
between AWS Lambda and S3.

https://youtu.be/K2SiMZllN_A

If you have any questions about Qinling, feel free to ask in
#openstack-qinling irc channel, my irc name is kong. I am always online
from UTC 20:30 to UTC 04:00, but you can leave messages to me anyway.

[1]:
https://www.openstack.org/videos/sydney-2017/make-your-application-serverless

Cheers,
Lingxian Kong (Larry)
__
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] [infra] support graphviz in document publishing

[Andreas Jaeger]

On 2017-11-13 10:16,  Yujun Zhang (ZTE)  wrote:
> Hi, all
> 
> Sometimes a picture worths thousands word. I wonder if it is possible to
> support graphviz in https://docs.openstack.org/
> 
> What I expect is to include a dot file and render it as a picture in
> HTML output. The syntax is simple
> 
> .. graphviz:: aggregate-equivalent-alarms.files/example.dot
> 
> And should be supported by sphinx graphviz plugin[2]
> 
> See full example[1]. Currently I render the picture offline and include
> it manually in the document. It would be much more convenient for
> developer if the extension is added to document build job.

You can easily include them for any repository - add the python
requirements to test-requirments and add the binary requirements to
bindep.txt - as explained in
https://docs.openstack.org/infra/manual/drivers.html#package-requirements

Andreas

> [1]:
> https://review.openstack.org/#/c/518196/5/proposals/aggregate-equivalent-alarms.rst
> [2]: http://www.sphinx-doc.org/en/stable/ext/graphviz.html
> 
> -- 
> Yujun Zhang
> 
> 
> __
> 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
> 


-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] [infra] support graphviz in document publishing

[Yujun Zhang (ZTE)]

Hi, all

Sometimes a picture worths thousands word. I wonder if it is possible to
support graphviz in https://docs.openstack.org/

What I expect is to include a dot file and render it as a picture in HTML
output. The syntax is simple

.. graphviz:: aggregate-equivalent-alarms.files/example.dot

And should be supported by sphinx graphviz plugin[2]

See full example[1]. Currently I render the picture offline and include it
manually in the document. It would be much more convenient for developer if
the extension is added to document build job.

[1]:
https://review.openstack.org/#/c/518196/5/proposals/aggregate-equivalent-alarms.rst
[2]: http://www.sphinx-doc.org/en/stable/ext/graphviz.html

-- 
Yujun Zhang
__
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] [Openstack-operators] Upstream LTS Releases

[Dmitry Tantsur]

On 11/10/2017 11:51 PM, John Dickinson wrote:

On 7 Nov 2017, at 15:28, Erik McCormick wrote:

Hello Ops folks,

This morning at the Sydney Summit we had a very well attended and very
productive session about how to go about keeping a selection of past
releases available and maintained for a longer period of time (LTS).

There was agreement in the room that this could be accomplished by
moving the responsibility for those releases from the Stable Branch
team down to those who are already creating and testing patches for
old releases: The distros, deployers, and operators.

The concept, in general, is to create a new set of cores from these
groups, and use 3rd party CI to validate patches. There are lots of
details to be worked out yet, but our amazing UC (User Committee) will
be begin working out the details.

Please take a look at the Etherpad from the session if you'd like to
see the details. More importantly, if you would like to contribute to
this effort, please add your name to the list starting on line 133.

https://etherpad.openstack.org/p/SYD-forum-upstream-lts-releases

Thanks to everyone who participated!

Cheers,
Erik

___
OpenStack-operators mailing list
openstack-operat...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

I'm not a fan of the current proposal. I feel like the discussion jumped into a 
policy/procedure solution without getting much more feedback from operators. The 
room heard "ops want LTS" and we now have a new governance model to work out.


What I heard from ops in the room is that they want (to start) one release a 
year who's branch isn't deleted after a year. What if that's exactly what we 
did? I propose that OpenStack only do one release a year instead of two. We 
still keep N-2 stable releases around. We still do backports to all open stable 
branches. We still do all the things we're doing now, we just do it once a year 
instead of twice.


The problem is around making breaking changes, e.g. removing configuration 
options. Currently we can do it, roughly speaking, up to 6 months after 
deprecation. Your suggestions bumps it to up to 12 months, if we want to support 
the same deprecation model.




Looking at current deliverables in the openstack releases repo, most (by nearly 
a factor of 2x) are using "cycle-with-intermediary".


|john@europa:~/Documents/openstack_releases/deliverables/pike(master)$ grep 
release-model * | cut -d ':' -f 2- | sort | uniq -c 44 release-model: 
cycle-trailing 147 release-model: cycle-with-intermediary 37 release-model: 
cycle-with-milestones 2 release-model: untagged |


Any deliverable that using this model is already successfully dealing with 
skip-level upgrades. Skip-level upgrades are already identified as needed and 
prioritized functionality in projects that don't yet support them. Let's keep 
working on getting that functionality supported across all OpenStack 
deliverables. Let's move to one LTS release a year. And let's get all project 
deliverables to start using cycle-with-intermediary releases. >

--John



__
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] Building Openstack Trove Images

[Ritesh Vishwakarma]

Hi Amirth,



Many thanks for your response coz of which I was able to build a MySQL
image from Ubuntu Xenial.

However, I am facing another obstacle now, we have added one compute node
to our Openstack controller which is showing in the openstack dashboard
however the when we launch any VM, the VM goes into error state. We have
gone through most of the things available on the internet but nothing sorts
it out. Below are the logs for the error:



ERROR nova.compute.manager [instance:
054229be-3467-490d-b407-dc256a8747c8]   File
"/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 984,
in _update_ports_for_instance

2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
054229be-3467-490d-b407-dc256a8747c8] port_client, instance, port_id,
port_req_body)

2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
054229be-3467-490d-b407-dc256a8747c8]   File
"/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 445,
in _update_port

2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
054229be-3467-490d-b407-dc256a8747c8]
_ensure_no_port_binding_failure(port)

2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
054229be-3467-490d-b407-dc256a8747c8]   File
"/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 191,
in _ensure_no_port_binding_failure

2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
054229be-3467-490d-b407-dc256a8747c8] raise
exception.PortBindingFailed(port_id=port['id'])

2017-11-12 02:58:57.551 2372 ERROR nova.compute.manager [instance:
054229be-3467-490d-b407-dc256a8747c8] PortBindingFailed: Binding failed for
port 26b727dd-52b4-4b34-b484-6ea3fd571c8d, please check neutron logs for
more information.





Can you throw some light or give us some guidance on this as it has halted
the implementation of our Production Openstack Pike.

Your support and co-operation is highly appreciated.


FYI: Controller and compute node are running CentOS7.



Thanks and Regards,

Ritesh





On Thu, Nov 9, 2017 at 12:03 PM, Amrith Kumar 
wrote:

> Sorry, I should have been more clear.
>
> You shouldn't use redstack.
>
> And you should not be using trovestack with trusty.
>
> All of the gate moved to Xenial a while back and I don't know that anyone
> is verifying trusty any longer. But, YMMV, set the force flag and try again
> if you want. I am not able to verify with Trusty, don't have a trusty env.
>
> Apologies for the back and forth. It has been a long week at summit.
>
>
>
> -amrith
>
>
> On Thu, Nov 9, 2017 at 1:24 AM, Ritesh Vishwakarma <
> ritesh.vishwaka...@indusnet.co.in> wrote:
>
>> Hi Amrith,
>>
>> This time I followed the https://github.com/opensta
>> ck/trove/tree/master/integration/ however, it still throws me the same
>> error. Please find the log file attached.
>>
>>
>> Regards,
>> Ritesh
>>
>> On Wed, Nov 8, 2017 at 4:44 PM, Amrith Kumar 
>> wrote:
>>
>>> Please see inline below.
>>>
>>> -amrith
>>>
>>>
>>> On Wed, Nov 8, 2017 at 9:52 PM, Ritesh Vishwakarma <
>>> ritesh.vishwaka...@indusnet.co.in> wrote:
>>>


 Hi Amrith,



 Please find my response to your queries below:





 1.   What (exact) version of OpenStack are you using? Is it from
 upstream or a vendor, if it is the latter, which vendor?

 We are using Openstack Pike installed on CentOS7.

 2.   What database (exact version) are you trying to create an
 image for?

 We want to build images for mysql5.7 as of now.

 3.   What operating system (exact version) are you attempting to
 perform this   on?

 We have tried it from CentOS7 & Ubuntu 14.04.

 4.   What command(s) are you executing?

 I am step-by-step following the 
 *https://github.com/openstack/trove-integration
 * and the “./redstack
 install” command. Also, I want to confirm that as this code installs its
 own devstack cloud, will we be able to use the images created using it
 in our Openstack Pike trove environment.

>>>
>>>
>>> ​The Trove Integration repository is dead and gone for a couple of
>>> releases now and you should be using the stuff from the trove repository as
>>> the documentation indicates.​
>>>
>>>
>>>
 5.   What exact error(s) are you receiving?

 I have attached the logs.

>>>
>>>
>>> ​The end of your error log indicates
>>>
>>> +./stack.sh:main:225   echo 'WARNING: this script
>>> has not been tested on trusty'
>>> WARNING: this script has not been tested on trusty
>>> +./stack.sh:main:226   [[ '' != \y\e\s ]]
>>> +./stack.sh:main:227   die 227 'If you wish to run
>>> this script anyway run with FORCE=yes'
>>> +functions-common:die:187  local exitcode=0
>>> +functions-common:die:188 

Re: [openstack-dev] [octavia] how to recreate amphora instances

[mihaela.balas]

Hi Michael,

Thank you for the detailed explanation. I was in the worst scenario where the 
database entries were purged and I had to manually re-create the DB entries and 
the ports. I successfully managed to insert the lines in the database and the 
amphoras were created.

Thanks a lot for the hints. I also increased the DB cleanup interval to 1 week.

Mihaela

-Original Message-
From: Michael Johnson [mailto:johnso...@gmail.com] 
Sent: Friday, November 10, 2017 3:31 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [octavia] how to recreate amphora instances

I can give it a go, there are also logs of our conversation on evesdrop here: 
http://eavesdrop.openstack.org/irclogs/%23openstack-lbaas/%23openstack-lbaas.2017-11-02.log.html#t2017-11-02T11:07:45

Short background, they had an infrastructure issue where networking was out.  
This caused the load balancer amphora to be detected as failed and started the 
failover process which rebuilds the amphora, however this process also failed 
due to the wider infrastructure issues (Note, this is what I remember from the 
conversation. Correct the background if I am wrong). At this point the load 
balancers would be in a provisioning status of "ERROR", the amphora instances 
were likely deleted (depending on where the infrastructure issue impacted the 
failover process), and the amphora db records would be in the "DELETED" state.  
To make their situation worse, the DB cleanup cycle of the housekeeping process 
was set low (default is a week) and the amphora records were purged. This meant 
the customer data for the VIP address/ports was also purged.

Recovery:
If the database records were not purged, after the infrastructure issues are 
resolved, you can simply go into the octavia database and
issue: update load_balancer set provisioning_status="ACTIVE" where 
provisioning_status = "ERROR"; This will restart the health manager expecting 
the amphora to report health heartbeats and the failover process with start 
again rebuilding the amphora.  We have also recently added an admin API to 
trigger a failover manually 
(https://developer.openstack.org/api-ref/load-balancer/v2/index.html#failover-a-load-balancer).

If your amphora records have been purged, you are in some pain (don't do this). 
 This means that the VIP address and neutron port information for that VIP 
address are not available for the failover process to rebuild.  In this case, 
before you start the above process you will need to recreate the amphora 
records from your logs, either adding the port information if the ports are 
still live in neutron, or creating replacement ports.

Michael

On Wed, Nov 8, 2017 at 2:07 AM,   wrote:
> I am also interested how to fix this. If you can describe shortly the 
> procedure.
>
> Thanks,
> Mihaela
>
> -Original Message-
> From: Michael Johnson [mailto:johnso...@gmail.com]
> Sent: Monday, November 06, 2017 6:54 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [octavia] how to recreate amphora 
> instances
>
> I think we helped you get going again in the IRC channel.  Please ping us 
> again in the IRC channel if you need more assistance.
>
> Michael
>
> On Thu, Nov 2, 2017 at 4:42 AM, Kim-Norman Sahm  
> wrote:
>> Hi,
>>
>> after a rabbitmq problem octavia has removed all amphora instances.
>> the loadbalancers are in provisioning_status "ACTIVE"
>>
>> ~$ neutron lbaas-loadbalancer-list
>> neutron CLI is deprecated and will be removed in the future. Use 
>> openstack CLI instead.
>> | 07b41df6-bb75-4502-975a-20140b0832dd | Load Balancer
>> 4   | 260b0c452e214accaf6cc0e98fb10fc0 |
>> 192.168.1.18   | ACTIVE  | octavia  |
>> | 25664be7-15cb-426b-ad09-6102afb62b14 | Load Balancer
>> 2   | 260b0c452e214accaf6cc0e98fb10fc0 |
>> 192.168.1.7| ACTIVE  | octavia  |
>> | 927eb754-7c52-4060-b130-1f5e82d92555 | Load Balancer
>> 6   | 260b0c452e214accaf6cc0e98fb10fc0 |
>> 192.168.1.17   | ACTIVE  | octavia  |
>> | b4d93c68-89d6-4e4f-b06c-117d4ea933fa | Load Balancer
>> 5   | 260b0c452e214accaf6cc0e98fb10fc0 |
>> 192.168.1.24   | ACTIVE  | octavia  |
>> | d7699f8d-2106-42d6-8797-5feb72de6e2e | Load Balancer
>> 1   | 260b0c452e214accaf6cc0e98fb10fc0 |
>> 192.168.1.5| ACTIVE  | octavia  |
>> | dd6114ae-21e9-41bd-b155-325287aed420 | Load Balancer
>> 3   | 260b0c452e214accaf6cc0e98fb10fc0 |
>> 192.168.1.23   | ACTIVE  | octavia  |
>>
>> How can we trigger octavia to rebuild the amphore instances?
>> I've tried to restart the octavia services but it didn't solved the 
>> problem.
>>
>> Best regards
>> Kim
>>
>>
>> Kim-Norman Sahm
>> Cloud & Infrastructure(OCI)
>> noris network AG
>> Thomas-Mann-Straße 16-20
>> 90471 Nürnberg
>> Deutschland