date:20180615

Excerpts from Eric Fried's message of 2018-06-15 18:09:49 -0500:
> Doug-
> 
> > The lower constraints tests only look at files in the same repo.
> > The minimum versions of dependencies set in requirements.txt,
> > test-requirements.txt, etc. need to match the values in
> > lower-constraints.txt.
> > 
> > In this case, the more detailed error message is a few lines above the
> > error quoted by Chen CH Ji. The detail say "Requirement for package
> > retrying has no lower bound" which means that there is a line in
> > requirements.txt indicating a dependency on "retrying" but without
> > specifying a minimum version. That is the problem.
> 
> The patch didn't change the retrying constraint in requirements.txt [1];
> why isn't this same failure affecting every other patch in nova?
> 
> [1] https://review.openstack.org/#/c/523387/51/requirements.txt@65
> 
> -efried
> 

Earlier this cycle I updated the requirements check job to verify
that all of the settings are correct any time any changes to the
dependency lists are made. We used to only look at the line being
changed, but that allowed incorrect settings to stay in place for
a long time so we weren't actually testing with good settings. We
still only run that job when the dependency list is modified in
some way.

Earlier this week, Matt Thode updated the job to be more strict and
to require that all dependencies have a minimum version specified
[2]. We did this because some project teams thought that after we
dropped the minimums from the global-requirements.txt list they
were supposed to (or allowed to) drop them from their project
dependency lists, too.

My guess is that this dependency in nova never had a lower bound and
that this is the first patch to touch the dependency list, so now it's
being blocked on the fact that the list has a validation error.

I recommend using a separate patch to fix the minimum version of
retrying and then rebasing 523387 on top of the new patch.

Doug

[2] https://review.openstack.org/#/c/574367/

__
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] [requirements][nova] weird error on 'Validating lower constraints of test-requirements.txt'

2018-06-15 Thread Balázs Gibizer



On Fri, Jun 15, 2018 at 11:36 AM, Chen CH Ji  
wrote:
on patch [1] , PS 50 and PS51 just a minor rebase but PS51 start to 
fail on requirements-check with following error in [2]


Validating lower constraints of test-requirements.txt
*** Incompatible requirement found!
*** See http://docs.openstack.org/developer/requirements

but it doesn't provide enough info to know what's wrong , and because 
I didn't make too much change , curious on why
the job failed... can anyone provide any hint on what happened there? 
thanks


[1]https://review.openstack.org/#/c/523387
[2]http://logs.openstack.org/87/523387/51/check/requirements-check/3598ba0/job-output.txt.gz



Looking at your change and the state of the global requirements repo I 
see the following contradiction 
https://github.com/openstack/requirements/blob/a07ef1c282a37a4bcc93166ddf4cdc97f7626d5d/lower-constraints.txt#L151 
says zVMCloudConnector===0.3.2
while 
https://review.openstack.org/#/c/523387/51/lower-constraints.txt@173 
says zVMCloudConnector==1.1.1


Based on the history of the lower-constraints.txt in the global repo 
you have to manually bump the lower constraint there as well 
https://github.com/openstack/requirements/commits/master/lower-constraints.txt


Cheers,
gibi


Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian 
District, Beijing 100193, PRC



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

Re: [openstack-dev] [nova] increasing the number of allowed volumes attached per instance > 26

2018-06-15 Thread Kashyap Chamarthy

On Mon, Jun 11, 2018 at 10:14:33AM -0500, Eric Fried wrote:
> I thought we were leaning toward the option where nova itself doesn't
> impose a limit, but lets the virt driver decide.

Yeah, I agree with that, if we can't arrive at a sensible limit for
Nova, after testing with all drivers that matter (which I doubt will
happen anytime soon).

[...]

-- 
/kashyap

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

Re: [openstack-dev] [neutron] Question on the OVS configuration

Apologize for having sent this question to a dev mailing list first! But I 
humbly request to continue the discussion here.


My VM is connect to a private network under demo project, here is the info of 
the network:

$ openstack network show 64f4f4dc-a851-486a-8789-43b816d9bf3d
+---++
| Field | Value 
 |
+---++
| admin_state_up| UP
 |
| availability_zone_hints   |   
 |
| availability_zones| nova  
 |
| created_at| 2018-06-15T04:26:18Z  
 |
| description   |   
 |
| dns_domain| None  
 |
| id| 64f4f4dc-a851-486a-8789-43b816d9bf3d  
 |
| ipv4_address_scope| None  
 |
| ipv6_address_scope| None  
 |
| is_default| None  
 |
| is_vlan_transparent   | None  
 |
| mtu   | 1450  
 |
| name  | private   
 |
| port_security_enabled | True  
 |
| project_id| e202899d90ba449d880be42f19cd6a55  
 |
| provider:network_type | vxlan 
 |
| provider:physical_network | None  
 |
| provider:segmentation_id  | 72
 |
| qos_policy_id | None  
 |
| revision_number   | 4 
 |
| router:external   | Internal  
 |
| segments  | None  
 |
| shared| False 
 |
| status| ACTIVE
 |
| subnets   | 18a0847e-b733-4ec2-9e25-d7d630a1af2f, 
91e91bab-7405-4717-97cd-4ca2cb11589d |
| tags  |   
 |
| updated_at| 2018-06-15T04:26:23Z  
 |
+---++



And below is the full output of ovs bridges.

$ sudo ovs-vsctl show
0ee72d8a-65bc-4c82-884a-61b0e86b9893
Manager "ptcp:6640:127.0.0.1"
is_connected: true
Bridge br-int
Controller "tcp:127.0.0.1:6633"
is_connected: true
fail_mode: secure
Port "qvo97604b93-55"
tag: 1
Interface "qvo97604b93-55"
Port int-br-ex
Interface int-br-ex
type: patch
options: {peer=phy-br-ex}
Port "qr-c3f198ac-0b"
tag: 1
Interface "qr-c3f198ac-0b"
type: internal
Port "sg-8868b1a8-69"
tag: 1
Interface "sg-8868b1a8-69"
type: internal
Port br-int
Interface br-int
type: internal
Port "qvo6f012656-74"
tag: 1
Interface "qvo6f012656-74"
Port "fg-c4e5dcbc-a3"
tag: 2
Interface "fg-c4e5dcbc-a3"
type: internal
Port "tap10dc7b3e-a7"
tag: 1
Interface "tap10dc7b3e-a7"
type: internal
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Port "qg-4014b9e8-ce"
tag: 2
Interface "qg-4014b9e8-ce"

[openstack-dev] [requirements][nova] weird error on 'Validating lower constraints of test-requirements.txt'

2018-06-15 Thread Chen CH Ji


on patch [1] , PS 50 and PS51 just a minor rebase but PS51 start to fail on
requirements-check with following error in [2]

Validating lower constraints of test-requirements.txt
*** Incompatible requirement found!
*** See http://docs.openstack.org/developer/requirements

but it doesn't provide enough info to know what's wrong , and because I
didn't make too much change , curious on why
the job failed... can anyone provide any hint on what happened there?
thanks

[1]https://review.openstack.org/#/c/523387
[2]
http://logs.openstack.org/87/523387/51/check/requirements-check/3598ba0/job-output.txt.gz

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] review runways check-in and feedback

2018-06-15 Thread Balázs Gibizer

On Wed, Jun 13, 2018 at 10:33 PM, melanie witt
wrote:

Howdy everyone,

We've been experimenting with a new process this cycle, Review
Runways [1] and we're about at the middle of the cycle now as we had
the r-2 milestone last week June 7.

I wanted to start a thread and gather thoughts and feedback from the
nova community about how they think runways have been working or not
working and lend any suggestions to change or improve as we continue
on in the rocky cycle.

We decided to try the runways process to increase the chances of core
reviewers converging on the same changes and thus increasing reviews
and merges on approved blueprint work. As of today, we have 69
blueprints approved and 28 blueprints completed, we just passed r-2
June 7 and r-3 is July 26 and rc1 is August 9 [2].

Do people feel like they've been receiving more review on their
blueprints? Does it seem like we're completing more blueprints
earlier? Is there feedback or suggestions for change that you can
share?

Looking at the Queens burndown chart from Matt [3] we had 11 completed
bps at Queens milestone 2. So having 28 completed bps at R-2 means a
really nice improvement on our bp completion rate. I think the runaways
process contributed to this improvement.

Did runaway solve the problem that not every equally ready patch gets
equal attention from reviewers? Clearly not. But I don't think this
would be a realistic goal for runaways.

I suggest that in the future we continue the runaway process but we
also revive the priority setting process. Before runaways we had 3-4
bps agreed as priority work for a given cycle. I think we had this 3-4
bps in our head for Rocky as well we just did not write them down. I
feel this causes misunderstanding about priories, like:
a) does reviewer X has the same 3-4 bps in her/his head with priority
as in mine?
b) does something that I think part of the 3-4 priority bps has more
importance than what is in a runaway slot?

Of course when I select what to review priority is only a single factor
and there are others, like:
* Do I have knowledge about the feature? (Did I review the related
spec? Do I have knowledge in the domain or in the impacted code path?)
* Is it seems easy to review? (e.g. low complexity feature, small
patches, well written commit message)
* Is it something that feels important to me, regardless of priority
set by the community. (e.g. Do I get frequent company internal
questions about the feature? Do I have another feature that depends on
this feature as prerequisite work?)
So during the cycle it happened that I selected patches to review even
if they wasn't in a runaway slot and ignored some patches from the
runaway slots.

Cheers,
gibi

[3]
https://docs.google.com/spreadsheets/d/e/2PACX-1vRh5glbJ44-Ru2iARidNRa7uFfn2yjiRPjHIEQOc3Fjp5YDAlcMmXkYAEFW0WNhALl010T4rzyChuO9/pubhtml?gid=128173249=true

Thanks all,
-melanie

[1] https://etherpad.openstack.org/p/nova-runways-rocky
[2] https://wiki.openstack.org/wiki/Nova/Rocky_Release_Schedule

__
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] [requirements][nova] weird error on 'Validating lower constraints of test-requirements.txt'

Excerpts from Balázs Gibizer's message of 2018-06-15 13:34:09 +0200:
> 
> On Fri, Jun 15, 2018 at 11:36 AM, Chen CH Ji  
> wrote:
> > on patch [1] , PS 50 and PS51 just a minor rebase but PS51 start to 
> > fail on requirements-check with following error in [2]
> > 
> > Validating lower constraints of test-requirements.txt
> > *** Incompatible requirement found!
> > *** See http://docs.openstack.org/developer/requirements
> > 
> > but it doesn't provide enough info to know what's wrong , and because 
> > I didn't make too much change , curious on why
> > the job failed... can anyone provide any hint on what happened there? 
> > thanks
> > 
> > [1]https://review.openstack.org/#/c/523387
> > [2]http://logs.openstack.org/87/523387/51/check/requirements-check/3598ba0/job-output.txt.gz
> > 
> 
> Looking at your change and the state of the global requirements repo I 
> see the following contradiction 
> https://github.com/openstack/requirements/blob/a07ef1c282a37a4bcc93166ddf4cdc97f7626d5d/lower-constraints.txt#L151
>  
> says zVMCloudConnector===0.3.2
> while 
> https://review.openstack.org/#/c/523387/51/lower-constraints.txt@173 
> says zVMCloudConnector==1.1.1
> 
> Based on the history of the lower-constraints.txt in the global repo 
> you have to manually bump the lower constraint there as well 
> https://github.com/openstack/requirements/commits/master/lower-constraints.txt

