[Openstack] [Fuel] How to set bonding included admin network by using network template?

[Eddie Yen]

Hi everyone,

I'm using Fuel community 11 to install Openstack, and I'm using network
template to set the network for my own reason.

I tried to set bonding with 2 NICs, and bonding mode is 6 (blanace-alb).
Then planned all networks going to do tagged VLAN except PXE network, and
all networks are going to use bonding interface as traffic.

network_scheme:
  bond_setup:
transformations:
  - action: add-bond
bond_properties:
  mode: balance-alb
  type__: linux
  xmit_hash_policy: layer2
  lacp_rate: fast
interface_properties: {}
interfaces:
- <% if1 %>
- <% if2 %>
name: bond0
endpoints:
  - bond0
roles:
  fake/use: br-fake
  fuel_fw_admin:
transformations:
  - action: add-br
name: br-fw-admin
  - action: add-port
bridge: br-fw-admin
name: bond0
endpoints:
  - br-fw-admin
roles:
  admin/pxe: br-fw-admin
  fw-admin: br-fw-admin

Now the problem is, I tried to upload this template to my environment, but
it says :

Networks cannot be assigned as interface with named bond0 does not exist
for node.

Already searched the internet but no answer.
Can someone help me?
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [cloudkitty] IRC meetings and community

[Tony Breeds]

On Wed, Nov 07, 2018 at 08:35:02PM +0100, Luka Peschke wrote:

> Here's the patch: https://review.openstack.org/#/c/616205/. If it is not
> merged by Friday (date of the first meeting), I'll send the log of the first
> meeting to this ML.

Even if the above doesn't merge you can still use #startmeeting in
#cloudkitty and the logs will be published to eavesdrop.  The chnage you
submitted its just about raising visibility not access control.

Yours Tony.


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] Diversity and Inclusion at OpenStack Summit

[Amy Marrich]

I just wanted to pass on a few things we have going on during Summit that
might be of interest!

*Diversity and Inclusion GroupMe* - Is it your first summit and you don't
know anyone else? Maybe you just don't want to travel to and from the venue
alone? In the tradition of WoO, I have created a GroupMe so people can
communicate with each other. If you would like to be added to the group
please let me know and I'll get you added!

*Night Watch Tour *- On Wednesday night at 10PM, members of the community
will be meeting up to go on a private Night Watch Tour[0]! This is a
non-alcoholic activity for those wanting to get with other Stackers, but
don't want to partake in the Pub Crawl! We've been doing these since Boston
and they're a lot of fun. The cost is 15 euros cash and I do need you to
RSVP to me as we will need to get a second guide if we grow too large!

Summit sessions you may wish to attend:
Tuesday -
*Speed Mentoring Lunch* [1] 12:30 -1:40 - We are still looking for both
Mentors and Mentees for the session so please RSVP! This is another great
way to meet people in the community, learn more and give back!!!
*Cohort Mentoring BoF* [2] 4:20 - 5:00 - Come talk to the people in charge
of the Cohort Mentoring program and see how you can get involved as a
Mentor or Mentee!
*D WG Update* [3] 5:10- 5:50 - Learn what we've been up to, how you can
get involved, and what's next.

Wednesday -
*Git and Gerrit Hands-On Workshop* [4] 3:20 - 4:20 - So you've seen some
exciting stuff this week but don't know how to get setup to start
contributing? This session is for you in that we'll walk you through
getting your logins, your system configured and if time allows even how to
submit a bug and patch!

Thursday -
*Mentoring Program Reboot* [5] 3:20 - 4:00 - Learn about the importance of
mentoring, the changes in the OPenStack mentoring programs and how you can
get involved.

Hope to see everyone in Berlin next week! Please feel free to contact me or
grab me in the hall next week with any questions or to join in the fun!

Amy Marrich (spotz)
Diversity and Inclusion WG Chair

[0] - http://baerentouren.de/nachtwache_en.html
[1] - https://www.openstack.org/summit/berlin-2018/summit-
schedule/events/22873/speed-mentoring-lunch
[2] - https://www.openstack.org/summit/berlin-2018/summit-
schedule/events/22892/long-term-mentoring-keeping-the-party-going
[3] - https://www.openstack.org/summit/berlin-2018/summit-
schedule/events/22893/diversity-and-inclusion-wg-update
[4] - https://www.openstack.org/summit/berlin-2018/summit-
schedule/events/21943/git-and-gerrit-hands-on-workshop
[5] - https://www.openstack.org/summit/berlin-2018/summit-
schedule/events/22443/mentoring-program-reboot
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack-operators] [all] Results of the T release naming poll. open

[Tony Breeds]

Hello all!
The results of the naming poll are in!

**PLEASE REMEMBER** that these now have to go through legal vetting. So
it is too soon to say 'OpenStack Train' is our next release, given that
previous polls have had some issues with the top choice.

In any case, the names will be sent off to legal for vetting. As soon as
we have a final winner, I'll let you all know.

https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_aac97f1cbb6c61df=7c8b5588574494c1

Result
1. Train  (Condorcet winner: wins contests with all other choices)
2. Tiger  loses to Train by 142–70
3. Timber  loses to Train by 142–72, loses to Tiger by 100–76
4. Trail  loses to Train by 150–55, loses to Timber by 93–62
5. Telluride  loses to Train by 155–56, loses to Trail by 81–69
6. Teller  loses to Train by 158–46, loses to Telluride by 70–67
7. Treasure  loses to Train by 151–52, loses to Teller by 68–67
8. Teakettle  loses to Train by 158–49, loses to Treasure by 75–67
9. Tincup  loses to Train by 157–47, loses to Teakettle by 67–60
10. Turret  loses to Train by 158–48, loses to Tincup by 75–56
11. Thomas  loses to Train by 159–42, loses to Turret by 66–63
12. Trinidad  loses to Train by 153–44, loses to Thomas by 70–56
13. Troublesome  loses to Train by 165–41, loses to Trinidad by 69–62
14. Thornton  loses to Train by 163–35, loses to Troublesome by 62–59
15. Tyrone  loses to Train by 163–35, loses to Thornton by 58–38
16. Tarryall  loses to Train by 170–31, loses to Tyrone by 54–50
17. Timnath  loses to Train by 170–23, loses to Tarryall by 60–32
18. Tiny Town  loses to Train by 168–29, loses to Timnath by 45–43
19. Torreys  loses to Train by 167–29, loses to Tiny Town by 48–40
20. Trussville  loses to Train by 169–25, loses to Torreys by 43–34


signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack] [all] Results of the T release naming poll. open

[Tony Breeds]

Hello all!
The results of the naming poll are in!

**PLEASE REMEMBER** that these now have to go through legal vetting. So
it is too soon to say 'OpenStack Train' is our next release, given that
previous polls have had some issues with the top choice.

In any case, the names will be sent off to legal for vetting. As soon as
we have a final winner, I'll let you all know.

https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_aac97f1cbb6c61df=7c8b5588574494c1

Result
1. Train  (Condorcet winner: wins contests with all other choices)
2. Tiger  loses to Train by 142–70
3. Timber  loses to Train by 142–72, loses to Tiger by 100–76
4. Trail  loses to Train by 150–55, loses to Timber by 93–62
5. Telluride  loses to Train by 155–56, loses to Trail by 81–69
6. Teller  loses to Train by 158–46, loses to Telluride by 70–67
7. Treasure  loses to Train by 151–52, loses to Teller by 68–67
8. Teakettle  loses to Train by 158–49, loses to Treasure by 75–67
9. Tincup  loses to Train by 157–47, loses to Teakettle by 67–60
10. Turret  loses to Train by 158–48, loses to Tincup by 75–56
11. Thomas  loses to Train by 159–42, loses to Turret by 66–63
12. Trinidad  loses to Train by 153–44, loses to Thomas by 70–56
13. Troublesome  loses to Train by 165–41, loses to Trinidad by 69–62
14. Thornton  loses to Train by 163–35, loses to Troublesome by 62–59
15. Tyrone  loses to Train by 163–35, loses to Thornton by 58–38
16. Tarryall  loses to Train by 170–31, loses to Tyrone by 54–50
17. Timnath  loses to Train by 170–23, loses to Tarryall by 60–32
18. Tiny Town  loses to Train by 168–29, loses to Timnath by 45–43
19. Torreys  loses to Train by 167–29, loses to Tiny Town by 48–40
20. Trussville  loses to Train by 169–25, loses to Torreys by 43–34


signature.asc
Description: PGP signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [all] Results of the T release naming poll. open

[Tony Breeds]

Hello all!
The results of the naming poll are in!

**PLEASE REMEMBER** that these now have to go through legal vetting. So
it is too soon to say 'OpenStack Train' is our next release, given that
previous polls have had some issues with the top choice.

In any case, the names will be sent off to legal for vetting. As soon as
we have a final winner, I'll let you all know.

https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_aac97f1cbb6c61df=7c8b5588574494c1

Result
1. Train  (Condorcet winner: wins contests with all other choices)
2. Tiger  loses to Train by 142–70
3. Timber  loses to Train by 142–72, loses to Tiger by 100–76
4. Trail  loses to Train by 150–55, loses to Timber by 93–62
5. Telluride  loses to Train by 155–56, loses to Trail by 81–69
6. Teller  loses to Train by 158–46, loses to Telluride by 70–67
7. Treasure  loses to Train by 151–52, loses to Teller by 68–67
8. Teakettle  loses to Train by 158–49, loses to Treasure by 75–67
9. Tincup  loses to Train by 157–47, loses to Teakettle by 67–60
10. Turret  loses to Train by 158–48, loses to Tincup by 75–56
11. Thomas  loses to Train by 159–42, loses to Turret by 66–63
12. Trinidad  loses to Train by 153–44, loses to Thomas by 70–56
13. Troublesome  loses to Train by 165–41, loses to Trinidad by 69–62
14. Thornton  loses to Train by 163–35, loses to Troublesome by 62–59
15. Tyrone  loses to Train by 163–35, loses to Thornton by 58–38
16. Tarryall  loses to Train by 170–31, loses to Tyrone by 54–50
17. Timnath  loses to Train by 170–23, loses to Tarryall by 60–32
18. Tiny Town  loses to Train by 168–29, loses to Timnath by 45–43
19. Torreys  loses to Train by 167–29, loses to Tiny Town by 48–40
20. Trussville  loses to Train by 169–25, loses to Torreys by 43–34


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] [cinder][manila] Cinder and Friends Dinner at Berlin Summit ...

[Jay S Bryant]

All,

I am working on scheduling a dinner for the Cinder team (and our 
extended family that work on and around Cinder) during the Summit in 
Berlin.  I have created an etherpad for people to RSVP for dinner [1].


It seemed like Tuesday night after the Marketplace Mixer was the best 
time for most people.


So, it will be a little later dinner ... 8 pm.  Here is the place:

Location: http://www.dicke-wirtin.de/
Address:  Carmerstraße 9, 10623 Berlin, Germany

It looks like the kind of place that will fit for our usual group.

If planning to attend please add your name to the etherpad and I will 
get a reservation in over the weekend.


Hope to see you all on Tuesday!

Jay

[1] https://etherpad.openstack.org/p/BER-cinder-outing-planning

__
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] CI is broken

[Emilien Macchi]

No alert anymore, gate is green.
recheck if needed.

On Wed, Nov 7, 2018 at 2:22 PM Emilien Macchi  wrote:

> I updated the bugs, and so far we have one alert left:
> https://bugs.launchpad.net/tripleo/+bug/1801969
>
> The patch is in gate, be patient and then we'll be able to +A/recheck
> stuff again.
>
> On Wed, Nov 7, 2018 at 7:30 AM Juan Antonio Osorio Robles <
> jaosor...@redhat.com> wrote:
>
>> Hello folks,
>>
>>
>> Please do not attempt to merge or recheck patches until we get this
>> sorted out.
>>
>> We are dealing with several issues that have broken all jobs.
>>
>> https://bugs.launchpad.net/tripleo/+bug/1801769
>> https://bugs.launchpad.net/tripleo/+bug/1801969
>> https://bugs.launchpad.net/tripleo/+bug/1802083
>> https://bugs.launchpad.net/tripleo/+bug/1802085
>>
>> Best Regards!
>>
>>
>> __
>> 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
>


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

[openstack-dev] [oslo] Next two meetings

[Ben Nemec]

Hi,

Next week is summit and a lot of our contributors will be traveling 
there on Monday, so let's skip the meeting. The following week I will 
also be out, so if anyone wants to run the meeting please let me know. 
Otherwise we'll skip that one too and reconvene after Thanksgiving.


If you need your Oslo fix for next week, come see us in Berlin: 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22952/oslo-project-onboarding


(I just noticed that is listed as a project onboarding - it's actually a 
project update. I'll look into getting that fixed)


-Ben

__
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] [octavia] Weekly meeting is cancelled 11/7/18

[Michael Johnson]

We decided to cancel the weekly Octavia IRC meeting next week due to
the OpenStack Summit in Berlin.

Some of the Octavia related sessions:

Octavia - Project Onboarding - Tue 13, 3:20pm - 4:00pm
Extending Your OpenStack Troubleshooting Tool Box - Digging deeper
into network operations - Wed 14, 11:00am - 12:30pm
Migrate from neutron LBaaS to Octavia LoadBalancing - Wed 14, 1:40pm - 2:20pm
How to make a Kubernetes app from an OpenStack service? Tale of
kuryr-kubernetes' "kubernetization" - Thu 15, 10:50am - 11:30am
Octavia - Project Update - Thu 15, 2:35pm - 2:55pm

Michael

__
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] No n-sch meeting next week

[Eric Fried]

...due to summit.

-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] [cloudkitty] IRC meetings and community

[Doug Hellmann]

Luka Peschke  writes:

> Hello Doug,
>
> Here's the patch: https://review.openstack.org/#/c/616205/. If it is 
> not merged by Friday (date of the first meeting), I'll send the log of 
> the first meeting to this ML.
>
> Luka

I was mostly concerned with future meetings, so that sounds like a good
plan.

Thanks!

>
> Le 2018-11-07 18:43, Doug Hellmann a écrit :
>> Luka Peschke  writes:
>> 
>>> Hello,
>>> 
>>> I'm making this e-mail to announce that the CloudKitty project will 
>>> be
>>> holding IRC meetings from now on. They will be held in the 
>>> #cloudkitty
>>> channel on Freenode. They should (for now) be held on the first 
>>> Friday
>>> of each month at 15h00 UTC. Of course, the time / frequency can be
>>> adapted to what suits the community the best.
>>> 
>>> The first meeting will be an exception to this schedule. It will be
>>> held on Friday the 9th of November at 15h00 UTC. Topics for this 
>>> meeting
>>> can be found and proposed at
>>> https://etherpad.openstack.org/p/cloudkitty-meeting-topics
>>> 
>>> These meetings were a thing in the project's early days and have 
>>> slowly
>>> stopped, which we really regret.
>>> 
>>> This is part of a larger effort to get more in touch with the
>>> community. We would gladly welcome new contributors, and any
>>> contribution of any kind (bug report, review, documentation
>>> suggestion/update, commit...),  is welcome. There are several points
>>> which should be tackled in order to ease interactions with the
>>> community. These will be detailled and discussed during the first
>>> meeting.
>>> 
>>> For those interested in CloudKitty attending the Berlin summit, the
>>> Project Update will happen on the 14/11 at 2:30pm in M-Räum 3 and the
>>> onboarding will be held on the 14/11 at 5:10pm in M-Räum 1.
>>> 
>>> Cheers,
>>> 
>>> Luka
>>> 
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> Thanks, Luka.
>> 
>> Please propose an update to the openstack-infra/irc-meetings 
>> repository
>> to register the meeting info so it shows up on eavesdrop.openstack.org
>> and the calendar published there. That will make it easier for other
>> folks to find the meeting and keep it on their schedule.

-- 
Doug

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

[openstack-dev] [TripleO] Edge squad meeting this week and next week

[James Slagle]

I won't be around to run the Edge squad meeting this week and next
week. If someone else wants to pick it up, that would be great.
Otherwise, consider it cancelled :). Thanks!

https://etherpad.openstack.org/p/tripleo-edge-squad-status

-- 
-- James Slagle
--

__
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] [cloudkitty] IRC meetings and community

[Luka Peschke]

Hello Doug,

Here's the patch: https://review.openstack.org/#/c/616205/. If it is 
not merged by Friday (date of the first meeting), I'll send the log of 
the first meeting to this ML.


Luka

Le 2018-11-07 18:43, Doug Hellmann a écrit :

Luka Peschke  writes:


Hello,

I'm making this e-mail to announce that the CloudKitty project will 
be
holding IRC meetings from now on. They will be held in the 
#cloudkitty
channel on Freenode. They should (for now) be held on the first 
Friday

of each month at 15h00 UTC. Of course, the time / frequency can be
adapted to what suits the community the best.

The first meeting will be an exception to this schedule. It will be
held on Friday the 9th of November at 15h00 UTC. Topics for this 
meeting

can be found and proposed at
https://etherpad.openstack.org/p/cloudkitty-meeting-topics

These meetings were a thing in the project's early days and have 
slowly

stopped, which we really regret.

This is part of a larger effort to get more in touch with the
community. We would gladly welcome new contributors, and any
contribution of any kind (bug report, review, documentation
suggestion/update, commit...),  is welcome. There are several points
which should be tackled in order to ease interactions with the
community. These will be detailled and discussed during the first
meeting.

For those interested in CloudKitty attending the Berlin summit, the
Project Update will happen on the 14/11 at 2:30pm in M-Räum 3 and the
onboarding will be held on the 14/11 at 5:10pm in M-Räum 1.

Cheers,

Luka


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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Thanks, Luka.

Please propose an update to the openstack-infra/irc-meetings 
repository

to register the meeting info so it shows up on eavesdrop.openstack.org
and the calendar published there. That will make it easier for other
folks to find the meeting and keep it on their 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

Re: [openstack-dev] [tripleo] CI is broken

[Emilien Macchi]

I updated the bugs, and so far we have one alert left:
https://bugs.launchpad.net/tripleo/+bug/1801969

The patch is in gate, be patient and then we'll be able to +A/recheck stuff
again.

On Wed, Nov 7, 2018 at 7:30 AM Juan Antonio Osorio Robles <
jaosor...@redhat.com> wrote:

> Hello folks,
>
>
> Please do not attempt to merge or recheck patches until we get this
> sorted out.
>
> We are dealing with several issues that have broken all jobs.
>
> https://bugs.launchpad.net/tripleo/+bug/1801769
> https://bugs.launchpad.net/tripleo/+bug/1801969
> https://bugs.launchpad.net/tripleo/+bug/1802083
> https://bugs.launchpad.net/tripleo/+bug/1802085
>
> Best Regards!
>
>
> __
> 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

Re: [openstack-dev] [cloudkitty] IRC meetings and community

[Doug Hellmann]

Luka Peschke  writes:

> Hello,
>
> I'm making this e-mail to announce that the CloudKitty project will be 
> holding IRC meetings from now on. They will be held in the #cloudkitty 
> channel on Freenode. They should (for now) be held on the first Friday 
> of each month at 15h00 UTC. Of course, the time / frequency can be 
> adapted to what suits the community the best.
>
> The first meeting will be an exception to this schedule. It will be 
> held on Friday the 9th of November at 15h00 UTC. Topics for this meeting 
> can be found and proposed at 
> https://etherpad.openstack.org/p/cloudkitty-meeting-topics
>
> These meetings were a thing in the project's early days and have slowly 
> stopped, which we really regret.
>
> This is part of a larger effort to get more in touch with the 
> community. We would gladly welcome new contributors, and any 
> contribution of any kind (bug report, review, documentation 
> suggestion/update, commit...),  is welcome. There are several points 
> which should be tackled in order to ease interactions with the 
> community. These will be detailled and discussed during the first 
> meeting.
>
> For those interested in CloudKitty attending the Berlin summit, the 
> Project Update will happen on the 14/11 at 2:30pm in M-Räum 3 and the 
> onboarding will be held on the 14/11 at 5:10pm in M-Räum 1.
>
> Cheers,
>
> Luka
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Thanks, Luka.

Please propose an update to the openstack-infra/irc-meetings repository
to register the meeting info so it shows up on eavesdrop.openstack.org
and the calendar published there. That will make it easier for other
folks to find the meeting and keep it on their schedule.

-- 
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] [Openstack-operators] FIPS Compliance

[Doug Hellmann]

Joshua Cornutt  writes:

> On Wed, Nov 7, 2018 at 7:30 AM Doug Hellmann  wrote:
>>
>> Joshua Cornutt  writes:
>>
>> > Doug,
>> >
>> > I have such a list put together (my various installation documents for
>> > getting these clouds working in FIPS mode) but it's hardly ready for
>> > public consumption. I planned on releasing each bit as a code change
>> > and/or bug ticket and letting the community consume it as it figures
>> > some of these things out.
>>
>> It's likely that the overall migration will go better if we all have the
>> full context. So I hope you can find some time to publish some of the
>> information you've compiled to help with that.
>>
>> > I agree that some changes may break backwards compatibility (such as
>> > Glance's image checksumming), but one approach I think could ease the
>> > transition would be the approach I took for SSH key pair
>> > fingerprinting (also MD5-based, as is Glance image checksums) found
>> > here - https://review.openstack.org/#/c/615460/ . This allows
>> > administrators to choose, hopefully at deployment time, the hashing
>> > algorithm with the default of being the existing MD5 algorithm.
>>
>> That certainly seems like it would provide the most compatibility in the
>> short term.
>>
>> That said, I honestly don't know the best approach for us to take. We're
>> going to need people who understand the issues around FIPS and the
>> issues around maintaining backwards-compatibility to work together to
>> create a recommended approach. Perhaps a few of the folks on this thread
>> would be interested in forming a team to work on that?
>>
>> Doug
>>
>
> I'd be interested in that. Good idea

I added "FIPS compliance" to the list of community goal ideas in
https://etherpad.openstack.org/p/community-goals (see number 35,
currently at the bottom of the etherpad).