No, that file is not used and does not need to be changed.

The lower constraints tests only look at files in the same repo.
The minimum versions of dependencies set in requirements.txt,
test-requirements.txt, etc. need to match the values in
lower-constraints.txt.

In this case, the more detailed error message is a few lines above the
error quoted by Chen CH Ji. The detail say "Requirement for package
retrying has no lower bound" which means that there is a line in
requirements.txt indicating a dependency on "retrying" but without
specifying a minimum version. That is the problem.

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] [neutron] Question on the OVS configuration

Please send info about network to which You vm is connected and config of all 
bridges from ovs also.

> Wiadomość napisana przez dave.c...@dell.com w dniu 15.06.2018, o godz. 11:18:
> 
> Thanks Slawomir for your reply, so what's the right configuration if I want 
> my VM could be able to access external with physical NIC "eno2"?  Do I still 
> need add that NIC into "br-ex"?  
> 
> 
> Best Regards,
> Dave Chen
> 
> -Original Message-
> From: Slawomir Kaplonski [mailto:skapl...@redhat.com] 
> Sent: Friday, June 15, 2018 5:09 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron] Question on the OVS configuration
> 
> Hi,
> 
> If You have vxlan network than traffic from it is going via vxlan tunnel 
> which is in br-tun bridge instead of br-ex. 
> 
>> Wiadomość napisana przez dave.c...@dell.com w dniu 15.06.2018, o godz. 10:17:
>> 
>> Dear folks,
>> 
>> I have setup a pretty simple OpenStack cluster in our lab based on devstack, 
>> couples of guest VM are running on one controller node (this doesn’t looks 
>> like a right behavior anyway),  the Neutron network is configured as OVS + 
>> vxlan, the bridge “br-ex” configured as below:
>> 
>>Bridge br-ex
>>Controller "tcp:127.0.0.1:6633"
>>is_connected: true
>>fail_mode: secure
>>Port phy-br-ex
>>Interface phy-br-ex
>>type: patch
>>options: {peer=int-br-ex}
>>Port br-ex
>>Interface br-ex
>>type: internal
>> ovs_version: "2.8.0"
>> 
>> 
>> 
>> As you see, there is no external physical NIC bound to “br-ex”, so I guess 
>> the traffic from the VM to external will use the default route set on the 
>> controller node,  since there is a NIC (eno2) that can access external so I 
>> bind it to “br-ex” like this: ovs-vsctl add-port br-ex eno2. now the “br-ex” 
>> is configured as below:  
>> 
>>Bridge br-ex
>>Controller "tcp:127.0.0.1:6633"
>>is_connected: true
>>fail_mode: secure
>>Port phy-br-ex
>>Interface phy-br-ex
>>type: patch
>>options: {peer=int-br-ex}
>>*Port "eno2"*
>>Interface "eno2"
>>Port br-ex
>>Interface br-ex
>>type: internal
>>ovs_version: "2.8.0"
>> 
>> 
>> 
>> Looks like this is how it should be configured according to lots of 
>> wiki/blog suggestion I have googled, but it doesn’t work as expected, ping 
>> from the VM, the tcpdump shows the traffic still go the “eno1” which is the 
>> default route on the controller node. 
>> 
>> Inside of VM
>> ubuntu@test-br:~$ ping 8.8.8.8
>> PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
>> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=38 time=168 ms
>> 64 bytes from 8.8.8.8: icmp_seq=2 ttl=38 time=168 ms …
>> 
>> Dump the traffic on the “eno2”, got nothing $ sudo tcpdump -nn -i eno2 
>> icmp
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol 
>> decode listening on eno2, link-type EN10MB (Ethernet), capture size 
>> 262144 bytes …
>> 
>> Dump the traffic on the “eno1” (internal NIC),  catch it!
>> $ sudo tcpdump -nn -i eno1 icmp
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol 
>> decode listening on eno1, link-type EN10MB (Ethernet), capture size 
>> 262144 bytes
>> 16:08:59.609888 IP 192.168.20.132 > 8.8.8.8: ICMP echo request, id 
>> 1439, seq 1, length 64
>> 16:08:59.781042 IP 8.8.8.8 > 192.168.20.132: ICMP echo reply, id 1439, 
>> seq 1, length 64
>> 16:09:00.611453 IP 192.168.20.132 > 8.8.8.8: ICMP echo request, id 
>> 1439, seq 2, length 64
>> 16:09:00.779550 IP 8.8.8.8 > 192.168.20.132: ICMP echo reply, id 1439, 
>> seq 2, length 64
>> 
>> 
>> $ sudo ip route
>> default via 192.168.18.1 dev eno1  proto static  metric 100 default 
>> via 192.168.8.1 dev eno2  proto static  metric 101
>> 169.254.0.0/16 dev docker0  scope link  metric 1000 linkdown
>> 172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1 
>> linkdown
>> 192.168.8.0/24 dev eno2  proto kernel  scope link  src 192.168.8.101  
>> metric 100
>> 192.168.16.0/21 dev eno1  proto kernel  scope link  src 192.168.20.132  
>> metric 100
>> 192.168.42.0/24 dev br-ex  proto kernel  scope link  src 192.168.42.1
>> 
>> 
>> What’s going wrong here? Do I miss something? Or some service need to be 
>> restarted?
>> 
>> Anyone could help me out?  This question made me sick for many days!  Huge 
>> thanks in the advance!
>> 
>> 
>> Best Regards,
>> Dave
>> 
>> __
>>  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
> 
> —
> Slawek Kaplonski
> Senior software engineer
> Red Hat
> 
> 
> __
>

Re: [openstack-dev] [cinder] backups need reserved space for LVM snapshots: do we have it implemented already?

2018-06-15 Thread Thomas Goirand

On 06/14/2018 01:10 PM, Erlon Cruz wrote:
> Hi Thomas,
> 
> The reserved_percentage *is* taken in account for non thin provisoning
> backends. So you can use it to spare the space you need for backups. It
> is a per backend configuration.

Oh. Reading the doc, I thought it was only for thin provisioning, it's
nice if it works with "normal" cinder LVM then ... :P

When you say "per backend", does it means it can be set differently on
each volume node?

> If you have already tried to used it and that is not working, please let
> us know what release you are using, because despite this being the
> current (and proper) behavior, it might not being like this in the past.
> 
> Erlon

Will do, thanks.

Cheers,

Thomas

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

Re: [openstack-dev] [tc] [summary] Organizational diversity tag

2018-06-15 Thread Jean-Philippe Evrard

I think PTLs would naturally like to have those updated, and for me a
TC +w would make sense.
But we need to have guidelines, so that's it's more tangible, and the
subtlety stays impartial.

__
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] [cinder] [placement] cinder + placement forum session etherpad

2018-06-15 Thread Eric Fried

We just merged an initial pass at direct access to the placement service
[1].  See the test_direct suite for simple usage examples.

Note that this was written primarily to satisfy the FFU use case in
blueprint reshape-provider-tree [2] and therefore likely won't have
everything cinder needs.  So play around with it, but please do not put
it anywhere near production until we've had some more collab.  Find us
in #openstack-placement.

-efried

[1] https://review.openstack.org/572576
[2] https://review.openstack.org/572583

On 06/04/2018 07:57 AM, Jay S Bryant wrote:
> 
> 
> On 6/1/2018 7:28 PM, Chris Dent wrote:
>> On Wed, 9 May 2018, Chris Dent wrote:
>>
>>> I've started an etherpad for the forum session in Vancouver devoted
>>> to discussing the possibility of tracking and allocation resources
>>> in Cinder using the Placement service. This is not a done deal.
>>> Instead the session is to discuss if it could work and how to make
>>> it happen if it seems like a good idea.
>>>
>>> The etherpad is at
>>>
>>>    https://etherpad.openstack.org/p/YVR-cinder-placement
>>
>> The session went well. Some of the members of the cinder team who
>> might have had more questions had not been able to be at summit so
>> we were unable to get their input.
>>
>> We clarified some of the things that cinder wants to be able to
>> accomplish (run multiple schedulers in active-active and avoid race
>> conditions) and the fact that this is what placement is built for.
>> We also made it clear that placement itself can be highly available
>> (and scalable) because of its nature as a dead-simple web app over a
>> database.
>>
>> The next steps are for the cinder team to talk amongst themselves
>> and socialize the capabilities of placement (with the help of
>> placement people) and see if it will be suitable. It is unlikely
>> there will be much visible progress in this area before Stein.
> Chris,
> 
> Thanks for this update.  I have it on the agenda for the Cinder team to
> discuss this further.  We ran out of time in last week's meeting but
> will hopefully get some time to discuss it this week.  We will keep you
> updated as to how things progress on our end and pull in the placement
> guys as necessary. 
> 
> Jay
>>
>> See the etherpad for a bit more detail.
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

Re: [openstack-dev] [tripleo] Migration to Storyboard

2018-06-15 Thread Alex Schultz