Please add more detail there about what exactly is involved, references,
etc. -- whatever you think would be useful to someone learning about
what this is.

>
>> > Another approach would be to make the projects "FIPS aware" where we
>> > choose the hashing algorithm based on the system's FIPS-enforcing
>> > state. An example of doing so is what I'm proposing for Django
>> > (another FIPS-related patch that was needed for OSP 13) -
>> > https://github.com/django/django/pull/10605
>> >
>> > __
>> > 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

-- 
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] [publiccloud-wg] Serving vendor json from RFC 5785 well-known dir

[Monty Taylor]

On 11/5/18 3:21 AM, Mohammed Naser wrote:



Sent from my iPhone


On Nov 5, 2018, at 10:19 AM, Thierry Carrez  wrote:

Monty Taylor wrote:

[...]
What if we added support for serving vendor data files from the root of a 
primary URL as-per RFC 5785. Specifically, support deployers adding a json file 
to .well-known/openstack/client that would contain what we currently store in 
the openstacksdk repo and were just discussing splitting out.
[...]
What do people think?


I love the idea of public clouds serving that file directly, and the user 
experience you get from it. The only two drawbacks on top of my head would be:

- it's harder to discover available compliant openstack clouds from the client.

- there is no vetting process, so there may be failures with weird clouds 
serving half-baked files that people may blame the client tooling for.

I still think it's a good idea, as in theory it aligns the incentive of 
maintaining the file with the most interested stakeholder. It just might need 
some extra communication to work seamlessly.


I’m thinking out loud here but perhaps a simple linter that a cloud provider 
can run will help them make sure that everything is functional.


I've got an initial patch up:

WIP Support remote vendor profiles https://review.openstack.org/616228

it works with vexxhost's published vendor file.


__
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] [cyborg]Weekly Meeting

[Jeremy Stanley]

On 2018-11-07 10:02:52 -0500 (-0500), Li Liu wrote:
> It seems the meeting bot is having issues.. I would just paste the
> meeting log here
[...]

The meetbot wasn't having any issues. The chair didn't issue an
#endmeeting, and only a meeting chair is allowed to do so until an
hour has elapsed from the #startmeeting. After an hour, anyone can
so I did an #endmeeting in your channel and it wrapped up and wrote
the minutes and logs as usual:

http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-11-07-14.16.html

-- 
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] [PackStack][Neutron] erro port no present in bridge br-int

[Soheil Pourbafrani]

Thank you for the clarification, Laszlo.

On Wed, Nov 7, 2018 at 5:39 PM Budai Laszlo  wrote:

> Hi,
>
> please don't misunderstand me. If you have multiple nodes, then each of
> them will have its own ``host`` setting (like, host = node1 for node1 and
> host = node2 for node2). The important thing is that both the neutron.conf
> and nova.conf to have the same ``host`` setting on one node. So if you have
> used the ``host = node1`` in neutron.conf of node1, then do the same in the
> nova.conf on the same host. And if you have ``host = node2`` in
> neutron.conf on node2, then you should have the same in the nova.conf.
>
> Kind regards,
> Laszlo
>
>
> On 11/7/18 2:52 PM, Soheil Pourbafrani wrote:
> > Thanks. In one node installation no error happened but in two node
> installation, I got the error. So I guess the answer of Laszlo is
> reasonable.
> >
> > On Wed, Nov 7, 2018 at 10:23 AM Budai Laszlo  > wrote:
> >
> > Hi
> >
> > we had a similar situation when the ``host`` entry in the
> neutron.conf was different than the host entry in the nova.conf on the
> compute nodes.
> > So if you're setting a ``host`` entry in one of these files, then
> make sure the other file contains the same ``host`` setting.
> >
> > see
> https://docs.openstack.org/neutron/rocky/configuration/neutron.html#DEFAULT.host
> and
> https://docs.openstack.org/nova/rocky/configuration/config.html#DEFAULT.host
> >
> > Kind regards,
> > Laszlo
> >
> > On 11/6/18 6:04 PM, Akihiro Motoki wrote:
> >  > How is your [ovs] bridge_mapping in your configuration?
> >  > Flat network requires a corresponding bridge_mapping entry and
> you also need to create a corresponding bridge in advance.
> >  >
> >  >
> >  > 2018年11月6日(火) 21:31 Soheil Pourbafrani   >>:
> >  >
> >  > Hi, I initilize an instance using a defined flat network and
> I got the error:
> >  > port no present in bridge br-int
> >  >
> >  > I have a 2 node deployment (controller + network, compute).
> >  >
> >  > The output of the command ovs-vsctl show is
> >  > *
> >  > *
> >  > *On the network node*
> >  > d3a06f16-d727-4333-9de6-cf4ce3b0ce36
> >  >  Manager "ptcp:6640:127.0.0.1"
> >  >  is_connected: true
> >  >  Bridge br-ex
> >  >  Controller "tcp:127.0.0.1:6633 <
> http://127.0.0.1:6633> "
> >  >  is_connected: true
> >  >  fail_mode: secure
> >  >  Port br-ex
> >  >  Interface br-ex
> >  >  type: internal
> >  >  Port phy-br-ex
> >  >  Interface phy-br-ex
> >  >  type: patch
> >  >  options: {peer=int-br-ex}
> >  >  Port "ens33"
> >  >  Interface "ens33"
> >  >  Bridge br-int
> >  >  Controller "tcp:127.0.0.1:6633 <
> http://127.0.0.1:6633> "
> >  >  is_connected: true
> >  >  fail_mode: secure
> >  >  Port br-int
> >  >  Interface br-int
> >  >  type: internal
> >  >  Port patch-tun
> >  >  Interface patch-tun
> >  >  type: patch
> >  >  options: {peer=patch-int}
> >  >  Port int-br-ex
> >  >  Interface int-br-ex
> >  >  type: patch
> >  >  options: {peer=phy-br-ex}
> >  >  Port "tapefb98047-57"
> >  >  tag: 1
> >  >  Interface "tapefb98047-57"
> >  >  type: internal
> >  >  Port "qr-d62d0c14-51"
> >  >  tag: 1
> >  >  Interface "qr-d62d0c14-51"
> >  >  type: internal
> >  >  Port "qg-5468707b-6d"
> >  >  tag: 2
> >  >  Interface "qg-5468707b-6d"
> >  >  type: internal
> >  >  Bridge br-tun
> >  >  Controller "tcp:127.0.0.1:6633 <
> http://127.0.0.1:6633> "
> >  >  is_connected: true
> >  >  fail_mode: secure
> >  >  Port patch-int
> >  >  Interface patch-int
> >  >  type: patch
> >  >  options: {peer=patch-tun}
> >  >  Port br-tun
> >  >  Interface br-tun
> >  >  type: internal
> >  >  Port "vxlan-c0a8003d"
> >  >  Interface "vxlan-c0a8003d"
> > 

[openstack-dev] [cloudkitty] IRC meetings and community

[Luka Peschke]

Hello,

I'm making this e-mail to announce that the CloudKitty project will be 
holding IRC meetings from now on. They will be held in the #cloudkitty 
channel on Freenode. They should (for now) be held on the first Friday 
of each month at 15h00 UTC. Of course, the time / frequency can be 
adapted to what suits the community the best.


The first meeting will be an exception to this schedule. It will be 
held on Friday the 9th of November at 15h00 UTC. Topics for this meeting 
can be found and proposed at 
https://etherpad.openstack.org/p/cloudkitty-meeting-topics


These meetings were a thing in the project's early days and have slowly 
stopped, which we really regret.


This is part of a larger effort to get more in touch with the 
community. We would gladly welcome new contributors, and any 
contribution of any kind (bug report, review, documentation 
suggestion/update, commit...),  is welcome. There are several points 
which should be tackled in order to ease interactions with the 
community. These will be detailled and discussed during the first 
meeting.


For those interested in CloudKitty attending the Berlin summit, the 
Project Update will happen on the 14/11 at 2:30pm in M-Räum 3 and the 
onboarding will be held on the 14/11 at 5:10pm in M-Räum 1.


Cheers,

Luka


__
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] [python3] Enabling py37 unit tests

[Clark Boylan]

On Wed, Nov 7, 2018, at 4:47 AM, Mohammed Naser wrote:
> On Wed, Nov 7, 2018 at 1:37 PM Doug Hellmann  wrote:
> >
> > Corey Bryant  writes:
> >
> > > On Wed, Oct 10, 2018 at 8:45 AM Corey Bryant 
> > > wrote:
> > >
> > > I'd like to start moving forward with enabling py37 unit tests for a 
> > > subset
> > > of projects. Rather than putting too much load on infra by enabling 3 x 
> > > py3
> > > unit tests for every project, this would just focus on enablement of py37
> > > unit tests for a subset of projects in the Stein cycle. And just to be
> > > clear, I would not be disabling any unit tests (such as py35). I'd just be
> > > enabling py37 unit tests.
> > >
> > > As some background, this ML thread originally led to updating the
> > > python3-first governance goal (https://review.openstack.org/#/c/610708/)
> > > but has now led back to this ML thread for a +1 rather than updating the
> > > governance goal.
> > >
> > > I'd like to get an official +1 here on the ML from parties such as the TC
> > > and infra in particular but anyone else's input would be welcomed too.
> > > Obviously individual projects would have the right to reject proposed
> > > changes that enable py37 unit tests. Hopefully they wouldn't, of course,
> > > but they could individually vote that way.
> > >
> > > Thanks,
> > > Corey
> >
> > This seems like a good way to start. It lets us make incremental
> > progress while we take the time to think about the python version
> > management question more broadly. We can come back to the other projects
> > to add 3.7 jobs and remove 3.5 jobs when we have that plan worked out.
> 
> What's the impact on the number of consumption in upstream CI node usage?
> 

For period from 2018-10-25 15:16:32,079 to 2018-11-07 15:59:04,994, 
openstack-tox-py35 jobs in aggregate represent 0.73% of our total capacity 
usage.

I don't expect py37 to significantly deviate from that. Again the major 
resource consumption is dominated by a small number of projects/repos/jobs. 
Generally testing outside of that bubble doesn't represent a significant 
resource cost.

I see no problem with adding python 3.7 unit testing from an infrastructure 
perspective.

Clark

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

[openstack-dev] [kolla] Meeting 14-nov-2018 canceled

[Eduardo Gonzalez]

Dear Kolla Team,

Due to the OpenStack Summit in Berlin, the Kolla weekly meeting on
Wednesday 14th is canceled.

Best regards
__
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-operators] Diversity and Inclusion at OpenStack Summit