On Fri, Jun 15, 2018 at 3:12 AM, Michele Baldessari  wrote:
> On Mon, May 21, 2018 at 01:58:26PM -0700, Emilien Macchi wrote:
>> During the Storyboard session today:
>> https://etherpad.openstack.org/p/continuing-the-migration-lp-sb
>>
>> We mentioned that TripleO would continue to migrate during Rocky cycle.
>> Like Alex mentioned in this thread, we need to migrate the scripts used by
>> the CI squad so they work with SB.
>> Once this is done, we'll proceed to the full migration of all blueprints
>> and bugs into tripleo-common project in SB.
>> Projects like tripleo-validations, tripleo-ui (more?) who have 1:1 mapping
>> between their "name" and project repository could use a dedicated project
>> in SB, although we need to keep things simple for our users so they know
>> where to file a bug without confusion.
>> We hope to proceed during Rocky but it'll probably take some time to update
>> our scripts and documentation, also educate our community to use the tool,
>> so we expect the Stein cycle the first cycle where we actually consume SB.
>>
>> I really wanted to thank the SB team for their patience and help, TripleO
>> is big and this migration hasn't been easy but we'll make it :-)
>
> Having used storyboard for the first time today to file a bug^Wstory in heat,
> I'd like to raise a couple of concerns on this migration. And by all
> means, if I just missed to RTFM, feel free to point me in the right
> direction.
>
> 1. Searching for bugs in a specific project is *extremely* cumbersome
>and I am not even sure I got it right (first you need to put
>openstack/project in the search bar, wait and click it. Then you add
>the term you are looking for. I have genuinely no idea if I get all
>the issues I was looking for or not as it is not obvious on what
>fields this search is performed
> 2. Advanced search is either very well hidden or not existant yet?
>E.g. how do you search for bugs filed by someone or over a certain
>release, or just generally more complex searches which are super
>useful in order to avoid filing duplicate bugs.
>
> I think Zane's additional list also matches my experience very well:
> http://lists.openstack.org/pipermail/openstack-dev/2018-June/131365.html
>
> So my take is that a migration atm is a bit premature and I would
> postpone it at least to Stein.
>

Given that my original request was to try and do it prior to M2 and
that's past, I think I'd also side with waiting until early Stein to
continue.  Let's focus on the Rocky work and push this to early Stein
instead. I'll talk about this in the next IRC meeting if anyone wishes
to discuss further.

Thanks,
-Alex

> Thanks,
> Michele
>
>> Thanks,
>>
>> On Tue, May 15, 2018 at 7:53 AM, Alex Schultz  wrote:
>>
>> > Bumping this up so folks can review this.  It was mentioned in this
>> > week's meeting that it would be a good idea for folks to take a look
>> > at Storyboard to get familiar with it.  The upstream docs have been
>> > updated[0] to point to the differences when dealing with proposed
>> > patches.  Please take some time to review this and raise any
>> > concerns/issues now.
>> >
>> > Thanks,
>> > -Alex
>> >
>> > [0] https://docs.openstack.org/infra/manual/developers.html#
>> > development-workflow
>> >
>> > On Wed, May 9, 2018 at 1:24 PM, Alex Schultz  wrote:
>> > > Hello tripleo folks,
>> > >
>> > > So we've been experimenting with migrating some squads over to
>> > > storyboard[0] but this seems to be causing more issues than perhaps
>> > > it's worth.  Since the upstream community would like to standardize on
>> > > Storyboard at some point, I would propose that we do a cut over of all
>> > > the tripleo bugs/blueprints from Launchpad to Storyboard.
>> > >
>> > > In the irc meeting this week[1], I asked that the tripleo-ci team make
>> > > sure the existing scripts that we use to monitor bugs for CI support
>> > > Storyboard.  I would consider this a prerequisite for the migration.
>> > > I am thinking it would be beneficial to get this done before or as
>> > > close to M2.
>> > >
>> > > Thoughts, concerns, etc?
>> > >
>> > > Thanks,
>> > > -Alex
>> > >
>> > > [0] https://storyboard.openstack.org/#!/project_group/76
>> > > [1] http://eavesdrop.openstack.org/meetings/tripleo/2018/
>> > tripleo.2018-05-08-14.00.log.html#l-42
>> >
>> > __
>> > 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
>> >
>>
>>
>>
>> --
>> Emilien Macchi
>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> Michele Baldessari
>

[openstack-dev] [tricircle] Zuul v3 integration status

2018-06-15 Thread Boden Russell

Is there anyone who can speak to the status of tricircle's adoption of
Zuul v3?

As per [1] it doesn't seem like the project is setup properly for Zuul
v3. Thus, it's difficult/impossible to land patches like [2] that
require neutron/master + a depends on patch.

Assuming tricircle is still being maintained, IMO we need to find a way
to get it up to speed with zuul v3; otherwise some of our neutron
efforts will be held up, or tricircle will fall behind with respect to
neutron-lib adoption.

Thanks


[1] https://bugs.launchpad.net/tricircle/+bug/1776922
[2] https://review.openstack.org/#/c/565879/

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

Re: [openstack-dev] [tc] [ptl] PTL E-mail addresses on rendered team pages

2018-06-15 Thread Jeremy Stanley

On 2018-06-15 10:23:36 -0500 (-0500), Matthew Thode wrote:
[...]
> Not sure it'd help but one option we do is to create aliases based
> on the title.  Though since the PTLs don't have addresses on the
> openstack domain an alias may not make as much sense, it'd have to
> be a full account forward.  It's useful for centralized spam
> filtering.

I'm not personally comfortable having someone else decide for me
what is or isn't spam, and I doubt I'm alone in that.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on storage bits

2018-06-15 Thread Goutham Pacha Ravi

+1


On Thu, Jun 14, 2018 at 11:03 PM Michele Baldessari  wrote:
>
> +1
>
> On Wed, Jun 13, 2018 at 08:50:23AM -0700, Emilien Macchi wrote:
> > Alan Bishop has been highly involved in the Storage backends integration in
> > TripleO and Puppet modules, always here to update with new features, fix
> > (nasty and untestable third-party backends) bugs and manage all the
> > backports for stable releases:
> > https://review.openstack.org/#/q/owner:%22Alan+Bishop+%253Cabishop%2540redhat.com%253E%22
> >
> > He's also well knowledgeable of how TripleO works and how containers are
> > integrated, I would like to propose him as core on TripleO projects for
> > patches related to storage things (Cinder, Glance, Swift, Manila, and
> > backends).
> >
> > Please vote -1/+1,
> > Thanks!
> > --
> > Emilien Macchi
>
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> Michele Baldessari
> C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [tc] [ptl] PTL E-mail addresses on rendered team pages

2018-06-15 Thread Matthew Thode

On 18-06-15 15:00:50, Jeremy Stanley wrote:
> Governance tooling change https://review.openstack.org/575554 is
> currently up for review to start displaying current PTL E-mail
> addresses on the team specific pages linked from the projects index
> https://governance.openstack.org/tc/reference/projects/ page.
> 
> Since https://review.openstack.org/234420 merged a few years ago
> we've been tracking PTL E-mail addresses in the structured data from
> which we generate those pages, but the Sphinx extension we're using
> was never amended to include them. Having somewhere consistent to
> point members of the community who need to reach out to the PTL of a
> team in private (and may not have easy access or comfort to do so via
> IRC privmsg) would be useful. Right now we're stuck telling people
> to dig around in a YAML file for them, which is not an especially
> friendly answer.
> 
> A knee-jerk reaction any time E-mail addresses get displayed
> somewhere new is that it's going to increase the amount of spam
> those addresses receive. Keep in mind that we've been publishing all
> of them on a Web page for years now, just one which is only
> convenient for spammers and not one which is convenient for people
> who might have a legitimate need to contact our PTLs.
> -- 
> Jeremy Stanley

Not sure it'd help but one option we do is to create aliases based on
the title.  Though since the PTLs don't have addresses on the openstack
domain an alias may not make as much sense, it'd have to be a full
account forward.  It's useful for centralized spam filtering.

-- 
Matthew Thode (prometheanfire)


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

[openstack-dev] [tc] [ptl] PTL E-mail addresses on rendered team pages

2018-06-15 Thread Jeremy Stanley

Governance tooling change https://review.openstack.org/575554 is
currently up for review to start displaying current PTL E-mail
addresses on the team specific pages linked from the projects index
https://governance.openstack.org/tc/reference/projects/ page.

Since https://review.openstack.org/234420 merged a few years ago
we've been tracking PTL E-mail addresses in the structured data from
which we generate those pages, but the Sphinx extension we're using
was never amended to include them. Having somewhere consistent to
point members of the community who need to reach out to the PTL of a
team in private (and may not have easy access or comfort to do so via
IRC privmsg) would be useful. Right now we're stuck telling people
to dig around in a YAML file for them, which is not an especially
friendly answer.

A knee-jerk reaction any time E-mail addresses get displayed
somewhere new is that it's going to increase the amount of spam
those addresses receive. Keep in mind that we've been publishing all
of them on a Web page for years now, just one which is only
convenient for spammers and not one which is convenient for people
who might have a legitimate need to contact our PTLs.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [neutron] Question on the OVS configuration

You are using vxlan network which is not going through br-ex but via br-tun.
In br-tun You have established vxlan tunnel:

>Port "vxlan-c0a81218"
>Interface "vxlan-c0a81218"
>type: vxlan
>options: {df_default="true", in_key=flow, 
> local_ip="192.168.20.132", out_key=flow, remote_ip="192.168.18.24”}

So traffic from Your vm is going via this tunnel to remote end with IP 
192.168.18.24 from local IP 192.168.20.132
This local IP 192.168.20.132 is probably configured on Your eno1 interface. Ovs 
is sending packets to remote IP according
To Your routing table so packets to 192.168.18.24 are going via eno1.

If You want to use br-ex to send packets, You should have flat or vlan network 
created and such networks are going via br-ex basically.

> Wiadomość napisana przez dave.c...@dell.com w dniu 15.06.2018, o godz. 12:13:
> 
> Apologize for having sent this question to a dev mailing list first! But I 
> humbly request to continue the discussion here.
> 
> 
> My VM is connect to a private network under demo project, here is the info of 
> the network:
> 
> $ openstack network show 64f4f4dc-a851-486a-8789-43b816d9bf3d
> +---++
> | Field | Value   
>|
> +---++
> | admin_state_up| UP  
>|
> | availability_zone_hints   | 
>|
> | availability_zones| nova
>|
> | created_at| 2018-06-15T04:26:18Z
>|
> | description   | 
>|
> | dns_domain| None
>|
> | id| 64f4f4dc-a851-486a-8789-43b816d9bf3d
>|
> | ipv4_address_scope| None
>|
> | ipv6_address_scope| None
>|
> | is_default| None
>|
> | is_vlan_transparent   | None
>|
> | mtu   | 1450
>|
> | name  | private 
>|
> | port_security_enabled | True
>|
> | project_id| e202899d90ba449d880be42f19cd6a55
>|
> | provider:network_type | vxlan   
>|
> | provider:physical_network | None
>|
> | provider:segmentation_id  | 72  
>|
> | qos_policy_id | None
>|
> | revision_number   | 4   
>|
> | router:external   | Internal
>|
> | segments  | None
>|
> | shared| False   
>|
> | status| ACTIVE  
>|
> | subnets   | 18a0847e-b733-4ec2-9e25-d7d630a1af2f, 
> 91e91bab-7405-4717-97cd-4ca2cb11589d |
> | tags  | 
>|
> | updated_at| 2018-06-15T04:26:23Z
>|
> +---++
> 
> 
> 
> And below is the full output of ovs bridges.
> 
> $ sudo ovs-vsctl show
> 0ee72d8a-65bc-4c82-884a-61b0e86b9893
>Manager "ptcp:6640:127.0.0.1"
>is_connected: true
>Bridge br-int
>Controller "tcp:127.0.0.1:6633"
>is_connected: true
>fail_mode: secure
>Port "qvo97604b93-55"
>tag: 1

Re: [openstack-dev] [qa][python3] advice needed with updating lib-forward-testing jobs

Excerpts from Ghanshyam's message of 2018-06-15 09:04:35 +0900:
> 
> 
> 
>   On Fri, 15 Jun 2018 06:17:34 +0900 Doug Hellmann 
>  wrote  
>  > Excerpts from Doug Hellmann's message of 2018-06-14 13:02:31 -0400:
>  > > Excerpts from Ghanshyam's message of 2018-06-14 16:54:33 +0900:
>  > 
>  > > >  > > > Could it be as simple as adding tempest-full-py3 with the
>  > > >  > > > required-projects list updated to include the current 
> repository? So
>  > > >  > > > there isn't a special separate job, and we would just reuse
>  > > >  > > > tempest-full-py3 for this?
>  > > > 
>  > > > This can work if lib-forward-testing is going to run against current 
> lib repo only not cross lib or cross project. For example, if neutron want to 
> tests neutron change against neutron-lib src  then this will not work. But 
> from history [1] this does not seems to be scope of lib-forward-testing.
>  > > > 
>  > > > Even  we do not need to add current repo to required-projects list or 
> in LIBS_FROM_GIT .  That will always from master + current patch changes. So 
> this makes no change in tempest-full-py3 job and we can directly use  
> tempest-full-py3 job in lib-forward-testing. Testing in [2].
>  > > 
>  > > Does it? So if I add tempest-full-py3 to a *library* that library is
>  > > installed from source in the job? I know the source for the library
>  > > will be checked out, but I'm surprised that devstack would be configured
>  > > to use it. How does that work?
>  > 
>  > Based on my testing, that doesn't seem to be the case. I added it to
>  > oslo.config and looking at the logs [1] I do not set LIBS_FROM_GIT set
>  > to include oslo.config and the check function is returning false so that
>  > it is not installed from source [2].
> 
> Yes, It will not be set on LIBS_FROM_GIT as we did not set it explicitly. But 
> gate running on any repo does run job on current change set of that repo 
> which is nothing but  "master + current patch changes" . For example, any job 
> running on oslo.config patch will take oslo.config source code from that 
> patch which is "master + current change". You can see the results in this 
> patch - https://review.openstack.org/#/c/575324/ . Where I deleted a module 
> and gate jobs (including tempest-full-py3) fails as they run on current 
> change set of neutron-lib code not on pypi version(which would pass the 
> tests). 

The tempest-full-py3 job passed for that patch, though. Which seems to
indicate that the neutron-lib repository was not used in the test job,
even though it was checked out.

> 
> In that case, lib's proposed change will be tested against integration tests  
> job to check any regression. If we need to run cross lib/project testing of 
> any lib then, yes we need the 'tempest-full-py3-src' job but that is separate 
> things as you mentioned. 
> 
> -gmann
> 
>  > 
>  > So, I think we need the tempest-full-py3-src job. I will propose an
>  > update to the tempest repo to add that.
>  > 
>  > Doug
>  > 
>  > [1] 
> http://logs.openstack.org/64/575164/2/check/tempest-full-py3/9aa50ad/job-output.txt.gz
>  > [2] 
> http://logs.openstack.org/64/575164/2/check/tempest-full-py3/9aa50ad/job-output.txt.gz#_2018-06-14_19_40_56_223136
>  > 
>  > __
>  > OpenStack Development Mailing List (not for usage questions)
>  > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>  > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>  > 
> 

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

Re: [openstack-dev] [tc] [ptl] PTL E-mail addresses on rendered team pages

2018-06-15 Thread Matthew Thode

On 18-06-15 15:29:07, Jeremy Stanley wrote:
> On 2018-06-15 10:23:36 -0500 (-0500), Matthew Thode wrote:
> [...]
> > Not sure it'd help but one option we do is to create aliases based
> > on the title.  Though since the PTLs don't have addresses on the
> > openstack domain an alias may not make as much sense, it'd have to
> > be a full account forward.  It's useful for centralized spam
> > filtering.
> 
> I'm not personally comfortable having someone else decide for me
> what is or isn't spam, and I doubt I'm alone in that.
> -- 
> Jeremy Stanley

That makes sense, it'd only be for openstack ptl emails, still makes
sense.

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [cinder] [placement] cinder + placement forum session etherpad

2018-06-15 Thread Chris Dent


On Fri, 15 Jun 2018, Eric Fried wrote:


We just merged an initial pass at direct access to the placement service
[1].  See the test_direct suite for simple usage examples.

Note that this was written primarily to satisfy the FFU use case in
blueprint reshape-provider-tree [2] and therefore likely won't have
everything cinder needs.  So play around with it, but please do not put
it anywhere near production until we've had some more collab.  Find us
in #openstack-placement.


Just to word this a bit more strongly (see also
http://p.anticdent.org/2nbF, where this is paraphrased from):

It would be bad news for cinder to start from placement direct. Better
would be for cinder to figure out how to use placement "normally", and
then for the standalone special case, consider placement direct or
something derived from it. PlacementDirect, as currently written,
is really for special cases only, for use in extremis only.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
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] [barbican] NEW weekly meeting time

2018-06-15 Thread Dave McCowan (dmccowan)

+1
This is a great time.

On 6/14/18, 4:30 PM, "Ade Lee"  wrote:

>The new time slot has been pretty difficult for folks to attend.
>I'd like to propose a new time slot, which will hopefully be more
>amenable to everyone.
>
>Tuesday 12:00 UTC
>
>https://www.timeanddate.com/worldclock/fixedtime.html?hour=12=00
>c=0
>
>This works out to 8 am EST, around 1pm in Europe, and 8 pm in China.
>Please vote by responding to this email.
>
>Thanks,
>Ade
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [tc] [ptl] PTL E-mail addresses on rendered team pages

2018-06-15 Thread Jean-Philippe Evrard

> Not sure it'd help but one option we do is to create aliases based on
> the title.  Though since the PTLs don't have addresses on the openstack
> domain an alias may not make as much sense, it'd have to be a full
> account forward.  It's useful for centralized spam filtering.

I foresee this:
1) We create an alias  to PTL email
2) PTL think that kind of emails are worth sharing with a team to balance work
3) We now have a project mailing list
4) People stop using openstack-dev lists.

But that's maybe me...

__
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] [qa][python3] advice needed with updating lib-forward-testing jobs

2018-06-15 Thread James E. Blair

Doug Hellmann  writes:

> Excerpts from Ghanshyam's message of 2018-06-15 09:04:35 +0900:

>> Yes, It will not be set on LIBS_FROM_GIT as we did not set it
>> explicitly. But gate running on any repo does run job on current
>> change set of that repo which is nothing but "master + current patch
>> changes" . For example, any job running on oslo.config patch will
>> take oslo.config source code from that patch which is "master +
>> current change". You can see the results in this patch -
>> https://review.openstack.org/#/c/575324/ . Where I deleted a module
>> and gate jobs (including tempest-full-py3) fails as they run on
>> current change set of neutron-lib code not on pypi version(which
>> would pass the tests).
>
> The tempest-full-py3 job passed for that patch, though. Which seems to
> indicate that the neutron-lib repository was not used in the test job,
> even though it was checked out.

The automatic generation of LIBS_FROM_GIT only includes projects which
appear in required-projects.  So in this case neutron-lib does not
appear in LIBS_FROM_GIT[1], so the change is not actually tested by that
job.

Doug's approach of adding {{zuul.project}} to LIBS_FROM_GIT would work,
but anytime LIBS_FROM_GIT is set explicitly, it turns off the automatic
generation, so more complex jobs (which may want to inherit from that
job but need multiple libraries) would also have to override
LIBS_FROM_GIT and add the full set of projects.

The code that automatically sets LIBS_FROM_GIT is fairly simple and
could be modified to automatically add the project of the change under
test.  We could do that for all jobs, or we could add a flag which
toggles the behavior.  The question to answer here is: is there ever a
case where a devstack job should not install the change under test from
source?  I think the answer is no, and even though under Zuul v2
devstack-gate didn't automatically add the project under test to
LIBS_FROM_GIT, we probably had that behavior anyway due to some JJB
templating which did.

A further thing to consider is what the desired behavior is for a series
of changes.  If a change to neutron-lib depends on a change to
oslo.messaging, when the forward testing job runs on neutron-lib, should
it also add oslo.messaging to LIBS_FROM_GIT?  That's equally easy to
implement (but would certainly need a flag as it essentially would add
everything in the change series to LIBS_FROM_GIT which defeats the
purpose of the restriction for the jobs which need it), but I honestly
am not certain what's desired.

For each type of project (service, lib, lib-group (eg oslo.messaging)),
what do we want to test from git vs pypi?  How many jobs are needed to
accomplish that?  What should happen with a change series with other
projects in it?

[1] 
http://logs.openstack.org/24/575324/3/check/tempest-full-py3/d183788/controller/logs/_.localrc_auto.txt

-Jim

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

Re: [openstack-dev] [cinder] backups need reserved space for LVM snapshots: do we have it implemented already?

2018-06-15 Thread Erlon Cruz

Hi Thomas,

Yes. If you have more than 1 volume node, or 1 volume node with multiple
backends definitions. Each volume node should have at least one [backend]
that will point to your storage configuration. You can add that config for
each of them.

Erlon

Em sex, 15 de jun de 2018 às 09:52, Thomas Goirand 
escreveu:

> On 06/14/2018 01:10 PM, Erlon Cruz wrote:
> > Hi Thomas,
> >
> > The reserved_percentage *is* taken in account for non thin provisoning
> > backends. So you can use it to spare the space you need for backups. It
> > is a per backend configuration.
>
> Oh. Reading the doc, I thought it was only for thin provisioning, it's
> nice if it works with "normal" cinder LVM then ... :P
>
> When you say "per backend", does it means it can be set differently on
> each volume node?
>
> > If you have already tried to used it and that is not working, please let
> > us know what release you are using, because despite this being the
> > current (and proper) behavior, it might not being like this in the past.
> >
> > Erlon
>
> Will do, thanks.
>
> Cheers,
>
> Thomas
>
> __
> 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] [nova] [placement] placement update 18-24

2018-06-15 Thread Chris Dent



HTML: https://anticdent.org/placement-update-18-24.html