[Amy Marrich]

I just wanted to pass on a few things we have going on during Summit that
might be of interest!

*Diversity and Inclusion GroupMe* - Is it your first summit and you don't
know anyone else? Maybe you just don't want to travel to and from the venue
alone? In the tradition of WoO, I have created a GroupMe so people can
communicate with each other. If you would like to be added to the group
please let me know and I'll get you added!

*Night Watch Tour *- On Wednesday night at 10PM, members of the community
will be meeting up to go on a private Night Watch Tour[0]! This is a
non-alcoholic activity for those wanting to get with other Stackers, but
don't want to partake in the Pub Crawl! We've been doing these since Boston
and they're a lot of fun. The cost is 15 euros cash and I do need you to
RSVP to me as we will need to get a second guide if we grow too large!

Summit sessions you may wish to attend:
Tuesday -
*Speed Mentoring Lunch* [1] 12:30 -1:40 - We are still looking for both
Mentors and Mentees for the session so please RSVP! This is another great
way to meet people in the community, learn more and give back!!!
*Cohort Mentoring BoF* [2] 4:20 - 5:00 - Come talk to the people in charge
of the Cohort Mentoring program and see how you can get involved as a
Mentor or Mentee!
*D WG Update* [3] 5:10- 5:50 - Learn what we've been up to, how you can
get involved, and what's next.

Wednesday -
*Git and Gerrit Hands-On Workshop* [4] 3:20 - 4:20 - So you've seen some
exciting stuff this week but don't know how to get setup to start
contributing? This session is for you in that we'll walk you through
getting your logins, your system configured and if time allows even how to
submit a bug and patch!

Thursday -
*Mentoring Program Reboot* [5] 3:20 - 4:00 - Learn about the importance of
mentoring, the changes in the OPenStack mentoring programs and how you can
get involved.

Hope to see everyone in Berlin next week! Please feel free to contact me or
grab me in the hall next week with any questions or to join in the fun!

Amy Marrich (spotz)
Diversity and Inclusion WG Chair

[0] - http://baerentouren.de/nachtwache_en.html
[1] -
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22873/speed-mentoring-lunch
[2] -
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22892/long-term-mentoring-keeping-the-party-going
[3] -
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22893/diversity-and-inclusion-wg-update
[4] -
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/21943/git-and-gerrit-hands-on-workshop
[5] -
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22443/mentoring-program-reboot
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] Diversity and Inclusion at OpenStack Summit

[Amy Marrich]

I just wanted to pass on a few things we have going on during Summit that
might be of interest!

*Diversity and Inclusion GroupMe* - Is it your first summit and you don't
know anyone else? Maybe you just don't want to travel to and from the venue
alone? In the tradition of WoO, I have created a GroupMe so people can
communicate with each other. If you would like to be added to the group
please let me know and I'll get you added!

*Night Watch Tour *- On Wednesday night at 10PM, members of the community
will be meeting up to go on a private Night Watch Tour[0]! This is a
non-alcoholic activity for those wanting to get with other Stackers, but
don't want to partake in the Pub Crawl! We've been doing these since Boston
and they're a lot of fun. The cost is 15 euros cash and I do need you to
RSVP to me as we will need to get a second guide if we grow too large!

Summit sessions you may wish to attend:
Tuesday -
*Speed Mentoring Lunch* [1] 12:30 -1:40 - We are still looking for both
Mentors and Mentees for the session so please RSVP! This is another great
way to meet people in the community, learn more and give back!!!
*Cohort Mentoring BoF* [2] 4:20 - 5:00 - Come talk to the people in charge
of the Cohort Mentoring program and see how you can get involved as a
Mentor or Mentee!
*D WG Update* [3] 5:10- 5:50 - Learn what we've been up to, how you can
get involved, and what's next.

Wednesday -
*Git and Gerrit Hands-On Workshop* [4] 3:20 - 4:20 - So you've seen some
exciting stuff this week but don't know how to get setup to start
contributing? This session is for you in that we'll walk you through
getting your logins, your system configured and if time allows even how to
submit a bug and patch!

Thursday -
*Mentoring Program Reboot* [5] 3:20 - 4:00 - Learn about the importance of
mentoring, the changes in the OPenStack mentoring programs and how you can
get involved.

Hope to see everyone in Berlin next week! Please feel free to contact me or
grab me in the hall next week with any questions or to join in the fun!

Amy Marrich (spotz)
Diversity and Inclusion WG Chair

[0] - http://baerentouren.de/nachtwache_en.html
[1] -
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22873/speed-mentoring-lunch
[2] -
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22892/long-term-mentoring-keeping-the-party-going
[3] -
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22893/diversity-and-inclusion-wg-update
[4] -
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/21943/git-and-gerrit-hands-on-workshop
[5] -
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22443/mentoring-program-reboot
__
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] [python3] Enabling py37 unit tests

[Chris Dent]

On Tue, 6 Nov 2018, Corey Bryant wrote:


I'd like to get an official +1 here on the ML from parties such as the TC
and infra in particular but anyone else's input would be welcomed too.
Obviously individual projects would have the right to reject proposed
changes that enable py37 unit tests. Hopefully they wouldn't, of course,
but they could individually vote that way.


Speaking as someone on the TC but not "the TC" as well as someone
active in a few projects: +1. As shown elsewhere in the thread the
impact on node consumption and queue lengths shouldn't be a huge
amount and the benefits are high.


From an openstack/placement standpoint, please go for it if nobody

else beats you to it.

To me the benefits are simply that we find bugs sooner. It's bizarre
to me that we even need to think about this. The sooner we find
them, the less they impact people who want to use our code. Will it
cause breakage and extra work us now? Possibly, but it's like making
an early payment on the mortgage: We are saving cost later.

--
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] [cyborg]Weekly Meeting

[Li Liu]

It seems the meeting bot is having issues.. I would just paste the meeting
log here

[09:19] == Li_Liu [b896edde@gateway/web/freenode/ip.184.150.237.222] has
joined #openstack-cyborg
[09:19]  Hi Xinran
[09:20]  Looks like just we two and maybe Li so far
[09:20]  Hi guyss
[09:20]  Let me ask people in wechat group
[09:20]  Hi Li
[09:20]  Hi
[09:21]  Hi
[09:21]  #wangzhh
[09:21]  Sundar, Did you have the change to look at the spec I
submit last weekend?
[09:21]  #info wangzhh
[09:21]  Hi wangzhh
[09:22]  Hi Sundar.
[09:22]  I know i must still miss things, but I just wanna get the
thing started first
[09:22]  Li: Yes, I had some comments. I am still writing them.
Will post by today.
[09:22]  sure, thanks a lot
[09:22]  #info Li_Liu
[09:23]  ok, let's get started on the business
[09:23]  I think CoCo is still on her way home. but we can go ahead
for the meeting
[09:23]  #topic status updates
[09:23] == Coco_gao [uid312075@gateway/web/irccloud.com/x-rybjocunfidqrgrs]
has joined #openstack-cyborg
[09:24]  Hi CoCo
[09:24]  start with
https://review.openstack.org/#/q/status:open%20project:openstack/cyborg
[09:24]  Storyboard has been updated for db and driver-agent
[09:24]  Some driver-agent tasks probably need tweaks. I'll also
file some for the end-to-end workflow.
[09:24]  regarding "Add Allocation/Deallocation API"
[09:25]  still blocked right? xinran
[09:25]  Apart from that, folks are free to add tasks, modify them
or sign up
[09:25]  Thanks  a lot Sundar :)
[09:25]  Li: np :)
[09:25]  Hi all
[09:26]  #info Coco_gao
[09:26]  is xinran in the meeting
[09:27]  Thanks Sundar，I will check the storyboard to sign up
tomorrow.
[09:28]  Sundar, do you have any input on "Add
Allocation/Deallocation API"?
[09:29]  Yes I'm here
[09:29]  I think we should abandon Add Allocation/Deallocation API
spec, and follow Sundar's new design
[09:30]  That one I saw you adandon the other day.
[09:30]  but for https://review.openstack.org/#/c/596187/
[09:30]  do you wanna abandon it as well?
[09:32] == shaohe_feng [c066cc26@gateway/web/freenode/ip.192.102.204.38]
has joined #openstack-cyborg
[09:32]  #info shaohe
[09:32]  hi all
[09:32]  Hi shaohe.
[09:33]  I think it doesn't matter, I can commit new version
according to new spec. if you guys think it's better to abandon it and
submit another one, that's fine
[09:33]  hi shaohe
[09:33]  xinran, it's totally up to you
[09:33]  That is depends on you
[09:33]  yes, depends on you.
[09:34]  We should probably align on the db schema first. Li_Liu,
do you want to talk about the db spec here ?
[09:34]  "Add gpu driver" xiao hei, your comments on this? still
blocking by the new db design right?
[09:35]  Sundar, that might involve too much tech details once we
start the discussion.
[09:35]  if you think there are too many diffrience  maybe you
can add a new patch
[09:35]  I wanna focus on the status update first, then we can talk
about it
[09:35]  Yes, Li.
[09:35]  ok, thanks xiaohei
[09:36]  "Resource report to placement", xinran, you comments on
this?
[09:36]  yes
[09:36]  my patch is the same problem, still need to implement
new design
[09:37]  thanks coco, got it
[09:38]  alright, I think I got most of the feedback on the patches
status
[09:38]  #topic  New DB scheme planning
[09:39]  Sundar, you wanna talk about the storyboard items you
created?
[09:40]  Li_Liu: Sure. #link
https://storyboard.openstack.org/#!/project/openstack/cyborg
[09:40]  Storyboard has a openstack/cyborg project. We can create
stories for specific features or topics, and tasks within those stories.
[09:42]  We can optionally create worklists and group them into
boards. For example, we could create a worklist for Stein. However, i have
chosen to keep it simple: Stein is just a tag on every story we want to
complete in this release
[09:42]  The tag is a label. we can add more tags as needed
[09:42]  Regarding the DB work, I think there might be changes on
those tasks. Will keep you guys posted
[09:43]  Time to talk about the sb spec?
[09:43]  *db
[09:43]  Yep
[09:44]  I think we all agreed that the new db schema will not be
PCI-specific.
[09:45]  I think so.
[09:46]  Great. I thought we also agreed that Deployables should be
the equivalent of resource providers
[09:47]  "equivalent" might not be precise, I think they are
counter-part of each other
[09:47]  one in the context of Cyborg, the other one in the context
of Nova
[09:47]  That's exactly what I meant by 'equivalent'
[09:47]  Li，is  new db spec availale now?
[09:48]  We had this doc which we reviewed:
https://docs.google.com/document/d/1XLQtvyGJeEgo3ztBQiufWLF-E7S7yGLaYrme8iUPtA0/edit
[09:49]  agree with Li
[09:49]  Can we please align the spec to it? Otherwise, we will
have lots more discussion. The current spec shows a diagram tying
Deployables to PF, VF .
[09:50]  CoCo, check this out #link
https://review.openstack.org/#/c/615462/
[09:50]  Sundar, I think after my spec is finalized, we should get
all the pieces aligned
[09:50]  okay thank you。
[09:51]  