This is placement update 18-24, a weekly update of ongoing
development related to the [OpenStack](https://www.openstack.org/)
[placement
service](https://developer.openstack.org/api-ref/placement/).

It's been quite a while since the last one, mostly because of
travel, but also because coming to grips with the placement universe
takes some time. Catching up will mean that this update is likely to
be a bit long. Bear with it. This is obviously an _expand_ style
update (where we add new stuff). Next week will be a _contract_.

One thing I'd like to highlight is that with the merge of change
[560459](https://review.openstack.org/#/c/560459/) we've hit a long
promised milestone with placement. Thanks to an initial hit by Eric
Fried and considerable followups by Bhagyashri Shewale, we now have
rudimentary support in nova for libvirt-using compute nodes that
use shared disk to accurately report and claim that disk. Using it
requires some currently manual set up for the resource provider
associated with the disk and creating the aggregate of that disk
with the compute nodes that use it. But: this is one of the earliest
promises provided by the placement concept, in the works for more
than two years by many different people, finally showing up. Open
the bubbly or something, a light celebration is in order.

The flip side of this is that it highlights that we have a growing
documentation debt with the many features provided by placement and
how to make best use of them in nova (and other services that might
like to use placement). Before the end of the cycle we will need to
be sure that we set aside a considerable chunk of time to address
this gap.

# Most Important

Getting nested providers and consumer generations working are still
the key pieces of work. See the links in the themes below.

A lot of complicated work is in progress or recently merged and we
are getting deeper into the cycle. There are going to be bugs.  The
sooner we get stuff merged so it has time to interact and we have
time to experiment with it the better. And there's also that
documentation gap mentioned above.

Also a reminder that for blueprints that have code that is ready for
wide review, put it on the
[runway](https://etherpad.openstack.org/p/nova-runways-rocky).

# What's Changed

(This is rather long because of the gap since the last report, but
also because we've hit a point where lots of stuff can merge.)

Discussion revealed an issue with allocations and inventory that
exists on a top-level resource provider which we'd later like to
move to a nested provider. An example is VGPU inventory which, until
sometime very soon, was represented as inventory on the compute
node (I think). Fixing this should be an atomic operation so a spec
is in progress for [Handling Reshaped Provider
Trees](https://review.openstack.org/#/c/572583/). This suggests a
new `/migrator` URI in the placement service, and for the sake of
fast-forward-upgrades, a way to reach that URI from a within-process
placement service (rather than over HTTP). The
[PlacementDirect](https://review.openstack.org/#/c/572576/) tool has
been created to allow this and has merged. Quite a lot of work will
need to be done to implement that spec, so I'm going to add it as a
theme (below).

Nova now requires the 1.25 placement microversion. It will go up
again soon.

The groundwork for consumer generations (including requiring
some form of project and user on all allocations) has merged. What
remains is exposing it all at the API layer.

The placement version discovery document was incomplete, causing
trouble for certain ways of using the openstacksdk. This has [been
fixed](https://review.openstack.org/#/c/575117/).

Placement now supports granular policy (policy per URI) in-code,
with customization possible via a policy file.

A potential 500 when listing usage information has been fixed.

There is now a [heal allocations
CLI](https://review.openstack.org/#/c/565886/) which is designed to
help people migrate away from the CachingScheduler (which doesn't
use placement).

Nova host aggregates are now magically mirrored as placement
aggregates and, amongst other things, this is used to honor the
[availability_zone hint via
placement](https://review.openstack.org/#/c/546282/).

# Bugs

* Placement related [bugs not yet in
  progress](https://goo.gl/TgiPXb): 16, same as last time, but a
  different set of bugs.
* [In progress placement bugs](https://goo.gl/vzGGDQ) 9, -1 on last
  time.

# Specs

Total four weeks ago: 13. Now: 13

Spec-freeze has passed, so presumably exceptions will be required
for these. There's already a notional exception for "Reshaped
Provider Trees".

* 
  VMware: place instances on resource pool (using update_provider_tree)

* 
  Proposes NUMA topology with RPs

* 
  Account for host

[openstack-dev] [nova] Rocky blueprint status tracking

2018-06-15 Thread melanie witt


Howdy everyone,

Similar to last cycle, we have an etherpad for tracking the status of 
approved nova blueprints for Rocky here:


https://etherpad.openstack.org/p/nova-rocky-blueprint-status

that we can use to help us review patches. If I've missed any blueprints 
or if anything needs an update, please add a note on the etherpad and 
we'll get it sorted.


Thanks,
-melanie

__
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] Keystone Team Update - Week of 11 June 2018

2018-06-15 Thread Colleen Murphy

# Keystone Team Update - Week of 11 June 2018

## News

### New Implied Roles in keystone-manage bootstrap

We landed one of the first building blocks for Default Roles across OpenStack, 
which is ensuring they are created during the bootstrap of keystone[1]. Since 
this is new feature of the bootstrap command, it has implications for people 
who run the command after their keystone is already bootstrapped. We talked[2] 
about what the intended purpose of the bootstrap command is versus what it is 
potentially being used for, for example as part of automation that expects it 
to be idempotent.

We agreed that the bootstrap change for default roles needed to highlight the 
changing behavior in the upgrade notes so that operators could prepare for it 
if needed. Separately, it would also be good to implement a way to check 
whether bootstrap had already been run so that automated tools can make 
decisions about whether they need to run it, perhaps sidestepping the question 
of whether the command itself should be considered idempotent.

[1] https://review.openstack.org/572243
[2] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-06-13.log.html#t2018-06-13T12:44:00

### OPNFV Edge Computing

I attended the OPNFV Edge Computing Group's[3] meeting[4] to represent the 
keystone team and answer their questions about keystone's testing for federated 
scenarios. They were interested in donating hardware resources to fill out our 
use case coverage, but I had to inform them that we're still a ways away from 
having even basic keystone-to-keystone coverage and that the best way to help 
would to provide people resources to help work on it.

[3] https://wiki.opnfv.org/display/PROJ/Edge+cloud
[4] https://etherpad.opnfv.org/p/edge_cloud_meeting_minutes

### Flaskification

Morgan's work to replace our custom WSGI framework with Flask[5] is well 
underway. We'll be starting to move our API dispatching to Flask next week.

[5] https://review.openstack.org/#/q/topic:flaskification

## Recently Merged Changes

Search query: https://bit.ly/2IACk3F

We merged 19 changes this week, including the first steps for setting up 
default reader and member roles[6] and several changes for the Flask work[7].

[6] https://review.openstack.org/572243
[7] https://review.openstack.org/#/q/status:merged+topic:flaskification

## Changes that need Attention

Search query: https://bit.ly/2wv7QLK

There are 53 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots, whose authors are waiting for any 
feedback. We've also started feature implementations, and initial feedback is 
welcome even if they are not passing tests yet[8][9][10][11].

[8] https://review.openstack.org/572776
[9] https://review.openstack.org/#/q/topic:bp/unified-limits+status:open
[10] 
https://review.openstack.org/#/q/topic:bp/strict-two-level-model+status:open
[11] https://review.openstack.org/#/q/topic:bug/1754184+status:open

## Bugs

These week we opened 8 new bugs and closed 2.

Bugs opened (8) 
Bug #1776506 (keystone:High) opened by Morgan Fainberg 
https://bugs.launchpad.net/keystone/+bug/1776506 
Bug #1776504 (keystone:Medium) opened by Morgan Fainberg 
https://bugs.launchpad.net/keystone/+bug/1776504 
Bug #1776532 (keystone:Medium) opened by John Dennis 
https://bugs.launchpad.net/keystone/+bug/1776532 
Bug #1776541 (keystone:Medium) opened by John Dennis 
https://bugs.launchpad.net/keystone/+bug/1776541 
Bug #1776221 (keystone:Undecided) opened by Yuxin Wang 
https://bugs.launchpad.net/keystone/+bug/1776221 
Bug #1777086 (keystone:Undecided) opened by 徐爱保 
https://bugs.launchpad.net/keystone/+bug/1777086 
Bug #1776501 (keystoneauth:Undecided) opened by Chris Dent 
https://bugs.launchpad.net/keystoneauth/+bug/1776501 
Bug #1777177 (keystonemiddleware:Medium) opened by Morgan Fainberg 
https://bugs.launchpad.net/keystonemiddleware/+bug/1777177 

Bugs fixed (2) 
Bug #1776506 (keystone:High) fixed by Morgan Fainberg 
https://bugs.launchpad.net/keystone/+bug/1776506 
Bug #1776501 (keystoneauth:Undecided) fixed by Eric Fried 
https://bugs.launchpad.net/keystoneauth/+bug/1776501

## Milestone Outlook

https://releases.openstack.org/rocky/schedule.html

Next week is our feature *proposal* freeze. If you're working on implementing 
specs, some initial patches should be proposed by the end of next week.

Many feature patchs have already been proposed. Initial feedback on these WIP 
proposals is encouraged.

## Shout-outs

Thanks to everyone getting started on implementing our major feature work for 
this cycle: adriant, hrybacki, jaosorior, jgrassler, wxy, thank you!

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter
Dashboard generated using gerrit-dash-creator and 
https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67

Re: [openstack-dev] [nova] increasing the number of allowed volumes attached per instance > 26

2018-06-15 Thread Dan Smith

> I thought we were leaning toward the option where nova itself doesn't
> impose a limit, but lets the virt driver decide.
>
> I would really like NOT to see logic like this in any nova code:
>
>> if kvm|qemu:
>> return 256
>> elif POWER:
>> return 4000
>> elif:
>> ...

It's insanity to try to find a limit that will work for
everyone. PowerVM supports a billion, libvirt/kvm has some practical and
theoretical limits, both of which are higher than what is actually
sane. It depends on your virt driver, and how you're attaching your
volumes, maybe how tightly you pack your instances, probably how many
threads you give to an instance, how big your compute nodes are, and
definitely what your workload is.

That's a really big matrix, and even if we decide on something, IBM will
come out of the woodwork with some other hypervisor that has been around
since the Nixon era that uses BCD-encoded volume numbers and thus can
only support 10. It's going to depend, and a user isn't going to be able
to reasonably probe it using any of our existing APIs.

If it's going to depend on all the above factors, I see no reason not to
put a conf value in so that operators can pick a reasonably sane
limit. Otherwise, the limit we pick will be wrong for everyone.

Plus... if we do a conf option we can put this to rest and stop talking
about it, which I for one am *really* looking forward to :)

--Dan

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

Re: [openstack-dev] [nova] Rocky blueprint status tracking

2018-06-15 Thread Matt Riedemann


On 6/15/2018 11:23 AM, melanie witt wrote:
Similar to last cycle, we have an etherpad for tracking the status of 
approved nova blueprints for Rocky here:


https://etherpad.openstack.org/p/nova-rocky-blueprint-status

that we can use to help us review patches. If I've missed any blueprints 
or if anything needs an update, please add a note on the etherpad and 
we'll get it sorted.


Thanks for doing this, I find it very useful to get an overall picture 
of where we're sitting in the final milestone.


--

Thanks,

Matt

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

Re: [openstack-dev] [tripleo] Migration to Storyboard

2018-06-15 Thread Kendall Nelson

On Fri, Jun 15, 2018 at 2:13 AM Michele Baldessari 
wrote:

> On Mon, May 21, 2018 at 01:58:26PM -0700, Emilien Macchi wrote:
> > During the Storyboard session today:
> > https://etherpad.openstack.org/p/continuing-the-migration-lp-sb
> >
> > We mentioned that TripleO would continue to migrate during Rocky cycle.
> > Like Alex mentioned in this thread, we need to migrate the scripts used
> by
> > the CI squad so they work with SB.
> > Once this is done, we'll proceed to the full migration of all blueprints
> > and bugs into tripleo-common project in SB.
> > Projects like tripleo-validations, tripleo-ui (more?) who have 1:1
> mapping
> > between their "name" and project repository could use a dedicated project
> > in SB, although we need to keep things simple for our users so they know
> > where to file a bug without confusion.
> > We hope to proceed during Rocky but it'll probably take some time to
> update
> > our scripts and documentation, also educate our community to use the
> tool,
> > so we expect the Stein cycle the first cycle where we actually consume
> SB.
> >
> > I really wanted to thank the SB team for their patience and help, TripleO
> > is big and this migration hasn't been easy but we'll make it :-)
>
> Having used storyboard for the first time today to file a bug^Wstory in
> heat,
> I'd like to raise a couple of concerns on this migration. And by all
> means, if I just missed to RTFM, feel free to point me in the right
> direction.
>
> 1. Searching for bugs in a specific project is *extremely* cumbersome
>and I am not even sure I got it right (first you need to put
>openstack/project in the search bar, wait and click it. Then you add
>the term you are looking for. I have genuinely no idea if I get all
>the issues I was looking for or not as it is not obvious on what
>fields this search is performed
>

The wait and click-it part is being resolved- that was a bug where you had
to select it to actually get the correct project- it couldn't just be
typed. Yes, if you are looking for stories from a certain project- you want
to restrict the search by adding the project- same way you do in gerrit. If
you feel like the search results aren't showing as many as you think there
should be- you can adjust the setting to show more results.

I suppose we could add some sort of natural language process thing where
with the results it says searching for 'y' in project 'x' (where you put x
and y into the search- x as the project and y as the term as you did in the
description above). Not sure if that would help?

I think the search is a lot more intelligent than people assume and so it
seems difficult to deal with until you figure out how it works. Checking
out the api docs on search might be helpful[1]?

[1] https://docs.openstack.org/infra/storyboard/webapi/v1.html


> 2. Advanced search is either very well hidden or not existant yet?
>E.g. how do you search for bugs filed by someone or over a certain
>release, or just generally more complex searches which are super
>useful in order to avoid filing duplicate bugs.
>
>
Advanced search is the magnifying glass icon on the left navigation bar
(assuming you are using the webclient interface at storyboard.o.o) which I
think is what you were describing using above. The search in the top right
of the webclient is just a jump to quick search.


> I think Zane's additional list also matches my experience very well:
> http://lists.openstack.org/pipermail/openstack-dev/2018-June/131365.html
>
>
I think a lot of Zane's comment's have already been addressed, but I can go
reply on that thread too and hopefully clear up some of the concerns/fears.


> So my take is that a migration atm is a bit premature and I would
> postpone it at least to Stein.
>
>
Hopefully- it will be a stein release goal so it wouldn't be that big a
deal if you waited, but ideally, if there aren't any real blockers for your
team, the sooner the better.


> Thanks,
> Michele
>
> > Thanks,
> >
> > On Tue, May 15, 2018 at 7:53 AM, Alex Schultz 
> wrote:
> >
> > > Bumping this up so folks can review this.  It was mentioned in this
> > > week's meeting that it would be a good idea for folks to take a look
> > > at Storyboard to get familiar with it.  The upstream docs have been
> > > updated[0] to point to the differences when dealing with proposed
> > > patches.  Please take some time to review this and raise any
> > > concerns/issues now.
> > >
> > > Thanks,
> > > -Alex
> > >
> > > [0] https://docs.openstack.org/infra/manual/developers.html#
> > > development-workflow
> > >
> > > On Wed, May 9, 2018 at 1:24 PM, Alex Schultz 
> wrote:
> > > > Hello tripleo folks,
> > > >
> > > > So we've been experimenting with migrating some squads over to
> > > > storyboard[0] but this seems to be causing more issues than perhaps
> > > > it's worth.  Since the upstream community would like to standardize
> on
> > > > Storyboard at some point, I would propose that we do a cut over of
>

Re: [openstack-dev] [nova] [placement] placement update 18-24

2018-06-15 Thread Eric Fried

Thank you as always for doing this, Chris.

> Some of the older items in this list are not getting much attention.
> That's a shame. The list is ordered (oldest first) the way it is on
> purpose.
> 
> * 
>   Purge comp_node and res_prvdr records during deletion of
>   cells/hosts

This is still on its first patch set, in merge conflict, with no action
for about 3mo.  Is it still being worked?

> * 
>   placement: Make API history doc more consistent

Reviewed.

> * 
>   Handle agg generation conflict in report client

Rebased.  This previously had three +1s.

> * 
>   Add unit test for non-placement resize

Reviewed.

> * 
>   cover migration cases with functional tests

Reviewed.

> * 
>   Bug fixes for sharing resource providers

Two patches under this topic.

https://review.openstack.org/533437 is abandoned

https://review.openstack.org/#/c/519601/ reviewed (again) & rebased

> * 
>   Move refresh time from report client to prov tree

This patch is still alive only as a marker on my TODO list - I need to
replace it with something completely different as noted by Jay & myself
at the bottom.

> * 
>   PCPU resource class

Reviewed & rebased.  This also made me notice an unused thing, which
I've proposed to remove via https://review.openstack.org/575847

> * 
>   rework how we pass candidate request information

This represents a toe in the waters of "we ought to go back and majorly
refactor a lot of the placement code - especially
nova/api/openstack/placement/objects/resource_provider.py - to make it
more readable and maintainable.  This particular patch is in merge
conflict (pretty majorly, if I'm not mistaken) and probably needs to
wait until the dust settles around nrp-in-alloc-candidates to be
resurrected.

> * 
>   add root parent NULL online migration

Reviewed.  (In merge conflict, and needs tests.)

> * 
>   add resource_requests field to RequestSpec

Active series currently starts at https://review.openstack.org/#/c/570018/

I've been reviewing these; need to catch up on the latest.

> * 
>   replace deprecated accept.best_match

Heading to the gate.

> * 
>   Enforce placement minimum in nova.cmd.status

Heading to the gate.

> * 
>   normalize_name helper (in os-traits)

Needs second core review, please.

> * 
>   Fix nits in nested provider allocation candidates(2)

Heading to the gate.

> * 
>   Convert driver supported capabilities to compute node provider
>   traits

Merge conflict and a bevy of -1s, needs TLC from the author.

> * 
>   Use placement.inventory.inuse in report client

Rebased.

> * 
>   ironic: Report resources as reserved when needed

Needs merge conflict resolved.

> * 
>   Test for multiple limit/group_policy qparams

Another marker for my TODO list.  Added -W.

> # End
> 
> Yow. That was long. Thanks for reading. Review some code please.

++

-efried

__
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] [qa][python3] advice needed with updating lib-forward-testing jobs

Excerpts from corvus's message of 2018-06-15 08:46:40 -0700:
> Doug Hellmann  writes:
> 
> > Excerpts from Ghanshyam's message of 2018-06-15 09:04:35 +0900:
> 
> >> Yes, It will not be set on LIBS_FROM_GIT as we did not set it
> >> explicitly. But gate running on any repo does run job on current
> >> change set of that repo which is nothing but "master + current patch
> >> changes" . For example, any job running on oslo.config patch will
> >> take oslo.config source code from that patch which is "master +
> >> current change". You can see the results in this patch -
> >> https://review.openstack.org/#/c/575324/ . Where I deleted a module
> >> and gate jobs (including tempest-full-py3) fails as they run on
> >> current change set of neutron-lib code not on pypi version(which
> >> would pass the tests).
> >
> > The tempest-full-py3 job passed for that patch, though. Which seems to
> > indicate that the neutron-lib repository was not used in the test job,
> > even though it was checked out.
> 
> The automatic generation of LIBS_FROM_GIT only includes projects which
> appear in required-projects.  So in this case neutron-lib does not
> appear in LIBS_FROM_GIT[1], so the change is not actually tested by that
> job.
> 
> Doug's approach of adding {{zuul.project}} to LIBS_FROM_GIT would work,
> but anytime LIBS_FROM_GIT is set explicitly, it turns off the automatic
> generation, so more complex jobs (which may want to inherit from that
> job but need multiple libraries) would also have to override
> LIBS_FROM_GIT and add the full set of projects.
> 
> The code that automatically sets LIBS_FROM_GIT is fairly simple and
> could be modified to automatically add the project of the change under
> test.  We could do that for all jobs, or we could add a flag which
> toggles the behavior.  The question to answer here is: is there ever a
> case where a devstack job should not install the change under test from
> source?  I think the answer is no, and even though under Zuul v2
> devstack-gate didn't automatically add the project under test to
> LIBS_FROM_GIT, we probably had that behavior anyway due to some JJB
> templating which did.

Adding the project-under-test to LIBS_FROM_GIT unconditionally feels
like the behavior I would expect from the job.

> A further thing to consider is what the desired behavior is for a series
> of changes.  If a change to neutron-lib depends on a change to
> oslo.messaging, when the forward testing job runs on neutron-lib, should
> it also add oslo.messaging to LIBS_FROM_GIT?  That's equally easy to
> implement (but would certainly need a flag as it essentially would add
> everything in the change series to LIBS_FROM_GIT which defeats the
> purpose of the restriction for the jobs which need it), but I honestly
> am not certain what's desired.

I think going ahead and adding everything in the dependency chain
also makes sense. If I have 2 changes in libraries and a change in
a service and I want to test them all together I would expect to
be able to do that by using Depends-On and then for all 3 to be
installed from source in the job that runs.

> 
> For each type of project (service, lib, lib-group (eg oslo.messaging)),
> what do we want to test from git vs pypi?

We want to test changes to service projects with libraries from
PyPI so that we do not end up with services that rely on unreleased
features of libraries.

We want to test changes to libraries with some services installed
from git so that we know changes to the library do not break (current)
master of the service. The set of interesting services may vary,
but a default set that represents the tightly coupled services that
run in the integrated gate now is reasonable.

> How many jobs are needed to accomplish that?

Ideally 1? Or 2? That's what I'm trying to work out.

> What should happen with a change series with other
> projects in it?

I expect all of the patches in a series to be installed from source
somewhere in the chain. That works today if we have a library patch
that depends on a service patch because that patched version of the
service is used in the dsvm job run against the library change. If
we could make the reverse dependency work, too (where a patch to a
service depends on a library change), that would be grand.

I think your patch https://review.openstack.org/#/c/575801/ at least
lets us go in one direction (library->service) using a single job
definition, but I can't tell if it would work the other way around.

> 
> [1] 
> http://logs.openstack.org/24/575324/3/check/tempest-full-py3/d183788/controller/logs/_.localrc_auto.txt
> 
> -Jim
> 

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

Re: [openstack-dev] [tc] [ptl] PTL E-mail addresses on rendered team pages

Excerpts from Jean-Philippe Evrard's message of 2018-06-15 17:37:02 +0200:
> > Not sure it'd help but one option we do is to create aliases based on
> > the title.  Though since the PTLs don't have addresses on the openstack
> > domain an alias may not make as much sense, it'd have to be a full
> > account forward.  It's useful for centralized spam filtering.
> 
> I foresee this:
> 1) We create an alias  to PTL email
> 2) PTL think that kind of emails are worth sharing with a team to balance work
> 3) We now have a project mailing list
> 4) People stop using openstack-dev lists.
> 
> But that's maybe me...
> 

Yeah, setting all of that up feels like it would just be something
else we would have to remember to do every time we have an election.
I'm trying to reduce the number those kinds of tasks we have, so
let's not add a new one.

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] [tripleo] Status of Standalone installer (aka All-In-One)

2018-06-15 Thread Alex Schultz

On Mon, Jun 4, 2018 at 6:26 PM, Emilien Macchi  wrote:
> TL;DR: we made nice progress and you can checkout this demo:
> https://asciinema.org/a/185533
>
> We started the discussion back in Dublin during the last PTG. The idea of
> Standalone (aka All-In-One, but can be mistaken with all-in-one overcloud)
> is to deploy a single node OpenStack where the provisioning happens on the
> same node (there is no notion of {under/over}cloud).
>
> A kind of a "packstack" or "devstack" but using TripleO which has can offer:
> - composable containerized services
> - composable upgrades
> - composable roles
> - Ansible driven deployment
>
> One of the key features we have been focusing so far are:
> - low bar to be able to dev/test TripleO (single machine: VM), with simpler
> tooling
> - make it fast (being able to deploy OpenStack in minutes)


So to provide an update, I spent this week trying to get the network
configuration down for the standalone configuration. I've proposed
docs[0] for two configurations. I was able to test the two
configurations:

a) 2 nic (requires second nic with an accessable second "public"
network that is optionally route-able for VM connectivity)
b) 1 nic (requires 3 ips)

Additionally I've proposed an update to the Standalone role[1] that
includes Controller + Compute on a single node. With this I was able
to try out Keystone, Nova, Neutron (with ovs, floating ips), Glance
(backed by Swift), Cinder (lvm).  This configuration took about 35
mins to go from 0 to cloud on a single 16gb VM hosted on some old
hardware.

Thanks,
-Alex

[0] https://review.openstack.org/#/c/575859/
[1] https://review.openstack.org/#/c/575862/

__
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][api[[graphql] A starting point

2018-06-15 Thread Gilles Dubreuil


Hello,

This initial patch [1]  allows to retrieve networks, subnets.

This is very easy, thanks to the graphene-sqlalchemy helper.

The edges, nodes layer might be confusing at first meanwhile they make 
the Schema Relay-compliant in order to offer re-fetching, pagination 
features out of the box.


The next priority is to set the unit test in order to implement mutations.

Could someone help provide a base in order to respect Neutron test 
requirements?



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

Thanks,
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] [requirements][nova] weird error on 'Validating lower constraints of test-requirements.txt'

2018-06-15 Thread Eric Fried

Doug-

> The lower constraints tests only look at files in the same repo.
> The minimum versions of dependencies set in requirements.txt,
> test-requirements.txt, etc. need to match the values in
> lower-constraints.txt.
> 
> In this case, the more detailed error message is a few lines above the
> error quoted by Chen CH Ji. The detail say "Requirement for package
> retrying has no lower bound" which means that there is a line in
> requirements.txt indicating a dependency on "retrying" but without
> specifying a minimum version. That is the problem.

The patch didn't change the retrying constraint in requirements.txt [1];
why isn't this same failure affecting every other patch in nova?

[1] https://review.openstack.org/#/c/523387/51/requirements.txt@65

-efried

__
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] Question on the OVS configuration

Dear folks,

I have setup a pretty simple OpenStack cluster in our lab based on devstack, 
couples of guest VM are running on one controller node (this doesn't looks like 
a right behavior anyway),  the Neutron network is configured as OVS + vxlan, 
the bridge "br-ex" configured as below:

Bridge br-ex
Controller "tcp:127.0.0.1:6633"
is_connected: true
fail_mode: secure
Port phy-br-ex
Interface phy-br-ex
type: patch
options: {peer=int-br-ex}
Port br-ex
Interface br-ex
type: internal
ovs_version: "2.8.0"



As you see, there is no external physical NIC bound to "br-ex", so I guess the 
traffic from the VM to external will use the default route set on the 
controller node,  since there is a NIC (eno2) that can access external so I 
bind it to "br-ex" like this: ovs-vsctl add-port br-ex eno2. now the "br-ex" is 
configured as below:

Bridge br-ex
Controller "tcp:127.0.0.1:6633"
is_connected: true
fail_mode: secure
Port phy-br-ex
Interface phy-br-ex
type: patch
options: {peer=int-br-ex}
*Port "eno2"*
Interface "eno2"
Port br-ex
Interface br-ex
type: internal
ovs_version: "2.8.0"



Looks like this is how it should be configured according to lots of wiki/blog 
suggestion I have googled, but it doesn't work as expected, ping from the VM, 
the tcpdump shows the traffic still go the "eno1" which is the default route on 
the controller node.

Inside of VM
ubuntu@test-br:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=38 time=168 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=38 time=168 ms
...

Dump the traffic on the "eno2", got nothing
$ sudo tcpdump -nn -i eno2 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno2, link-type EN10MB (Ethernet), capture size 262144 bytes
...

Dump the traffic on the "eno1" (internal NIC),  catch it!
$ sudo tcpdump -nn -i eno1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
16:08:59.609888 IP 192.168.20.132 > 8.8.8.8: ICMP echo request, id 1439, seq 1, 
length 64
16:08:59.781042 IP 8.8.8.8 > 192.168.20.132: ICMP echo reply, id 1439, seq 1, 
length 64
16:09:00.611453 IP 192.168.20.132 > 8.8.8.8: ICMP echo request, id 1439, seq 2, 
length 64
16:09:00.779550 IP 8.8.8.8 > 192.168.20.132: ICMP echo reply, id 1439, seq 2, 
length 64


$ sudo ip route
default via 192.168.18.1 dev eno1  proto static  metric 100
default via 192.168.8.1 dev eno2  proto static  metric 101
169.254.0.0/16 dev docker0  scope link  metric 1000 linkdown
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1 linkdown
192.168.8.0/24 dev eno2  proto kernel  scope link  src 192.168.8.101  metric 100
192.168.16.0/21 dev eno1  proto kernel  scope link  src 192.168.20.132  metric 
100
192.168.42.0/24 dev br-ex  proto kernel  scope link  src 192.168.42.1


What's going wrong here? Do I miss something? Or some service need to be 
restarted?

Anyone could help me out?  This question made me sick for many days!  Huge 
thanks in the advance!


Best Regards,
Dave

__
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 Alan Bishop tripleo core on storage bits

2018-06-15 Thread Michele Baldessari

+1

On Wed, Jun 13, 2018 at 08:50:23AM -0700, Emilien Macchi wrote:
> Alan Bishop has been highly involved in the Storage backends integration in
> TripleO and Puppet modules, always here to update with new features, fix
> (nasty and untestable third-party backends) bugs and manage all the
> backports for stable releases:
> https://review.openstack.org/#/q/owner:%22Alan+Bishop+%253Cabishop%2540redhat.com%253E%22
> 
> He's also well knowledgeable of how TripleO works and how containers are
> integrated, I would like to propose him as core on TripleO projects for
> patches related to storage things (Cinder, Glance, Swift, Manila, and
> backends).
> 
> Please vote -1/+1,
> Thanks!
> -- 
> Emilien Macchi

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


-- 
Michele Baldessari
C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D

__
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] Reminder to add "nova-status upgrade check" to deployment tooling

2018-06-15 Thread Lee Yarwood

On 13-06-18 10:14:32, Matt Riedemann wrote:
> I was going through some recently reported nova bugs and came across [1]
> which I opened at the Summit during one of the FFU sessions where I realized
> the nova upgrade docs don't mention the nova-status upgrade check CLI [2]
> (added in Ocata).
> 
> As a result, I was wondering how many deployment tools out there support
> upgrades and from those, which are actually integrating that upgrade status
> check command.

TripleO doesn't at present but like OSA it looks trivial to add:

https://github.com/openstack/tripleo-heat-templates/blob/master/docker/services/nova-api.yaml

I've created the following bug to track this:

https://bugs.launchpad.net/tripleo/+bug/1777060

> I'm not really familiar with most of them, but I've dabbled in OSA enough to
> know where the code lived for nova upgrades, so I posted a patch [3].
> 
> I'm hoping this can serve as a template for other deployment projects to
> integrate similar checks into their upgrade (and install verification)
> flows.
> 
> [1] https://bugs.launchpad.net/nova/+bug/1772973
> [2] https://docs.openstack.org/nova/latest/cli/nova-status.html
> [3] https://review.openstack.org/#/c/575125/

Cheers,

-- 
Lee Yarwood A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76

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

Re: [openstack-dev] [neutron] Question on the OVS configuration

Hi,

If You have vxlan network than traffic from it is going via vxlan tunnel which 
is in br-tun bridge instead of br-ex. 

> Wiadomość napisana przez dave.c...@dell.com w dniu 15.06.2018, o godz. 10:17:
> 
> Dear folks, 
>  
> I have setup a pretty simple OpenStack cluster in our lab based on devstack, 
> couples of guest VM are running on one controller node (this doesn’t looks 
> like a right behavior anyway),  the Neutron network is configured as OVS + 
> vxlan, the bridge “br-ex” configured as below:
>  
> Bridge br-ex
> Controller "tcp:127.0.0.1:6633"
> is_connected: true
> fail_mode: secure
> Port phy-br-ex
> Interface phy-br-ex
> type: patch
> options: {peer=int-br-ex}
> Port br-ex
> Interface br-ex
> type: internal
> ovs_version: "2.8.0"
>  
>  
>  
> As you see, there is no external physical NIC bound to “br-ex”, so I guess 
> the traffic from the VM to external will use the default route set on the 
> controller node,  since there is a NIC (eno2) that can access external so I 
> bind it to “br-ex” like this: ovs-vsctl add-port br-ex eno2. now the “br-ex” 
> is configured as below:  
>  
> Bridge br-ex
> Controller "tcp:127.0.0.1:6633"
> is_connected: true
> fail_mode: secure
> Port phy-br-ex
> Interface phy-br-ex
> type: patch
> options: {peer=int-br-ex}
> *Port "eno2"*
> Interface "eno2"
> Port br-ex
> Interface br-ex
> type: internal
> ovs_version: "2.8.0"
>  
>  
>  
> Looks like this is how it should be configured according to lots of wiki/blog 
> suggestion I have googled, but it doesn’t work as expected, ping from the VM, 
> the tcpdump shows the traffic still go the “eno1” which is the default route 
> on the controller node. 
>  
> Inside of VM
> ubuntu@test-br:~$ ping 8.8.8.8
> PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=38 time=168 ms
> 64 bytes from 8.8.8.8: icmp_seq=2 ttl=38 time=168 ms
> …
>  
> Dump the traffic on the “eno2”, got nothing
> $ sudo tcpdump -nn -i eno2 icmp
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eno2, link-type EN10MB (Ethernet), capture size 262144 bytes
> …
>  
> Dump the traffic on the “eno1” (internal NIC),  catch it!
> $ sudo tcpdump -nn -i eno1 icmp
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
> 16:08:59.609888 IP 192.168.20.132 > 8.8.8.8: ICMP echo request, id 1439, seq 
> 1, length 64
> 16:08:59.781042 IP 8.8.8.8 > 192.168.20.132: ICMP echo reply, id 1439, seq 1, 
> length 64
> 16:09:00.611453 IP 192.168.20.132 > 8.8.8.8: ICMP echo request, id 1439, seq 
> 2, length 64
> 16:09:00.779550 IP 8.8.8.8 > 192.168.20.132: ICMP echo reply, id 1439, seq 2, 
> length 64
>  
>  
> $ sudo ip route
> default via 192.168.18.1 dev eno1  proto static  metric 100
> default via 192.168.8.1 dev eno2  proto static  metric 101
> 169.254.0.0/16 dev docker0  scope link  metric 1000 linkdown
> 172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1 linkdown
> 192.168.8.0/24 dev eno2  proto kernel  scope link  src 192.168.8.101  metric 
> 100
> 192.168.16.0/21 dev eno1  proto kernel  scope link  src 192.168.20.132  
> metric 100
> 192.168.42.0/24 dev br-ex  proto kernel  scope link  src 192.168.42.1
>  
>  
> What’s going wrong here? Do I miss something? Or some service need to be 
> restarted?
>  
> Anyone could help me out?  This question made me sick for many days!  Huge 
> thanks in the advance!
>  
>  
> Best Regards,
> Dave 
>  
> __
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] Migration to Storyboard

2018-06-15 Thread Michele Baldessari

On Mon, May 21, 2018 at 01:58:26PM -0700, Emilien Macchi wrote:
> During the Storyboard session today:
> https://etherpad.openstack.org/p/continuing-the-migration-lp-sb
> 
> We mentioned that TripleO would continue to migrate during Rocky cycle.
> Like Alex mentioned in this thread, we need to migrate the scripts used by
> the CI squad so they work with SB.
> Once this is done, we'll proceed to the full migration of all blueprints
> and bugs into tripleo-common project in SB.
> Projects like tripleo-validations, tripleo-ui (more?) who have 1:1 mapping
> between their "name" and project repository could use a dedicated project
> in SB, although we need to keep things simple for our users so they know
> where to file a bug without confusion.
> We hope to proceed during Rocky but it'll probably take some time to update
> our scripts and documentation, also educate our community to use the tool,
> so we expect the Stein cycle the first cycle where we actually consume SB.
> 
> I really wanted to thank the SB team for their patience and help, TripleO
> is big and this migration hasn't been easy but we'll make it :-)

Having used storyboard for the first time today to file a bug^Wstory in heat,
I'd like to raise a couple of concerns on this migration. And by all
means, if I just missed to RTFM, feel free to point me in the right
direction.

1. Searching for bugs in a specific project is *extremely* cumbersome
   and I am not even sure I got it right (first you need to put
   openstack/project in the search bar, wait and click it. Then you add
   the term you are looking for. I have genuinely no idea if I get all
   the issues I was looking for or not as it is not obvious on what
   fields this search is performed
2. Advanced search is either very well hidden or not existant yet?
   E.g. how do you search for bugs filed by someone or over a certain
   release, or just generally more complex searches which are super
   useful in order to avoid filing duplicate bugs.

I think Zane's additional list also matches my experience very well:
http://lists.openstack.org/pipermail/openstack-dev/2018-June/131365.html

So my take is that a migration atm is a bit premature and I would
postpone it at least to Stein.

Thanks,
Michele

> Thanks,
> 
> On Tue, May 15, 2018 at 7:53 AM, Alex Schultz  wrote:
> 
> > Bumping this up so folks can review this.  It was mentioned in this
> > week's meeting that it would be a good idea for folks to take a look
> > at Storyboard to get familiar with it.  The upstream docs have been
> > updated[0] to point to the differences when dealing with proposed
> > patches.  Please take some time to review this and raise any
> > concerns/issues now.
> >
> > Thanks,
> > -Alex
> >
> > [0] https://docs.openstack.org/infra/manual/developers.html#
> > development-workflow
> >
> > On Wed, May 9, 2018 at 1:24 PM, Alex Schultz  wrote:
> > > Hello tripleo folks,
> > >
> > > So we've been experimenting with migrating some squads over to
> > > storyboard[0] but this seems to be causing more issues than perhaps
> > > it's worth.  Since the upstream community would like to standardize on
> > > Storyboard at some point, I would propose that we do a cut over of all
> > > the tripleo bugs/blueprints from Launchpad to Storyboard.
> > >
> > > In the irc meeting this week[1], I asked that the tripleo-ci team make
> > > sure the existing scripts that we use to monitor bugs for CI support
> > > Storyboard.  I would consider this a prerequisite for the migration.
> > > I am thinking it would be beneficial to get this done before or as
> > > close to M2.
> > >
> > > Thoughts, concerns, etc?
> > >
> > > Thanks,
> > > -Alex
> > >
> > > [0] https://storyboard.openstack.org/#!/project_group/76
> > > [1] http://eavesdrop.openstack.org/meetings/tripleo/2018/
> > tripleo.2018-05-08-14.00.log.html#l-42
> >
> > __
> > 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
> >
> 
> 
> 
> -- 
> Emilien Macchi

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


-- 
Michele Baldessari
C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D

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

Re: [openstack-dev] [neutron] Question on the OVS configuration

Also, I think that You should sent such emails to openst...@lists.openstack.org 
or openstack-operat...@lists.openstack.org in the future :)