Re: [openstack-dev] [Openstack-operators] FIPS Compliance

[Joshua Cornutt]

On Wed, Nov 7, 2018 at 7:30 AM Doug Hellmann  wrote:
>
> Joshua Cornutt  writes:
>
> > Doug,
> >
> > I have such a list put together (my various installation documents for
> > getting these clouds working in FIPS mode) but it's hardly ready for
> > public consumption. I planned on releasing each bit as a code change
> > and/or bug ticket and letting the community consume it as it figures
> > some of these things out.
>
> It's likely that the overall migration will go better if we all have the
> full context. So I hope you can find some time to publish some of the
> information you've compiled to help with that.
>
> > I agree that some changes may break backwards compatibility (such as
> > Glance's image checksumming), but one approach I think could ease the
> > transition would be the approach I took for SSH key pair
> > fingerprinting (also MD5-based, as is Glance image checksums) found
> > here - https://review.openstack.org/#/c/615460/ . This allows
> > administrators to choose, hopefully at deployment time, the hashing
> > algorithm with the default of being the existing MD5 algorithm.
>
> That certainly seems like it would provide the most compatibility in the
> short term.
>
> That said, I honestly don't know the best approach for us to take. We're
> going to need people who understand the issues around FIPS and the
> issues around maintaining backwards-compatibility to work together to
> create a recommended approach. Perhaps a few of the folks on this thread
> would be interested in forming a team to work on that?
>
> Doug
>

I'd be interested in that. Good idea

> > Another approach would be to make the projects "FIPS aware" where we
> > choose the hashing algorithm based on the system's FIPS-enforcing
> > state. An example of doing so is what I'm proposing for Django
> > (another FIPS-related patch that was needed for OSP 13) -
> > https://github.com/django/django/pull/10605
> >
> > __
> > 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] [PackStack][Neutron] erro port no present in bridge br-int

[Budai Laszlo]

Hi,

please don't misunderstand me. If you have multiple nodes, then each of them 
will have its own ``host`` setting (like, host = node1 for node1 and host = 
node2 for node2). The important thing is that both the neutron.conf and 
nova.conf to have the same ``host`` setting on one node. So if you have used 
the ``host = node1`` in neutron.conf of node1, then do the same in the 
nova.conf on the same host. And if you have ``host = node2`` in neutron.conf on 
node2, then you should have the same in the nova.conf.

Kind regards,
Laszlo


On 11/7/18 2:52 PM, Soheil Pourbafrani wrote:

Thanks. In one node installation no error happened but in two node 
installation, I got the error. So I guess the answer of Laszlo is reasonable.

On Wed, Nov 7, 2018 at 10:23 AM Budai Laszlo mailto:laszlo.bu...@gmail.com>> wrote:

Hi

we had a similar situation when the ``host`` entry in the neutron.conf was 
different than the host entry in the nova.conf on the compute nodes.
So if you're setting a ``host`` entry in one of these files, then make sure 
the other file contains the same ``host`` setting.

see 
https://docs.openstack.org/neutron/rocky/configuration/neutron.html#DEFAULT.host
 and 
https://docs.openstack.org/nova/rocky/configuration/config.html#DEFAULT.host

Kind regards,
Laszlo

On 11/6/18 6:04 PM, Akihiro Motoki wrote:
 > How is your [ovs] bridge_mapping in your configuration?
 > Flat network requires a corresponding bridge_mapping entry and you also 
need to create a corresponding bridge in advance.
 >
 >
 > 2018年11月6日(火) 21:31 Soheil Pourbafrani mailto:soheil.i...@gmail.com> >>:
 >
 >     Hi, I initilize an instance using a defined flat network and I got 
the error:
 >     port no present in bridge br-int
 >
 >     I have a 2 node deployment (controller + network, compute).
 >
 >     The output of the command ovs-vsctl show is
 >     *
 >     *
 >     *On the network node*
 >     d3a06f16-d727-4333-9de6-cf4ce3b0ce36
 >          Manager "ptcp:6640:127.0.0.1"
 >              is_connected: true
 >          Bridge br-ex
 >              Controller "tcp:127.0.0.1:6633  
"
 >                  is_connected: true
 >              fail_mode: secure
 >              Port br-ex
 >                  Interface br-ex
 >                      type: internal
 >              Port phy-br-ex
 >                  Interface phy-br-ex
 >                      type: patch
 >                      options: {peer=int-br-ex}
 >              Port "ens33"
 >                  Interface "ens33"
 >          Bridge br-int
 >              Controller "tcp:127.0.0.1:6633  
"
 >                  is_connected: true
 >              fail_mode: secure
 >              Port br-int
 >                  Interface br-int
 >                      type: internal
 >              Port patch-tun
 >                  Interface patch-tun
 >                      type: patch
 >                      options: {peer=patch-int}
 >              Port int-br-ex
 >                  Interface int-br-ex
 >                      type: patch
 >                      options: {peer=phy-br-ex}
 >              Port "tapefb98047-57"
 >                  tag: 1
 >                  Interface "tapefb98047-57"
 >                      type: internal
 >              Port "qr-d62d0c14-51"
 >                  tag: 1
 >                  Interface "qr-d62d0c14-51"
 >                      type: internal
 >              Port "qg-5468707b-6d"
 >                  tag: 2
 >                  Interface "qg-5468707b-6d"
 >                      type: internal
 >          Bridge br-tun
 >              Controller "tcp:127.0.0.1:6633  
"
 >                  is_connected: true
 >              fail_mode: secure
 >              Port patch-int
 >                  Interface patch-int
 >                      type: patch
 >                      options: {peer=patch-tun}
 >              Port br-tun
 >                  Interface br-tun
 >                      type: internal
 >              Port "vxlan-c0a8003d"
 >                  Interface "vxlan-c0a8003d"
 >                      type: vxlan
 >                      options: {df_default="true", in_key=flow, 
local_ip="192.168.0.62", out_key=flow, remote_ip="192.168.0.61"}
 >          ovs_version: "2.9.0"
 >
 >     *On the Compute node*
 >     *
 >     *
 >     *55e62867-9c88-4925-b49c-55fb74d174bd*
 >     *    Manager "ptcp:6640:127.0.0.1"*
 >     *        is_connected: true*
 >     *    Bridge br-ex*
 >     *        

[Openstack] [glance] Rocky image import stuck

[Bernd Bausch]

Does the new image import process work? Am I missing something? Uploaded
images stay in an intermediate state, either /uploading/ or /importing/,
and never become /active.///Where should I look?/
/

On a stable/Rocky Devstack, I do:

openstack image create --disk-format qcow2 myimg

Image status is /queueing/, as expected.

glance image-stage --file devstack/files/Fedora...qcow2 --progress
IMAGE_ID

Image status is /uploading/. A copy of the image is on
/tmp/staging/IMAGE_ID.

glance image-import --import-method glance-direct IMAGE_ID

Sometimes, the status remains /uploading, /sometimes it turns
/importing, /never /active./

glance-api log grep'd for the image ID:

Nov 07 18:51:36 rocky devstack@g-api.service[1033]: INFO
glance.common.scripts.image_import.main [None
req-7a747213-c160-4423-b703-c6cad15b9217 admin admin] Task
ec4b36fd-dece-4f41-aa8d-337d01c239f1: Got image data uri
file:///tmp/staging/72a6d7d0-a538-4922-95f2-1649e9702eb2 to be imported
Nov 07 18:51:37 rocky devstack@g-api.service[1033]: DEBUG
glance_store._drivers.swift.store [None
req-7a747213-c160-4423-b703-c6cad15b9217 admin admin] Adding image
object '72a6d7d0-a538-4922-95f2-1649e9702eb2' to Swift {{(pid=2250) add
/usr/local/lib/python2.7/dist-packages/glance_store/_drivers/swift/store.py:941}}
Nov 07 18:51:45 rocky devstack@g-api.service[1033]: DEBUG swiftclient
[None req-7a747213-c160-4423-b703-c6cad15b9217 admin admin] REQ: curl -i
http://192.168.1.201:8080/v1/AUTH_9495609cff044252965f8c3e5e86f8e0/glance/72a6d7d0-a538-4922-95f2-1649e9702eb2-1
-X PUT -H "X-Auth-Token: gABb4rWowjLQ..." {{(pid=2250) http_log
/usr/local/lib/python2.7/dist-packages/swiftclient/client.py:167}}
Nov 07 18:51:45 rocky devstack@g-api.service[1033]: DEBUG
glance_store._drivers.swift.store [None
req-7a747213-c160-4423-b703-c6cad15b9217 admin admin] Wrote chunk
72a6d7d0-a538-4922-95f2-1649e9702eb2-1 (1/?) of length 20480 to
Swift returning MD5 of content: 5139500edbb5814a1351100d162db333
{{(pid=2250) add
/usr/local/lib/python2.7/dist-packages/glance_store/_drivers/swift/store.py:1024}}

And then nothing. So it does send a 200MB chunk to Swift. I can see it
on Swift, too. But it stops after the first chunk and forgets to send
the rest.

After I tried that a few times, now it doesn't even upload the first
chunk. Nothing in Swift at all. No error in the Glance API log either.

Same problem with the /image-upload-via-import /command. I also tried
the /web-download /import method; same result.

In all these cases, the image remains in an non-active state forever,
i.e. an hour or so, when I lose patience and delete it.

"Classic" upload works (/openstack image create --file /). The log
file then shows the expected chunk uploads to Swift.



signature.asc
Description: OpenPGP digital signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [python3] Enabling py37 unit tests

[Doug Hellmann]

Mohammed Naser  writes:

> On Wed, Nov 7, 2018 at 2:07 PM Dr. Jens Harbott (frickler)
>  wrote:
>>
>> 2018-11-07 12:47 GMT+00:00 Mohammed Naser :
>> > On Wed, Nov 7, 2018 at 1:37 PM Doug Hellmann  wrote:
>> >>
>> >> Corey Bryant  writes:
>> >>
>> >> > On Wed, Oct 10, 2018 at 8:45 AM Corey Bryant 
>> >> > 
>> >> > wrote:
>> >> >
>> >> > I'd like to start moving forward with enabling py37 unit tests for a 
>> >> > subset
>> >> > of projects. Rather than putting too much load on infra by enabling 3 x 
>> >> > py3
>> >> > unit tests for every project, this would just focus on enablement of 
>> >> > py37
>> >> > unit tests for a subset of projects in the Stein cycle. And just to be
>> >> > clear, I would not be disabling any unit tests (such as py35). I'd just 
>> >> > be
>> >> > enabling py37 unit tests.
>> >> >
>> >> > As some background, this ML thread originally led to updating the
>> >> > python3-first governance goal (https://review.openstack.org/#/c/610708/)
>> >> > but has now led back to this ML thread for a +1 rather than updating the
>> >> > governance goal.
>> >> >
>> >> > I'd like to get an official +1 here on the ML from parties such as the 
>> >> > TC
>> >> > and infra in particular but anyone else's input would be welcomed too.
>> >> > Obviously individual projects would have the right to reject proposed
>> >> > changes that enable py37 unit tests. Hopefully they wouldn't, of course,
>> >> > but they could individually vote that way.
>> >> >
>> >> > Thanks,
>> >> > Corey
>> >>
>> >> This seems like a good way to start. It lets us make incremental
>> >> progress while we take the time to think about the python version
>> >> management question more broadly. We can come back to the other projects
>> >> to add 3.7 jobs and remove 3.5 jobs when we have that plan worked out.
>> >
>> > What's the impact on the number of consumption in upstream CI node usage?
>>
>> I think the relevant metric here will be nodes_used * time_used.
>> nodes_used will increase by one, time_used for usual unit test jobs
>> seems to be < 10 minutes, so I'd think that the total increase in CI
>> usage should be neglegible compared to full tempest or similar jobs
>> that take 1-2 hours.
>
> Indeed it doesn't look too bad:
>
> http://zuul.openstack.org/builds?job_name=openstack-tox-py35
>
> It'll be good to try and aim to transition as quickly as possible to
> avoid extra 'wasted' resources in the infrastructure side

Right, I think we can live with it for a few weeks.

-- 
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] [python3] Enabling py37 unit tests

[Thomas Goirand]

On 10/11/18 1:35 AM, Goutham Pacha Ravi wrote:
> Thanks Corey for starting this effort. I proposed changes to
> manila repos to use your template [1] [2], but the interpreter's not
> being installed,
> do you need to make any bindep changes to enable the "universe" ppa and 
> install
> python3.7 and python3.7-dev?

Your best luck in Debian based distribution is probably to attempt
installing python3-all *or* python3-dev-all. The -all means all
available versions (so, in case of Debian Sid currently, it will install
both Python 3.6 and 3.7). The -dev-all will also install the -all
package, so you never need *both*. You also don't need the -dev if you
don't have Python packages that needs Python.h (ie: embedded C code in a
Python module).

So, just switch to that, and you're good to go *forever*, independently
of what python version is available in a given OS version! :)

I hope this helps,
Cheers,

Thomas Goirand (zigo)

__
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] [python3] Enabling py37 unit tests

[Mohammed Naser]

On Wed, Nov 7, 2018 at 2:07 PM Dr. Jens Harbott (frickler)
 wrote:
>
> 2018-11-07 12:47 GMT+00:00 Mohammed Naser :
> > On Wed, Nov 7, 2018 at 1:37 PM Doug Hellmann  wrote:
> >>
> >> Corey Bryant  writes:
> >>
> >> > On Wed, Oct 10, 2018 at 8:45 AM Corey Bryant 
> >> > wrote:
> >> >
> >> > I'd like to start moving forward with enabling py37 unit tests for a 
> >> > subset
> >> > of projects. Rather than putting too much load on infra by enabling 3 x 
> >> > py3
> >> > unit tests for every project, this would just focus on enablement of py37
> >> > unit tests for a subset of projects in the Stein cycle. And just to be
> >> > clear, I would not be disabling any unit tests (such as py35). I'd just 
> >> > be
> >> > enabling py37 unit tests.
> >> >
> >> > As some background, this ML thread originally led to updating the
> >> > python3-first governance goal (https://review.openstack.org/#/c/610708/)
> >> > but has now led back to this ML thread for a +1 rather than updating the
> >> > governance goal.
> >> >
> >> > I'd like to get an official +1 here on the ML from parties such as the TC
> >> > and infra in particular but anyone else's input would be welcomed too.
> >> > Obviously individual projects would have the right to reject proposed
> >> > changes that enable py37 unit tests. Hopefully they wouldn't, of course,
> >> > but they could individually vote that way.
> >> >
> >> > Thanks,
> >> > Corey
> >>
> >> This seems like a good way to start. It lets us make incremental
> >> progress while we take the time to think about the python version
> >> management question more broadly. We can come back to the other projects
> >> to add 3.7 jobs and remove 3.5 jobs when we have that plan worked out.
> >
> > What's the impact on the number of consumption in upstream CI node usage?
>
> I think the relevant metric here will be nodes_used * time_used.
> nodes_used will increase by one, time_used for usual unit test jobs
> seems to be < 10 minutes, so I'd think that the total increase in CI
> usage should be neglegible compared to full tempest or similar jobs
> that take 1-2 hours.

Indeed it doesn't look too bad:

http://zuul.openstack.org/builds?job_name=openstack-tox-py35

It'll be good to try and aim to transition as quickly as possible to
avoid extra 'wasted' resources in the infrastructure side

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



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

[openstack-dev] [barbican] No ca_file in the KeystonePassword class

[Thomas Goirand]

Hi,

Trying to implement kms_keymaster in Swift (to enable encryption), I
have found out that Castellan's KeystonePassword doesn't include any
option for root CA certificates (neither a insecure=True option). In
such a configuration, it's not easy to test.

So my question is: has anyone from the Barbican thought about this,
and/or is there any workaround this? Going to production without any
possibility to test with fake certs is a little bit annoying... :P

Cheers,

Thomas Goirand (zigo)

__
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] [openstack client] command completion

[Doug Hellmann]

Bernd Bausch  writes:

> Thanks for educating me, Doug and Jeremy. Bug submitted.
>
> Just by the way: I checked [1] and [2] to find out where bugs might be
> tracked. The former doesn't mention bugs, the latter is outdated.
> Finding the way through the maze of OpenStack information is not always
> easy.
>
> [1]
> https://governance.openstack.org/tc/reference/projects/openstackclient.html

Interesting; I don't think we really expected anyone to use the
governance docs to explore the projects in terms of code. I wonder how
common that is? Maybe we should add some links to docs.openstack.org.

>
> [2] https://wiki.openstack.org/wiki/OpenStackClient

We've marked that as deprecated but left it around for future digital
archaeologists. Maybe we should delete more of the content. We should
definitely update the home page in the governance repo so it doesn't
link to a wiki page we aren't maintaining, so I will do that.

-- 
Doug

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [python3] Enabling py37 unit tests

[Dr. Jens Harbott (frickler)]

2018-11-07 12:47 GMT+00:00 Mohammed Naser :
> On Wed, Nov 7, 2018 at 1:37 PM Doug Hellmann  wrote:
>>
>> Corey Bryant  writes:
>>
>> > On Wed, Oct 10, 2018 at 8:45 AM Corey Bryant 
>> > wrote:
>> >
>> > I'd like to start moving forward with enabling py37 unit tests for a subset
>> > of projects. Rather than putting too much load on infra by enabling 3 x py3
>> > unit tests for every project, this would just focus on enablement of py37
>> > unit tests for a subset of projects in the Stein cycle. And just to be
>> > clear, I would not be disabling any unit tests (such as py35). I'd just be
>> > enabling py37 unit tests.
>> >
>> > As some background, this ML thread originally led to updating the
>> > python3-first governance goal (https://review.openstack.org/#/c/610708/)
>> > but has now led back to this ML thread for a +1 rather than updating the
>> > governance goal.
>> >
>> > I'd like to get an official +1 here on the ML from parties such as the TC
>> > and infra in particular but anyone else's input would be welcomed too.
>> > Obviously individual projects would have the right to reject proposed
>> > changes that enable py37 unit tests. Hopefully they wouldn't, of course,
>> > but they could individually vote that way.
>> >
>> > Thanks,
>> > Corey
>>
>> This seems like a good way to start. It lets us make incremental
>> progress while we take the time to think about the python version
>> management question more broadly. We can come back to the other projects
>> to add 3.7 jobs and remove 3.5 jobs when we have that plan worked out.
>
> What's the impact on the number of consumption in upstream CI node usage?

I think the relevant metric here will be nodes_used * time_used.
nodes_used will increase by one, time_used for usual unit test jobs
seems to be < 10 minutes, so I'd think that the total increase in CI
usage should be neglegible compared to full tempest or similar jobs
that take 1-2 hours.

__
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] [PackStack][Neutron] erro port no present in bridge br-int

[Soheil Pourbafrani]

Thanks. In one node installation no error happened but in two node
installation, I got the error. So I guess the answer of Laszlo is
reasonable.

On Wed, Nov 7, 2018 at 10:23 AM Budai Laszlo  wrote:

> Hi
>
> we had a similar situation when the ``host`` entry in the neutron.conf was
> different than the host entry in the nova.conf on the compute nodes.
> So if you're setting a ``host`` entry in one of these files, then make
> sure the other file contains the same ``host`` setting.
>
> see
> https://docs.openstack.org/neutron/rocky/configuration/neutron.html#DEFAULT.host
> and
> https://docs.openstack.org/nova/rocky/configuration/config.html#DEFAULT.host
>
> Kind regards,
> Laszlo
>
> On 11/6/18 6:04 PM, Akihiro Motoki wrote:
> > How is your [ovs] bridge_mapping in your configuration?
> > Flat network requires a corresponding bridge_mapping entry and you also
> need to create a corresponding bridge in advance.
> >
> >
> > 2018年11月6日(火) 21:31 Soheil Pourbafrani  soheil.i...@gmail.com>>:
> >
> > Hi, I initilize an instance using a defined flat network and I got
> the error:
> > port no present in bridge br-int
> >
> > I have a 2 node deployment (controller + network, compute).
> >
> > The output of the command ovs-vsctl show is
> > *
> > *
> > *On the network node*
> > d3a06f16-d727-4333-9de6-cf4ce3b0ce36
> >  Manager "ptcp:6640:127.0.0.1"
> >  is_connected: true
> >  Bridge br-ex
> >  Controller "tcp:127.0.0.1:6633 "
> >  is_connected: true
> >  fail_mode: secure
> >  Port br-ex
> >  Interface br-ex
> >  type: internal
> >  Port phy-br-ex
> >  Interface phy-br-ex
> >  type: patch
> >  options: {peer=int-br-ex}
> >  Port "ens33"
> >  Interface "ens33"
> >  Bridge br-int
> >  Controller "tcp:127.0.0.1:6633 "
> >  is_connected: true
> >  fail_mode: secure
> >  Port br-int
> >  Interface br-int
> >  type: internal
> >  Port patch-tun
> >  Interface patch-tun
> >  type: patch
> >  options: {peer=patch-int}
> >  Port int-br-ex
> >  Interface int-br-ex
> >  type: patch
> >  options: {peer=phy-br-ex}
> >  Port "tapefb98047-57"
> >  tag: 1
> >  Interface "tapefb98047-57"
> >  type: internal
> >  Port "qr-d62d0c14-51"
> >  tag: 1
> >  Interface "qr-d62d0c14-51"
> >  type: internal
> >  Port "qg-5468707b-6d"
> >  tag: 2
> >  Interface "qg-5468707b-6d"
> >  type: internal
> >  Bridge br-tun
> >  Controller "tcp:127.0.0.1:6633 "
> >  is_connected: true
> >  fail_mode: secure
> >  Port patch-int
> >  Interface patch-int
> >  type: patch
> >  options: {peer=patch-tun}
> >  Port br-tun
> >  Interface br-tun
> >  type: internal
> >  Port "vxlan-c0a8003d"
> >  Interface "vxlan-c0a8003d"
> >  type: vxlan
> >  options: {df_default="true", in_key=flow,
> local_ip="192.168.0.62", out_key=flow, remote_ip="192.168.0.61"}
> >  ovs_version: "2.9.0"
> >
> > *On the Compute node*
> > *
> > *
> > *55e62867-9c88-4925-b49c-55fb74d174bd*
> > *Manager "ptcp:6640:127.0.0.1"*
> > *is_connected: true*
> > *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 "enp2s0"*
> > *Interface "enp2s0"*
> > *Port br-ex*
> > *Interface br-ex*
> > *type: internal*
> > *Bridge br-tun*
> > *Controller "tcp:127.0.0.1:6633 "*
> > *is_connected: true*
> > *fail_mode: secure*
> > *Port br-tun*
> > *Interface br-tun*
> > *type: internal*
> > *Port "vxlan-c0a8003e"*
> > *Interface "vxlan-c0a8003e"*
> > *type: vxlan*
> > *options: {df_default="true", in_key=flow,
> local_ip="192.168.0.61", out_key=flow, 

Re: [openstack-dev] [python3] Enabling py37 unit tests

[Mohammed Naser]

On Wed, Nov 7, 2018 at 1:37 PM Doug Hellmann  wrote:
>
> Corey Bryant  writes:
>
> > On Wed, Oct 10, 2018 at 8:45 AM Corey Bryant 
> > wrote:
> >
> > I'd like to start moving forward with enabling py37 unit tests for a subset
> > of projects. Rather than putting too much load on infra by enabling 3 x py3
> > unit tests for every project, this would just focus on enablement of py37
> > unit tests for a subset of projects in the Stein cycle. And just to be
> > clear, I would not be disabling any unit tests (such as py35). I'd just be
> > enabling py37 unit tests.
> >
> > As some background, this ML thread originally led to updating the
> > python3-first governance goal (https://review.openstack.org/#/c/610708/)
> > but has now led back to this ML thread for a +1 rather than updating the
> > governance goal.
> >
> > I'd like to get an official +1 here on the ML from parties such as the TC
> > and infra in particular but anyone else's input would be welcomed too.
> > Obviously individual projects would have the right to reject proposed
> > changes that enable py37 unit tests. Hopefully they wouldn't, of course,
> > but they could individually vote that way.
> >
> > Thanks,
> > Corey
>
> This seems like a good way to start. It lets us make incremental
> progress while we take the time to think about the python version
> management question more broadly. We can come back to the other projects
> to add 3.7 jobs and remove 3.5 jobs when we have that plan worked out.

What's the impact on the number of consumption in upstream CI node usage?

> 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



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [openstack-dev] [python3] Enabling py37 unit tests

[Doug Hellmann]

Corey Bryant  writes:

> On Wed, Oct 10, 2018 at 8:45 AM Corey Bryant 
> wrote:
>
> I'd like to start moving forward with enabling py37 unit tests for a subset
> of projects. Rather than putting too much load on infra by enabling 3 x py3
> unit tests for every project, this would just focus on enablement of py37
> unit tests for a subset of projects in the Stein cycle. And just to be
> clear, I would not be disabling any unit tests (such as py35). I'd just be
> enabling py37 unit tests.
>
> As some background, this ML thread originally led to updating the
> python3-first governance goal (https://review.openstack.org/#/c/610708/)
> but has now led back to this ML thread for a +1 rather than updating the
> governance goal.
>
> I'd like to get an official +1 here on the ML from parties such as the TC
> and infra in particular but anyone else's input would be welcomed too.
> Obviously individual projects would have the right to reject proposed
> changes that enable py37 unit tests. Hopefully they wouldn't, of course,
> but they could individually vote that way.
>
> Thanks,
> Corey

This seems like a good way to start. It lets us make incremental
progress while we take the time to think about the python version
management question more broadly. We can come back to the other projects
to add 3.7 jobs and remove 3.5 jobs when we have that plan worked out.

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] [Openstack-operators] FIPS Compliance

[Doug Hellmann]

Joshua Cornutt  writes:

> Doug,
>
> I have such a list put together (my various installation documents for
> getting these clouds working in FIPS mode) but it's hardly ready for
> public consumption. I planned on releasing each bit as a code change
> and/or bug ticket and letting the community consume it as it figures
> some of these things out.

It's likely that the overall migration will go better if we all have the
full context. So I hope you can find some time to publish some of the
information you've compiled to help with that.

> I agree that some changes may break backwards compatibility (such as
> Glance's image checksumming), but one approach I think could ease the
> transition would be the approach I took for SSH key pair
> fingerprinting (also MD5-based, as is Glance image checksums) found
> here - https://review.openstack.org/#/c/615460/ . This allows
> administrators to choose, hopefully at deployment time, the hashing
> algorithm with the default of being the existing MD5 algorithm.

That certainly seems like it would provide the most compatibility in the
short term.

That said, I honestly don't know the best approach for us to take. We're
going to need people who understand the issues around FIPS and the
issues around maintaining backwards-compatibility to work together to
create a recommended approach. Perhaps a few of the folks on this thread
would be interested in forming a team to work on that?

Doug

> Another approach would be to make the projects "FIPS aware" where we
> choose the hashing algorithm based on the system's FIPS-enforcing
> state. An example of doing so is what I'm proposing for Django
> (another FIPS-related patch that was needed for OSP 13) -
> https://github.com/django/django/pull/10605
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [tripleo] CI is broken

[Juan Antonio Osorio Robles]

Hello folks,


Please do not attempt to merge or recheck patches until we get this
sorted out.

We are dealing with several issues that have broken all jobs.

https://bugs.launchpad.net/tripleo/+bug/1801769
https://bugs.launchpad.net/tripleo/+bug/1801969
https://bugs.launchpad.net/tripleo/+bug/1802083
https://bugs.launchpad.net/tripleo/+bug/1802085

Best Regards!


__
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] [all]Naming the T release of OpenStack -- Poll open

[Lajos Katona]

Hi,

Thanks, I check via mobile net than.

Regards
Lajos

On 2018. 11. 07. 11:20, Colleen Murphy wrote:
> On Wed, Nov 7, 2018, at 11:12 AM, Lajos Katona wrote:
>> Hi,
>>
>> Maybe I missed something but I got the message: "Already voted
>> A vote has already been cast using your voter key.
>>
>> Poll results will be available only to the following users:
>>
>> t...@bakeyournoodle.com"
>>
>> Could you help me to have a correct link?
> The public polling service limits voting to one vote per IP address. If 
> someone in your office space has already voted, the poll won't let anyone 
> else in the office vote. You need to find a different public IP address to 
> vote from, either by tunneling through a proxy or physically going somewhere 
> else with a different network.
>
> Colleen
>
>> Regards
>> Lajos
>>
>> On 2018. 11. 06. 3:19, Tony Breeds wrote:
>>
>>
>> Hi all,
>>
>> Time is running out for you to have your say in the T release name
>> poll.  We have just under 3 days left.  If you haven't voted please do!
>>
>> On Tue, Oct 30, 2018 at 04:40:25PM +1100, Tony Breeds wrote:
>>
>>
>> Hi folks,
>>
>> It is time again to cast your vote for the naming of the T Release.
>> As with last time we'll use a public polling option over per user private 
>> URLs
>> for voting.  This means, everybody should proceed to use the following URL to
>> cast their vote:
>>
>>
>> https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_aac97f1cbb6c61df=b9e448b340787f0e
>>
>> We've selected a public poll to ensure that the whole community, not just 
>> gerrit
>> change owners get a vote.  Also the size of our community has grown such 
>> that we
>> can overwhelm CIVS if using private urls.  A public can mean that users
>> behind NAT, proxy servers or firewalls may receive an message saying
>> that your vote has already been lodged, if this happens please try
>> another IP.
>>
>> Because this is a public poll, results will currently be only viewable by 
>> myself
>> until the poll closes. Once closed, I'll post the URL making the results
>> viewable to everybody. This was done to avoid everybody seeing the results 
>> while
>> the public poll is running.
>>
>> The poll will officially end on 2018-11-08 00:00:00+00:00[1], and
>> results will be
>> posted shortly after.
>>
>> [1] https://governance.openstack.org/tc/reference/release-naming.html
>> ---
>>
>> According to the Release Naming Process, this poll is to determine the
>> community preferences for the name of the T release of OpenStack. It is
>> possible that the top choice is not viable for legal reasons, so the second 
>> or
>> later community preference could wind up being the name.
>>
>> Release Name Criteria
>> -
>>
>> Each release name must start with the letter of the ISO basic Latin alphabet
>> following the initial letter of the previous release, starting with the
>> initial release of "Austin". After "Z", the next name should start with
>> "A" again.
>>
>> The name must be composed only of the 26 characters of the ISO basic Latin
>> alphabet. Names which can be transliterated into this character set are also
>> acceptable.
>>
>> The name must refer to the physical or human geography of the region
>> encompassing the location of the OpenStack design summit for the
>> corresponding release. The exact boundaries of the geographic region under
>> consideration must be declared before the opening of nominations, as part of
>> the initiation of the selection process.
>>
>> The name must be a single word with a maximum of 10 characters. Words that
>> describe the feature should not be included, so "Foo City" or "Foo Peak"
>> would both be eligible as "Foo".
>>
>> Names which do not meet these criteria but otherwise sound really cool
>> should be added to a separate section of the wiki page and the TC may make
>> an exception for one or more of them to be considered in the Condorcet poll.
>> The naming official is responsible for presenting the list of exceptional
>> names for consideration to the TC before the poll opens.
>>
>> Exact Geographic Region
>> ---
>>
>> The Geographic Region from where names for the S release will come is 
>> Colorado
>>
>> Proposed Names
>> --
>>
>> * Tarryall
>> * Teakettle
>> * Teller
>> * Telluride
>> * Thomas : the Tank Engine
>> * Thornton
>> * Tiger
>> * Tincup
>> * Timnath
>> * Timber
>> * Tiny Town
>> * Torreys
>> * Trail
>> * Trinidad
>> * Treasure
>> * Troublesome
>> * Trussville
>> * Turret
>> * Tyrone
>>
>> Proposed Names that do not meet the criteria (accepted by the TC)
>> -
>>
>> * Train : Many Attendees of the first Denver PTG have a story to tell
>> about the trains near the PTG hotel.  We could celebrate those stories
>> with this name
>>
>> Yours Tony.
>>
>>
>>
>>
>>
>>
>>
>> __
>> OpenStack Development 

Re: [openstack-dev] [all]Naming the T release of OpenStack -- Poll open

[Colleen Murphy]

On Wed, Nov 7, 2018, at 11:12 AM, Lajos Katona wrote:
> Hi,
> 
> Maybe I missed something but I got the message: "Already voted
> A vote has already been cast using your voter key.
> 
> Poll results will be available only to the following users:
> 
> t...@bakeyournoodle.com"
> 
> Could you help me to have a correct link?

The public polling service limits voting to one vote per IP address. If someone 
in your office space has already voted, the poll won't let anyone else in the 
office vote. You need to find a different public IP address to vote from, 
either by tunneling through a proxy or physically going somewhere else with a 
different network.

Colleen

> 
> Regards
> Lajos
> 
> On 2018. 11. 06. 3:19, Tony Breeds wrote:
> 
> 
> Hi all,
> 
>Time is running out for you to have your say in the T release name
> poll.  We have just under 3 days left.  If you haven't voted please do!
> 
> On Tue, Oct 30, 2018 at 04:40:25PM +1100, Tony Breeds wrote:
> 
> 
> Hi folks,
> 
> It is time again to cast your vote for the naming of the T Release.
> As with last time we'll use a public polling option over per user private URLs
> for voting.  This means, everybody should proceed to use the following URL to
> cast their vote:
> 
>   
> https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_aac97f1cbb6c61df=b9e448b340787f0e
> 
> We've selected a public poll to ensure that the whole community, not just 
> gerrit
> change owners get a vote.  Also the size of our community has grown such that 
> we
> can overwhelm CIVS if using private urls.  A public can mean that users
> behind NAT, proxy servers or firewalls may receive an message saying
> that your vote has already been lodged, if this happens please try
> another IP.
> 
> Because this is a public poll, results will currently be only viewable by 
> myself
> until the poll closes. Once closed, I'll post the URL making the results
> viewable to everybody. This was done to avoid everybody seeing the results 
> while
> the public poll is running.
> 
> The poll will officially end on 2018-11-08 00:00:00+00:00[1], and 
> results will be
> posted shortly after.
> 
> [1] https://governance.openstack.org/tc/reference/release-naming.html
> ---
> 
> According to the Release Naming Process, this poll is to determine the
> community preferences for the name of the T release of OpenStack. It is
> possible that the top choice is not viable for legal reasons, so the second or
> later community preference could wind up being the name.
> 
> Release Name Criteria
> -
> 
> Each release name must start with the letter of the ISO basic Latin alphabet
> following the initial letter of the previous release, starting with the
> initial release of "Austin". After "Z", the next name should start with
> "A" again.
> 
> The name must be composed only of the 26 characters of the ISO basic Latin
> alphabet. Names which can be transliterated into this character set are also
> acceptable.
> 
> The name must refer to the physical or human geography of the region
> encompassing the location of the OpenStack design summit for the
> corresponding release. The exact boundaries of the geographic region under
> consideration must be declared before the opening of nominations, as part of
> the initiation of the selection process.
> 
> The name must be a single word with a maximum of 10 characters. Words that
> describe the feature should not be included, so "Foo City" or "Foo Peak"
> would both be eligible as "Foo".
> 
> Names which do not meet these criteria but otherwise sound really cool
> should be added to a separate section of the wiki page and the TC may make
> an exception for one or more of them to be considered in the Condorcet poll.
> The naming official is responsible for presenting the list of exceptional
> names for consideration to the TC before the poll opens.
> 
> Exact Geographic Region
> ---
> 
> The Geographic Region from where names for the S release will come is Colorado
> 
> Proposed Names
> --
> 
> * Tarryall
> * Teakettle
> * Teller
> * Telluride
> * Thomas : the Tank Engine
> * Thornton
> * Tiger
> * Tincup
> * Timnath
> * Timber
> * Tiny Town
> * Torreys
> * Trail
> * Trinidad
> * Treasure
> * Troublesome
> * Trussville
> * Turret
> * Tyrone
> 
> Proposed Names that do not meet the criteria (accepted by the TC)
> -
> 
> * Train : Many Attendees of the first Denver PTG have a story to tell 
> about the trains near the PTG hotel.  We could celebrate those stories 
> with this name
> 
> Yours Tony.
> 
> 
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?
> subject:unsubscribe
> 

Re: [openstack-dev] [all]Naming the T release of OpenStack -- Poll open

[Lajos Katona]

Hi,

Maybe I missed something but I got the message: "Already voted
A vote has already been cast using your voter key.

Poll results will be available only to the following users:

t...@bakeyournoodle.com"

Could you help me to have a correct link?

Regards
Lajos

On 2018. 11. 06. 3:19, Tony Breeds wrote:


Hi all,

   Time is running out for you to have your say in the T release name
poll.  We have just under 3 days left.  If you haven't voted please do!

On Tue, Oct 30, 2018 at 04:40:25PM +1100, Tony Breeds wrote:


Hi folks,

It is time again to cast your vote for the naming of the T Release.
As with last time we'll use a public polling option over per user private URLs
for voting.  This means, everybody should proceed to use the following URL to
cast their vote:

  
https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_aac97f1cbb6c61df=b9e448b340787f0e

We've selected a public poll to ensure that the whole community, not just gerrit
change owners get a vote.  Also the size of our community has grown such that we
can overwhelm CIVS if using private urls.  A public can mean that users
behind NAT, proxy servers or firewalls may receive an message saying
that your vote has already been lodged, if this happens please try
another IP.

Because this is a public poll, results will currently be only viewable by myself
until the poll closes. Once closed, I'll post the URL making the results
viewable to everybody. This was done to avoid everybody seeing the results while
the public poll is running.

The poll will officially end on 2018-11-08 00:00:00+00:00[1], and results will 
be
posted shortly after.

[1] https://governance.openstack.org/tc/reference/release-naming.html
---

According to the Release Naming Process, this poll is to determine the
community preferences for the name of the T release of OpenStack. It is
possible that the top choice is not viable for legal reasons, so the second or
later community preference could wind up being the name.

Release Name Criteria
-

Each release name must start with the letter of the ISO basic Latin alphabet
following the initial letter of the previous release, starting with the
initial release of "Austin". After "Z", the next name should start with
"A" again.

The name must be composed only of the 26 characters of the ISO basic Latin
alphabet. Names which can be transliterated into this character set are also
acceptable.

The name must refer to the physical or human geography of the region
encompassing the location of the OpenStack design summit for the
corresponding release. The exact boundaries of the geographic region under
consideration must be declared before the opening of nominations, as part of
the initiation of the selection process.

The name must be a single word with a maximum of 10 characters. Words that
describe the feature should not be included, so "Foo City" or "Foo Peak"
would both be eligible as "Foo".

Names which do not meet these criteria but otherwise sound really cool
should be added to a separate section of the wiki page and the TC may make
an exception for one or more of them to be considered in the Condorcet poll.
The naming official is responsible for presenting the list of exceptional
names for consideration to the TC before the poll opens.

Exact Geographic Region
---

The Geographic Region from where names for the S release will come is Colorado

Proposed Names
--

* Tarryall
* Teakettle
* Teller
* Telluride
* Thomas : the Tank Engine
* Thornton
* Tiger
* Tincup
* Timnath
* Timber
* Tiny Town
* Torreys
* Trail
* Trinidad
* Treasure
* Troublesome
* Trussville
* Turret
* Tyrone

Proposed Names that do not meet the criteria (accepted by the TC)
-

* Train : Many Attendees of the first Denver PTG have a story to tell about 
the trains near the PTG hotel.  We could celebrate those stories with this name

Yours Tony.







__
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



Yours Tony.




__
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-operators] Question about path in disk file

[Michael Stang]

Hi,

I have a question about the "disk" file from the instances, I searched about it 
but didn't find any infos.

At the beginning of the file the is a path to the baseimage which was used to 
create the instance, and I want to knwo what this ist for?

The problem behind is, that we changed the path to the imagecache and some 
instances denied to start after becaus they could not find the base image 
anymore. But the other instances didn't have this problem at all. Also I 
noticed that the info in the disk file ist not updated when the instance is 
migrated to another host.

So my question is this normal? What is when I migrate the sever to another host 
with another storage and there is another path to the image cahche?

We use still mitaka at the moment, maybe in a newer version this has already 
changed?

Thank you :)