> Wiadomość napisana przez dave.c...@dell.com w dniu 15.06.2018, o godz. 10:17:
> 
> Dear folks, 
>  
> I have setup a pretty simple OpenStack cluster in our lab based on devstack, 
> couples of guest VM are running on one controller node (this doesn’t looks 
> like a right behavior anyway),  the Neutron network is configured as OVS + 
> vxlan, the bridge “br-ex” configured as below:
>  
> Bridge br-ex
> Controller "tcp:127.0.0.1:6633"
> is_connected: true
> fail_mode: secure
> Port phy-br-ex
> Interface phy-br-ex
> type: patch
> options: {peer=int-br-ex}
> Port br-ex
> Interface br-ex
> type: internal
> ovs_version: "2.8.0"
>  
>  
>  
> As you see, there is no external physical NIC bound to “br-ex”, so I guess 
> the traffic from the VM to external will use the default route set on the 
> controller node,  since there is a NIC (eno2) that can access external so I 
> bind it to “br-ex” like this: ovs-vsctl add-port br-ex eno2. now the “br-ex” 
> is configured as below:  
>  
> Bridge br-ex
> Controller "tcp:127.0.0.1:6633"
> is_connected: true
> fail_mode: secure
> Port phy-br-ex
> Interface phy-br-ex
> type: patch
> options: {peer=int-br-ex}
> *Port "eno2"*
> Interface "eno2"
> Port br-ex
> Interface br-ex
> type: internal
> ovs_version: "2.8.0"
>  
>  
>  
> Looks like this is how it should be configured according to lots of wiki/blog 
> suggestion I have googled, but it doesn’t work as expected, ping from the VM, 
> the tcpdump shows the traffic still go the “eno1” which is the default route 
> on the controller node. 
>  
> Inside of VM
> ubuntu@test-br:~$ ping 8.8.8.8
> PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=38 time=168 ms
> 64 bytes from 8.8.8.8: icmp_seq=2 ttl=38 time=168 ms
> …
>  
> Dump the traffic on the “eno2”, got nothing
> $ sudo tcpdump -nn -i eno2 icmp
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eno2, link-type EN10MB (Ethernet), capture size 262144 bytes
> …
>  
> Dump the traffic on the “eno1” (internal NIC),  catch it!
> $ sudo tcpdump -nn -i eno1 icmp
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
> 16:08:59.609888 IP 192.168.20.132 > 8.8.8.8: ICMP echo request, id 1439, seq 
> 1, length 64
> 16:08:59.781042 IP 8.8.8.8 > 192.168.20.132: ICMP echo reply, id 1439, seq 1, 
> length 64
> 16:09:00.611453 IP 192.168.20.132 > 8.8.8.8: ICMP echo request, id 1439, seq 
> 2, length 64
> 16:09:00.779550 IP 8.8.8.8 > 192.168.20.132: ICMP echo reply, id 1439, seq 2, 
> length 64
>  
>  
> $ sudo ip route
> default via 192.168.18.1 dev eno1  proto static  metric 100
> default via 192.168.8.1 dev eno2  proto static  metric 101
> 169.254.0.0/16 dev docker0  scope link  metric 1000 linkdown
> 172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1 linkdown
> 192.168.8.0/24 dev eno2  proto kernel  scope link  src 192.168.8.101  metric 
> 100
> 192.168.16.0/21 dev eno1  proto kernel  scope link  src 192.168.20.132  
> metric 100
> 192.168.42.0/24 dev br-ex  proto kernel  scope link  src 192.168.42.1
>  
>  
> What’s going wrong here? Do I miss something? Or some service need to be 
> restarted?
>  
> Anyone could help me out?  This question made me sick for many days!  Huge 
> thanks in the advance!
>  
>  
> Best Regards,
> Dave 
>  
> __
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


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