Kind regards,

Michael



Michael Stang
Laboringenieur, Dipl. Inf. (FH)

Duale Hochschule Baden-Württemberg Mannheim
Baden-Wuerttemberg Cooperative State University Mannheim
ZeMath Zentrum für mathematisch-naturwissenschaftliches Basiswissen
Fachbereich Informatik, Fakultät Technik
Coblitzallee 1-9
68163 Mannheim

Tel.: +49 (0)621 4105 - 1367
michael.st...@dhbw-mannheim.de
mailto:michael.stang@dhbw-mannheim.dehttp://www.dhbw-mannheim.de/


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

Re: [openstack-dev] Asking for suggestion of video conference tool for team and webinar

[Thierry Carrez]

Trinh Nguyen wrote:
I tried several free tools for team meetings, vPTG, and webinars but 
there are always drawbacks ( because it's free, of course). For example:


  * Google Hangout: only allow a maximum of 10 people to do the video calls
  * Zoom: limits about 45m per meeting. So for a webinar or conference
call takes more than 45m we have to splits into 2 sessions or so.

If anyone in the community can suggest some better video conferencing 
tools, that would be great. So we can organize better communication for 
our team and the community's webinars.


Jitsi meet is an open source + free as in beer solution based on WebRTC:

https://meet.jit.si/

No account needed, no participant limit.

--
Thierry Carrez (ttx)

__
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