Re: [openstack-dev] [neutron] Question on the OVS configuration

Thanks Slawomir for your reply, so what's the right configuration if I want my 
VM could be able to access external with physical NIC "eno2"?  Do I still need 
add that NIC into "br-ex"?  


Best Regards,
Dave Chen

-Original Message-
From: Slawomir Kaplonski [mailto:skapl...@redhat.com] 
Sent: Friday, June 15, 2018 5:09 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Question on the OVS configuration

Hi,

If You have vxlan network than traffic from it is going via vxlan tunnel which 
is in br-tun bridge instead of br-ex. 

> Wiadomość napisana przez dave.c...@dell.com w dniu 15.06.2018, o godz. 10:17:
> 
> Dear folks,
>  
> I have setup a pretty simple OpenStack cluster in our lab based on devstack, 
> couples of guest VM are running on one controller node (this doesn’t looks 
> like a right behavior anyway),  the Neutron network is configured as OVS + 
> vxlan, the bridge “br-ex” configured as below:
>  
> Bridge br-ex
> Controller "tcp:127.0.0.1:6633"
> is_connected: true
> fail_mode: secure
> Port phy-br-ex
> Interface phy-br-ex
> type: patch
> options: {peer=int-br-ex}
> Port br-ex
> Interface br-ex
> type: internal
> ovs_version: "2.8.0"
>  
>  
>  
> As you see, there is no external physical NIC bound to “br-ex”, so I guess 
> the traffic from the VM to external will use the default route set on the 
> controller node,  since there is a NIC (eno2) that can access external so I 
> bind it to “br-ex” like this: ovs-vsctl add-port br-ex eno2. now the “br-ex” 
> is configured as below:  
>  
> Bridge br-ex
> Controller "tcp:127.0.0.1:6633"
> is_connected: true
> fail_mode: secure
> Port phy-br-ex
> Interface phy-br-ex
> type: patch
> options: {peer=int-br-ex}
> *Port "eno2"*
> Interface "eno2"
> Port br-ex
> Interface br-ex
> type: internal
> ovs_version: "2.8.0"
>  
>  
>  
> Looks like this is how it should be configured according to lots of wiki/blog 
> suggestion I have googled, but it doesn’t work as expected, ping from the VM, 
> the tcpdump shows the traffic still go the “eno1” which is the default route 
> on the controller node. 
>  
> Inside of VM
> ubuntu@test-br:~$ ping 8.8.8.8
> PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=38 time=168 ms
> 64 bytes from 8.8.8.8: icmp_seq=2 ttl=38 time=168 ms …
>  
> Dump the traffic on the “eno2”, got nothing $ sudo tcpdump -nn -i eno2 
> icmp
> tcpdump: verbose output suppressed, use -v or -vv for full protocol 
> decode listening on eno2, link-type EN10MB (Ethernet), capture size 
> 262144 bytes …
>  
> Dump the traffic on the “eno1” (internal NIC),  catch it!
> $ sudo tcpdump -nn -i eno1 icmp
> tcpdump: verbose output suppressed, use -v or -vv for full protocol 
> decode listening on eno1, link-type EN10MB (Ethernet), capture size 
> 262144 bytes
> 16:08:59.609888 IP 192.168.20.132 > 8.8.8.8: ICMP echo request, id 
> 1439, seq 1, length 64
> 16:08:59.781042 IP 8.8.8.8 > 192.168.20.132: ICMP echo reply, id 1439, 
> seq 1, length 64
> 16:09:00.611453 IP 192.168.20.132 > 8.8.8.8: ICMP echo request, id 
> 1439, seq 2, length 64
> 16:09:00.779550 IP 8.8.8.8 > 192.168.20.132: ICMP echo reply, id 1439, 
> seq 2, length 64
>  
>  
> $ sudo ip route
> default via 192.168.18.1 dev eno1  proto static  metric 100 default 
> via 192.168.8.1 dev eno2  proto static  metric 101
> 169.254.0.0/16 dev docker0  scope link  metric 1000 linkdown
> 172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1 
> linkdown
> 192.168.8.0/24 dev eno2  proto kernel  scope link  src 192.168.8.101  
> metric 100
> 192.168.16.0/21 dev eno1  proto kernel  scope link  src 192.168.20.132  
> metric 100
> 192.168.42.0/24 dev br-ex  proto kernel  scope link  src 192.168.42.1
>  
>  
> What’s going wrong here? Do I miss something? Or some service need to be 
> restarted?
>  
> Anyone could help me out?  This question made me sick for many days!  Huge 
> thanks in the advance!
>  
>  
> Best Regards,
> Dave
>  
> __
>  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

—
Slawek Kaplonski
Senior software engineer
Red Hat


__
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

Re: [openstack-dev] [neutron] Question on the OVS configuration