Re: [openstack-dev] [Octavia] Multinode setup

[Michael Johnson]

At the moment that is all we have for a setup guide.

That said, all of the Octavia controller processes are fully HA
capable. The one setting I can think of is the controller_ip_port_list
setting mentioned above. It will need to contain an entry for each
health manager IP/port as Sa Pham mentioned.

You will also want to load balance connections across your API
instances. Load balancing for the other processes is built into the
design and does not require any additional load balancing.

Michael
On Mon, Nov 26, 2018 at 5:59 AM Sa Pham  wrote:
>
> Hi,
>
> The controller_ip_port_list option is list of all IP of node which is 
> deployed octavia-health-manager.
>
>
>
> On Nov 26, 2018, at 8:41 PM, Anna Taraday  wrote:
>
> Hello everyone!
>
> I'm looking into how to run Octavia services (controller worker, housekeeper, 
> health manager) on several network nodes and get confused with setup guide 
> [1].
> Is there any special config option for such case? (controller_ip_port_list 
> probably)
> What manuals/docs/examples do we have except [2] ?
>
> [1] - 
> https://docs.openstack.org/octavia/queens/contributor/guides/dev-quick-start.html
> [2] 
> -https://github.com/openstack/octavia/blob/stable/queens/devstack/samples/multinode/local-2.conf
> --
> Regards,
> Ann Taraday
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> Sa Pham Dang
> Cloud RnD Team - VCCloud / VCCorp
> Phone: 0986.849.582
> Skype: great_bn
>
> __
> 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] [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

Re: [openstack-dev] [openstack-community] Sharing upstream contribution mentoring result with Korea user group

[Michael Johnson]

This is awesome Ian.  Thanks for all of the work on this!

Michael

On Tue, Oct 30, 2018 at 8:28 AM Frank Kloeker  wrote:
>
> Hi Ian,
>
> thanks for sharing. What a great user story about community work and
> contributing to OpenStack. I think you did a great job as mentor and
> organizer. I want to keep you with us.
>
> Welcome new contributors any many thanks for translation and
> programming. Hopefully you feel comfortable and have enough energy and
> fun to work further on OpenStack.
>
> kind regards
> Frank
>
> Am 2018-10-30 15:10, schrieb Ian Y. Choi:
> > Hello,
> >
> > I got involved organizing & mentoring Korean people for OpenStack
> > upstream contribution for about last two months,
> > and would like to share with community members.
> >
> > Total nine mentees had started to learn OpenStack, contributed, and
> > finally survived as volunteers for
> >  1) developing OpenStack mobile app for better mobile user interfaces
> > and experiences
> > (inspired from https://github.com/stackerz/app which worked on
> > Juno release), and
> >  2) translating OpenStack official project artifacts including
> > documents,
> >  and Container Whitepaper (
> > https://www.openstack.org/containers/leveraging-containers-and-openstack/
> > ).
> >
> > Korea user group organizers (Seongsoo Cho, Taehee Jang, Hocheol Shin,
> > Sungjin Kang, and Andrew Yongjoon Kong)
> > all helped to organize total 8 offline meetups + one mini-hackathon
> > and mentored to attendees.
> >
> > The followings are brief summary:
> >  - "OpenStack Controller" Android app is available on Play Store
> >   :
> > https://play.google.com/store/apps/details?id=openstack.contributhon.com.openstackcontroller
> >(GitHub: https://github.com/kosslab-kr/openstack-controller )
> >
> >  - Most high-priority projects (although it is not during string
> > freeze period) and documents are
> >100% translated into Korean: Horizon, OpenStack-Helm, I18n Guide,
> > and Container Whitepaper.
> >
> >  - Total 18,695 words were translated into Korean by four contributors
> >   (confirmed through Zanata API:
> > https://translate.openstack.org/rest/stats/user/[Zanata
> > ID]/2018-08-16..2018-10-25 ):
> >
> > ++---+-+
> > | Zanata ID  | Name  | Number of words |
> > ++---+-+
> > | ardentpark | Soonyeul Park | 12517   |
> > ++---+-+
> > | bnitech| Dongbim Im| 693 |
> > ++---+-+
> > | csucom | Sungwook Choi | 4397|
> > ++---+-+
> > | jaeho93| Jaeho Cho | 1088|
> > ++---+-+
> >
> >  - The list of projects translated into Korean are described as:
> >
> > +-+-+
> > | Project | Number of words |
> > +-+-+
> > | api-site| 20  |
> > +-+-+
> > | cinder  | 405 |
> > +-+-+
> > | designate-dashboard | 4   |
> > +-+-+
> > | horizon | 3226|
> > +-+-+
> > | i18n| 434 |
> > +-+-+
> > | ironic  | 4   |
> > +-+-+
> > | Leveraging Containers and OpenStack | 5480|
> > +-+-+
> > | neutron-lbaas-dashboard | 5   |
> > +-+-+
> > | openstack-helm  | 8835|
> > +-+-+
> > | trove-dashboard | 89  |
> > +-+-+
> > | zun-ui  | 193 |
> > +-+-+
> >
> > I would like to really appreciate all co-mentors and participants on
> > such a big event for promoting OpenStack contribution.
> > The venue and food were supported by Korea Open Source Software
> > Development Center ( https://kosslab.kr/ ).
> >
> >
> > With many thanks,
> >
> > /Ian
> >
> > ___
> > Community mailing list
> > commun...@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/community
>
>
> __
> OpenStack Development Mailing 

Re: [openstack-dev] [Octavia] [Kolla] SSL errors polling amphorae and missing tenant network interface

[Michael Johnson]

 with [1] but now
> >>> moved on to using the openstack-ansible way of generating them [2]
> >>> with some modifications.
> >>>
> >>> Right now I'm just getting: Could not connect to instance. Retrying.:
> >>> SSLError: [SSL: BAD_SIGNATURE] bad signature (_ssl.c:579)
> >>> from the amphoras, haven't got any further but I've eliminated a lot of
> >>> stuck in the middle.
> >>>
> >>> Tried deploying Ocatavia on Ubuntu with python3 to just make sure there
> >>> wasn't an issue with CentOS and OpenSSL versions since it tends to lag
> >>> behind.
> >>> Checking the amphora with openssl s_client [3] it gives the same one,
> >>> but the verification is successful just that I don't understand what the
> >>> bad signature
> >>> part is about, from browsing some OpenSSL code it seems to be related to
> >>> RSA signatures somehow.
> >>>
> >>> 140038729774992:error:1408D07B:SSL routines:ssl3_get_key_exchange:bad
> >>> signature:s3_clnt.c:2032:
> >>>
> >>> So I've basicly ruled out Ubuntu (openssl-1.1.0g) and CentOS
> >>> (openssl-1.0.2k) being the problem, ruled out signing_digest, so I'm
> >>> back to something related
> >>> to the certificates or the communication between the endpoints, or what
> >>> actually responds inside the amphora (gunicorn IIUC?). Based on the
> >>> "verify" functions actually causing that bad signature error I would
> >>> assume it's the generated certificate that the amphora presents that is
> >>> causing it.
> >>>
> >>> I'll have to continue the troubleshooting to the inside of the amphora,
> >>> I've used the test-only amphora image before but have now built my own
> >>> one that is
> >>> using the amphora-agent from the actual stable branch, but same issue
> >>> (bad signature).
> >>>
> >>> For verbosity this is the config options set for the certificates in
> >>> octavia.conf and which file it was copied from [4], same here, a
> >>> replication of what openstack-ansible does.
> >>>
> >>> Appreciate any feedback or help :)
> >>>
> >>> Best regards
> >>> Tobias
> >>>
> >>> [1]
> >>> https://github.com/openstack/octavia/blob/master/bin/create_certificates.sh
> >>> [2] http://paste.openstack.org/show/732483/
> >>> [3] http://paste.openstack.org/show/732486/
> >>> [4] http://paste.openstack.org/show/732487/
> >>>
> >>> On 10/20/2018 01:53 AM, Michael Johnson wrote:
> >>>> Hi Erik,
> >>>>
> >>>> Sorry to hear you are still having certificate issues.
> >>>>
> >>>> Issue #2 is probably caused by issue #1. Since we hot-plug the tenant
> >>>> network for the VIP, one of the first steps after the worker connects
> >>>> to the amphora agent is finishing the required configuration of the
> >>>> VIP interface inside the network namespace on the amphroa.
> >>>>
> >> Thanks for the hint on the workflow of this. I hadn't gotten deep
> >> enough into the code to find that yet, but I suspected it was blocking
> >> since the namespace never got created either. Thanks
> >>
> >>>> If I remember correctly, you are attempting to configure Octavia with
> >>>> the dual CA option (which is good for non-development use).
> >>>>
> >>>> This is what I have for notes:
> >>>>
> >>>> [certificates] gets the following:
> >>>> cert_generator = local_cert_generator
> >>>> ca_certificate = server CA's "server.pem" file
> >>>> ca_private_key = server CA's "server.key" file
> >>>> ca_private_key_passphrase = pass phrase for ca_private_key
> >>>> [controller_worker]
> >>>> client_ca = Client CA's ca_cert file
> >>>> [haproxy_amphora]
> >>>> client_cert = Client CA's client.pem file (I think with it's key
> >>>> concatenated is what rm_work said the other day)
> >>>> server_ca = Server CA's ca_cert file
> >>>>
> >> This is all very helpful. It's a bit difficult to know what goes where
> >> the way the documentation is written presently. For something that's
> >> going to be the defacto standard for loadbalancing, we as a community
> >> need to do a better 

Re: [openstack-dev] [Octavia] SSL errors polling amphorae and missing tenant network interface

[Michael Johnson]

Hi Erik,

Sorry to hear you are still having certificate issues.

Issue #2 is probably caused by issue #1. Since we hot-plug the tenant
network for the VIP, one of the first steps after the worker connects
to the amphora agent is finishing the required configuration of the
VIP interface inside the network namespace on the amphroa.

If I remember correctly, you are attempting to configure Octavia with
the dual CA option (which is good for non-development use).

This is what I have for notes:

[certificates] gets the following:
cert_generator = local_cert_generator
ca_certificate = server CA's "server.pem" file
ca_private_key = server CA's "server.key" file
ca_private_key_passphrase = pass phrase for ca_private_key
 [controller_worker]
 client_ca = Client CA's ca_cert file
 [haproxy_amphora]
client_cert = Client CA's client.pem file (I think with it's key
concatenated is what rm_work said the other day)
server_ca = Server CA's ca_cert file

That said, I can probably run through this and write something up next
week that is more step-by-step/detailed.

Michael

On Fri, Oct 19, 2018 at 2:31 PM Erik McCormick
 wrote:
>
> Apologies for cross-posting, but in the event that these might be
> worth filing as bugs, I wanted the Octavia devs to see it as well...
>
> I've been wrestling with getting Octavia up and running and have
> become stuck on two issues. I'm hoping someone has run into these
> before. My google foo has come up empty.
>
> Issue 1:
> When the Octavia controller tries to poll the amphora instance, it
> tries repeatedly and eventually fails. The error on the controller
> side is:
>
> 2018-10-19 14:17:39.181 26 ERROR
> octavia.amphorae.drivers.haproxy.rest_api_driver [-] Connection
> retries (currently set to 300) exhausted.  The amphora is unavailable.
> Reason: HTTPSConnectionPool(host='10.7.0.112', port=9443): Max retries
> exceeded with url: /0.5/plug/vip/10.250.20.15 (Caused by
> SSLError(SSLError("bad handshake: Error([('rsa routines',
> 'RSA_padding_check_PKCS1_type_1', 'invalid padding'), ('rsa routines',
> 'rsa_ossl_public_decrypt', 'padding check failed'), ('asn1 encoding
> routines', 'ASN1_item_verify', 'EVP lib'), ('SSL routines',
> 'tls_process_server_certificate', 'certificate verify
> failed')],)",),)): SSLError: HTTPSConnectionPool(host='10.7.0.112',
> port=9443): Max retries exceeded with url: /0.5/plug/vip/10.250.20.15
> (Caused by SSLError(SSLError("bad handshake: Error([('rsa routines',
> 'RSA_padding_check_PKCS1_type_1', 'invalid padding'), ('rsa routines',
> 'rsa_ossl_public_decrypt', 'padding check failed'), ('asn1 encoding
> routines', 'ASN1_item_verify', 'EVP lib'), ('SSL routines',
> 'tls_process_server_certificate', 'certificate verify
> failed')],)",),))
>
> On the amphora side I see:
> [2018-10-19 17:52:54 +] [1331] [DEBUG] Error processing SSL request.
> [2018-10-19 17:52:54 +] [1331] [DEBUG] Invalid request from
> ip=:::10.7.0.40: [SSL: SSL_HANDSHAKE_FAILURE] ssl handshake
> failure (_ssl.c:1754)
>
> I've generated certificates both with the script in the Octavia git
> repo, and with the Openstack Ansible playbook. I can see that they are
> present in /etc/octavia/certs.
>
> I'm using the Kolla (Queens) containers for the control plane so I'm
> sure I've satisfied all the python library constraints.
>
> Issue 2:
> I"m not sure how it gets configured, but the tenant network interface
> (ens6) never comes up. I can spawn other instances on that network
> with no issue, and I can see that Neutron has the port attached to the
> instance. However, in the instance this is all I get:
>
> ubuntu@amphora-33e0aab3-8bc4-4fcb-bc42-b9b36afb16d4:~$ ip a
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
> group default qlen 1
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
>valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
>valid_lft forever preferred_lft forever
> 2: ens3:  mtu 9000 qdisc pfifo_fast
> state UP group default qlen 1000
> link/ether fa:16:3e:30:c4:60 brd ff:ff:ff:ff:ff:ff
> inet 10.7.0.112/16 brd 10.7.255.255 scope global ens3
>valid_lft forever preferred_lft forever
> inet6 fe80::f816:3eff:fe30:c460/64 scope link
>valid_lft forever preferred_lft forever
> 3: ens6:  mtu 1500 qdisc noop state DOWN group
> default qlen 1000
> link/ether fa:16:3e:89:a2:7f brd ff:ff:ff:ff:ff:ff
>
> There's no evidence of the interface anywhere else including udev rules.
>
> Any help with either or both issues would be greatly appreciated.
>
> Cheers,
> Erik
>
> __
> 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 

Re: [openstack-dev] [horizon][plugins] Horizon plugins validation on CI

[Michael Johnson]

Hi Ivan,

As Octavia PTL I have no issue with adding a tempest-plugin repository
for the octavia-dashboard. I think we have had examples with the main
tempest tests and plugins where trying to do a suite of tests in one
repository becomes messy.

We may also want to consider doing a horizon-tempest-lib type of
repository that can host common code/tools for the dashboard plugins
to leverage. I'm thinking things like login code, etc.

Michael
On Wed, Oct 17, 2018 at 6:19 AM Ivan Kolodyazhny  wrote:
>
> Hi all,
>
> We discussed this topic at PTG both with Horizon and other teams. Sounds like 
> everybody is interested to have some cross-project CI jobs to verify that 
> plugins are not broken with the latest Horizon changes.
>
> The initial idea was to use tempest plugins for this effort like we do for 
> Horizon [1]. We've got a very simple test to verify that Horizon is up and 
> running and a user is able to login.
>
> It's easy to implement such tests for any existing horizon plugin. I tried it 
> for Heat and Manila dashboards.
>
> If I understand correctly how tempest plugins work, for such case we've got 
> such options:
>
> a) to create the same tempest plugins for each plugin - it this case, we need 
> to maintain new repos for tempest plugins
> b) add these tests to Horizon tempest plugin - in such case, it will be 
> harder for plugin maintainers to support these tests.
>
> If we don't want to go forward with tempest plugins, we can create similar 
> tests based on Horizon functional tests.
>
> I want to get more feedback both from Horizon and plugins teams on which 
> direction we should go and start implementation.
>
>
> [1] 
> https://github.com/openstack/tempest-horizon/blob/master/tempest_horizon/tests/scenario/test_dashboard_basic_ops.py#L138
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [tc][all] Discussing goals (upgrades) with community @ office hours

[Michael Johnson]

I am interested in participating in this discussion.

I think we have had a few goals that were selected before all of the
parts were in place. This leads to re-work and/or pushing goals work
into the already busy milestone 3 time frame.

Michael
On Mon, Oct 15, 2018 at 5:16 AM Chris Dent  wrote:
>
> On Sat, 13 Oct 2018, Mohammed Naser wrote:
>
> > Does this seem like it would be of interest to the community?  I am
> > currently trying to transform our office hours to be more of a space
> > where we have more of the community and less of discussion between us.
>
> If we want discussion to actually be with the community at large
> (rather than giving lip service to the idea), then we need to be
> more oriented to using email. Each time we have an office hour or a
> meeting in IRC or elsewhere, or an ad hoc Hangout, unless we are
> super disciplined about reporting the details to email afterwards, a
> great deal of information falls on the floor and individuals who are
> unable to attend because of time, space, language or other
> constraints are left out.
>
> For community-wide issues, synchronous discussion should be the mode
> of last resort. Anything else creates a priesthood with a
> disempowered laity wondering how things got away from them.
>
> For community goals, in particular, preferring email for discussion
> and planning seems pretty key.
>
> I wonder if instead of specifying topics for TC office hours, we kill
> them instead? They've turned into gossiping echo chambers.
>
> --
> 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

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

[openstack-dev] [neutron][lbaas][neutron-lbaas][octavia] Update on the previously announced deprecation of neutron-lbaas and neutron-lbaas-dashboard

[Michael Johnson]

During the Queens release cycle we announced the deprecation of
neutron-lbaas and neutron-lbaas-dashboard[1].

Today we are announcing the expected end date for the neutron-lbaas
and neutron-lbaas-dashboard deprecation cycles.  During September 2019
or the start of the “U” OpenStack release cycle, whichever comes
first, neutron-lbaas and neutron-lbaas-dashboard will be retired. This
means the code will be be removed and will not be released as part of
the "U" OpenStack release per the infrastructure team’s “retiring a
project” process[2].

We continue to maintain a Frequently Asked Questions (FAQ) wiki page
to help answer additional questions you may have about this process:
https://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation

For more information or if you have additional questions, please see
the following resources:

The FAQ: https://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation

The Octavia documentation: https://docs.openstack.org/octavia/latest/

Reach out to us via IRC on the Freenode IRC network, channel #openstack-lbaas

Weekly Meeting: 20:00 UTC on Wednesdays in #openstack-lbaas on the
Freenode IRC network.

Sending email to the OpenStack developer mailing list: openstack-dev
[at] lists [dot] openstack [dot] org. Please prefix the subject with
'[openstack-dev][Octavia]'

Thank you for your support and patience during this transition,

Michael Johnson
Octavia PTL





[1] http://lists.openstack.org/pipermail/openstack-dev/2018-January/126836.html

[2] https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project

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

[Michael Johnson]

Jimmy,

Yes, the tags are correct in
https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
but are not correct in Project Navigator.

I am asking where is the git repository with the Project Navigator
code that creates the "Project Details" section?
I am looking for the Project Navigator source code.

Michael
On Fri, Sep 21, 2018 at 4:22 PM Jimmy McArthur  wrote:
>
> The TC tags are indeed in a different repo: 
> https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
>
> Let me know if this makes sense.
>
> Jimmy
>
> Michael Johnson September 21, 2018 at 4:32 PM
> Matt,
>
> I'm a bit confused by your response. I'm not looking for a definition
> of the tags, that is very clear.
>
> I'm looking for the source code backing the page that is rendering
> which tags a project has.
> This code appears to be broken and not rendering the tags correctly
> and I wanted to see if I could fix it.
>
> 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
> Matt Riedemann September 21, 2018 at 3:04 PM
>
>
> Those are down in the project details section of the page, look to the right 
> and there is a 'tag details' column. The tags are descriptive and link to the 
> details on each tag.
>
> Michael Johnson September 21, 2018 at 1:11 PM
> Thank you Jimmy for making this available for updates.
>
> I was unable to find the code backing the project tags section of the
> Project Navigator pages.
> Our page is missing some upgrade tags and is showing duplicate "Stable
> branch policy" tags.
>
> https://www.openstack.org/software/releases/rocky/components/octavia
>
> Is there a different repository for the tags code?
>
> Thanks,
> 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
> Jimmy Mcarthur September 21, 2018 at 8:59 AM
> Following up on my (very brief) talk from the PTG, you can now propose 
> changes to the Project Navigator by going to 
> https://git.openstack.org/cgit/openstack/openstack-map repository
>
> Once your patch is merged, the page should reflect the changes straight away.
>
> Cheers,
> Jimmy
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] OpenStack Project Navigator

[Michael Johnson]

Matt,

I'm a bit confused by your response. I'm not looking for a definition
of the tags, that is very clear.

I'm looking for the source code backing the page that is rendering
which tags a project has.
This code appears to be broken and not rendering the tags correctly
and I wanted to see if I could fix it.

Michael

On Fri, Sep 21, 2018 at 1:05 PM Matt Riedemann  wrote:
>
> On 9/21/2018 1:11 PM, Michael Johnson wrote:
> > Thank you Jimmy for making this available for updates.
> >
> > I was unable to find the code backing the project tags section of the
> > Project Navigator pages.
> > Our page is missing some upgrade tags and is showing duplicate "Stable
> > branch policy" tags.
> >
> > https://www.openstack.org/software/releases/rocky/components/octavia
> >
> > Is there a different repository for the tags code?
>
> Those are down in the project details section of the page, look to the
> right and there is a 'tag details' column. The tags are descriptive and
> link to the details on each tag.
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] OpenStack Project Navigator

[Michael Johnson]

Thank you Jimmy for making this available for updates.

I was unable to find the code backing the project tags section of the
Project Navigator pages.
Our page is missing some upgrade tags and is showing duplicate "Stable
branch policy" tags.

https://www.openstack.org/software/releases/rocky/components/octavia

Is there a different repository for the tags code?

Thanks,
Michael
On Fri, Sep 21, 2018 at 6:59 AM Jimmy Mcarthur  wrote:
>
> Following up on my (very brief) talk from the PTG, you can now propose
> changes to the Project Navigator by going to
> https://git.openstack.org/cgit/openstack/openstack-map repository
>
> Once your patch is merged, the page should reflect the changes straight
> away.
>
> Cheers,
> Jimmy
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [docs] Nominating Ian Y. Choi for openstack-doc-core

[Michael Johnson]

Also not a docs core, but fully support this nomination!

Michael

On Wed, Sep 19, 2018 at 12:25 PM Jay S Bryant  wrote:
>
>
>
> On 9/19/2018 1:50 PM, Petr Kovar wrote:
> > Hi all,
> >
> > Based on our PTG discussion, I'd like to nominate Ian Y. Choi for
> > membership in the openstack-doc-core team. I think Ian doesn't need an
> > introduction, he's been around for a while, recently being deeply involved
> > in infra work to get us robust support for project team docs translation and
> > PDF builds.
> >
> > Having Ian on the core team will also strengthen our integration with
> > the i18n community.
> >
> > Please let the ML know should you have any objections.
> Petr,
>
> Not a doc Core but wanted to add my support.  Agree he would be a great
> addition.  Appreciate all he does for i18n, docs and OpenStack!
>
> Jay
>
> > Thanks,
> > pk
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [octavia] Optimize the query of the octavia database

[Michael Johnson]

Hi All,

I have created a patch that resolves this regression:
https://review.openstack.org/#/c/603242/

Please take a look. Locally it showed dramatic improvements. List load
balancers went from two and half minutes down to seconds when I had a
thousand Act/Stdby LBs.

The patch may need some touch ups around testing, but the
functionality should be good.

We also have some team members working on Rally support for Octavia,
so hopefully we will be able to catch a regression like this
immediately in the future. Please support those efforts if you can
contribute some time.

Michael
On Fri, Sep 14, 2018 at 6:01 PM Jeff Yang  wrote:
>
> Ok, Thank you very much for your work.
>
> Adam Harwell  于2018年9月15日周六 上午8:26写道：
>>
>> It's high priority for me as well, so we should be able to get something 
>> done very soon, I think. Look for something early next week maybe?
>>
>> Thanks,
>> --Adam
>>
>> On Thu, Sep 13, 2018, 21:18 Jeff Yang  wrote:
>>>
>>> Thanks:
>>> I found the correlative patch in neutron-lbaas: 
>>> https://review.openstack.org/#/c/568361/
>>>
>>>     The bug was marked high level by our QA team. I need to fix it as soon 
>>> as possible.
>>>  Does Michael Johnson have any good suggestion? I am willing to 
>>> complete the
>>>  repair work of this bug. If your patch still takes a while to prepare.
>>>
>>> Michael Johnson  于2018年9月14日周五 上午7:56写道：
>>>>
>>>> This is a known regression in the Octavia API performance. It has an
>>>> existing story[0] that is under development. You are correct, that
>>>> star join is the root of the problem.
>>>> Look for a patch soon.
>>>>
>>>> [0] https://storyboard.openstack.org/#!/story/2002933
>>>>
>>>> Michael
>>>> On Thu, Sep 13, 2018 at 10:32 AM Erik Olof Gunnar Andersson
>>>>  wrote:
>>>> >
>>>> > This was solved in neutron-lbaas recently, maybe we could adopt the same 
>>>> > method for Octavia?
>>>> >
>>>> > Sent from my iPhone
>>>> >
>>>> > On Sep 13, 2018, at 4:54 AM, Jeff Yang  wrote:
>>>> >
>>>> > Hi, All
>>>> >
>>>> > As octavia resources increase, I found that running the "openstack 
>>>> > loadbalancer list" command takes longer and longer. Sometimes a 504 
>>>> > error is reported.
>>>> >
>>>> > By reading the code, I found that octavia will performs complex left 
>>>> > outer join queries when acquiring resources such as loadbalancer, 
>>>> > listener, pool, etc. in order to only make one trip to the database.
>>>> > Reference code: http://paste.openstack.org/show/730022 Line 133
>>>> > Generated SQL statements: http://paste.openstack.org/show/730021
>>>> >
>>>> > So, I suggest that adjust the query strategy to provide different join 
>>>> > queries for different resources.
>>>> >
>>>> > https://storyboard.openstack.org/#!/story/2003751
>>>> >
>>>> > __
>>>> > OpenStack Development Mailing List (not for usage questions)
>>>> > Unsubscribe: 
>>>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> >
>>>> > __
>>>> > OpenStack Development Mailing List (not for usage questions)
>>>> > Unsubscribe: 
>>>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Openstack-operators] [all] Consistent policy names

[Michael Johnson]

I don't know for sure, but I assume it is short for "OpenStack" and
prefixing OpenStack policies vs. third party plugin policies for
documentation purposes.

I am guilty of borrowing this from existing code examples[0].

[0] 
http://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/policy-in-code.html

Michael
On Fri, Sep 14, 2018 at 8:46 AM Lance Bragstad  wrote:
>
>
>
> On Thu, Sep 13, 2018 at 5:46 PM Michael Johnson  wrote:
>>
>> In Octavia I selected[0] "os_load-balancer_api:loadbalancer:post"
>> which maps to the "os--api::" format.
>
>
> Thanks for explaining the justification, Michael.
>
> I'm curious if anyone has context on the "os-" part of the format? I've seen 
> that pattern in a couple different projects. Does anyone know about its 
> origin? Was it something we converted to our policy names because of API 
> names/paths?
>
>>
>>
>> I selected it as it uses the service-type[1], references the API
>> resource, and then the method. So it maps well to the API reference[2]
>> for the service.
>>
>> [0] https://docs.openstack.org/octavia/latest/configuration/policy.html
>> [1] https://service-types.openstack.org/
>> [2] 
>> https://developer.openstack.org/api-ref/load-balancer/v2/index.html#create-a-load-balancer
>>
>> Michael
>> On Wed, Sep 12, 2018 at 12:52 PM Tim Bell  wrote:
>> >
>> > So +1
>> >
>> >
>> >
>> > Tim
>> >
>> >
>> >
>> > From: Lance Bragstad 
>> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>> > 
>> > Date: Wednesday, 12 September 2018 at 20:43
>> > To: "OpenStack Development Mailing List (not for usage questions)" 
>> > , OpenStack Operators 
>> > 
>> > Subject: [openstack-dev] [all] Consistent policy names
>> >
>> >
>> >
>> > The topic of having consistent policy names has popped up a few times this 
>> > week. Ultimately, if we are to move forward with this, we'll need a 
>> > convention. To help with that a little bit I started an etherpad [0] that 
>> > includes links to policy references, basic conventions *within* that 
>> > service, and some examples of each. I got through quite a few projects 
>> > this morning, but there are still a couple left.
>> >
>> >
>> >
>> > The idea is to look at what we do today and see what conventions we can 
>> > come up with to move towards, which should also help us determine how much 
>> > each convention is going to impact services (e.g. picking a convention 
>> > that will cause 70% of services to rename policies).
>> >
>> >
>> >
>> > Please have a look and we can discuss conventions in this thread. If we 
>> > come to agreement, I'll start working on some documentation in oslo.policy 
>> > so that it's somewhat official because starting to renaming policies.
>> >
>> >
>> >
>> > [0] https://etherpad.openstack.org/p/consistent-policy-names
>> >
>> > ___
>> > OpenStack-operators mailing list
>> > openstack-operat...@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>> __
>> 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 mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

Re: [openstack-dev] [octavia] Optimize the query of the octavia database

[Michael Johnson]

This is a known regression in the Octavia API performance. It has an
existing story[0] that is under development. You are correct, that
star join is the root of the problem.
Look for a patch soon.

[0] https://storyboard.openstack.org/#!/story/2002933

Michael
On Thu, Sep 13, 2018 at 10:32 AM Erik Olof Gunnar Andersson
 wrote:
>
> This was solved in neutron-lbaas recently, maybe we could adopt the same 
> method for Octavia?
>
> Sent from my iPhone
>
> On Sep 13, 2018, at 4:54 AM, Jeff Yang  wrote:
>
> Hi, All
>
> As octavia resources increase, I found that running the "openstack 
> loadbalancer list" command takes longer and longer. Sometimes a 504 error is 
> reported.
>
> By reading the code, I found that octavia will performs complex left outer 
> join queries when acquiring resources such as loadbalancer, listener, pool, 
> etc. in order to only make one trip to the database.
> Reference code: http://paste.openstack.org/show/730022 Line 133
> Generated SQL statements: http://paste.openstack.org/show/730021
>
> So, I suggest that adjust the query strategy to provide different join 
> queries for different resources.
>
> https://storyboard.openstack.org/#!/story/2003751
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Openstack-operators] [all] Consistent policy names

[Michael Johnson]

In Octavia I selected[0] "os_load-balancer_api:loadbalancer:post"
which maps to the "os--api::" format.

I selected it as it uses the service-type[1], references the API
resource, and then the method. So it maps well to the API reference[2]
for the service.

[0] https://docs.openstack.org/octavia/latest/configuration/policy.html
[1] https://service-types.openstack.org/
[2] 
https://developer.openstack.org/api-ref/load-balancer/v2/index.html#create-a-load-balancer

Michael
On Wed, Sep 12, 2018 at 12:52 PM Tim Bell  wrote:
>
> So +1
>
>
>
> Tim
>
>
>
> From: Lance Bragstad 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: Wednesday, 12 September 2018 at 20:43
> To: "OpenStack Development Mailing List (not for usage questions)" 
> , OpenStack Operators 
> 
> Subject: [openstack-dev] [all] Consistent policy names
>
>
>
> The topic of having consistent policy names has popped up a few times this 
> week. Ultimately, if we are to move forward with this, we'll need a 
> convention. To help with that a little bit I started an etherpad [0] that 
> includes links to policy references, basic conventions *within* that service, 
> and some examples of each. I got through quite a few projects this morning, 
> but there are still a couple left.
>
>
>
> The idea is to look at what we do today and see what conventions we can come 
> up with to move towards, which should also help us determine how much each 
> convention is going to impact services (e.g. picking a convention that will 
> cause 70% of services to rename policies).
>
>
>
> Please have a look and we can discuss conventions in this thread. If we come 
> to agreement, I'll start working on some documentation in oslo.policy so that 
> it's somewhat official because starting to renaming policies.
>
>
>
> [0] https://etherpad.openstack.org/p/consistent-policy-names
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

__
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][infra]Including Functional Tests in Coverage

[Michael Johnson]

We do this in Octavia. The openstack-tox-cover calls the cover
environment in tox.ini, so you can add it there.

Check out the tox.ini in the openstack/octavia project.

Michael

On Wed, Sep 12, 2018 at 7:01 AM reedip banerjee  wrote:
>
> Hi All,
>
> Has anyone ever experimented with including Functional Tests with 
> openstack-tox-cover job?
> We would like to include Functional tests in the coverage jobs and already 
> have a dsvm-functional job in place. However,  openstack-tox-cover is , if I 
> am correct, an infra job which is directly called.
>
> Has anyone tried to include the functional tests and all its pre-requisites 
> in the cover job? If so, any pointers would be great
>
>
> --
> Thanks and Regards,
> Reedip Banerjee
> IRC: reedipb
>
>
>
>
> __
> 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] [release][octavia]

[Michael Johnson]

Octavia and Release teams,

I am adding Carlos Goncalves to the Octavia project release management
liaison list for Stein.
He will be assisting with regular stable branch release patches.

Let me know if you have any questions or concerns,
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

Re: [openstack-dev] [Openstack] OpenStack Rocky for Ubuntu 18.04 LTS

[Michael Johnson]

Corey,

Awesome!  Excited to see Octavia included in the release.

Michael
On Fri, Sep 7, 2018 at 8:19 AM Corey Bryant  wrote:
>
> The Ubuntu OpenStack team at Canonical is pleased to announce the general 
> availability of OpenStack Rocky on Ubuntu 18.04 LTS via the Ubuntu Cloud 
> Archive. Details of the Rocky release can be found at:  
> https://www.openstack.org/software/rocky
>
> To get access to the Ubuntu Rocky packages:
>
> Ubuntu 18.04 LTS
> ---
>
> You can enable the Ubuntu Cloud Archive pocket for OpenStack Rocky on Ubuntu 
> 18.04 installations by running the following commands:
>
> sudo add-apt-repository cloud-archive:rocky
> sudo apt update
>
> The Ubuntu Cloud Archive for Rocky includes updates for:
>
> aodh, barbican, ceilometer, ceph (13.2.1), cinder, designate, 
> designate-dashboard, glance, gnocchi, heat, heat-dashboard, horizon, ironic, 
> keystone, magnum, manila, manila-ui, mistral, murano, murano-dashboard, 
> networking-bagpipe, networking-bgpvpn, networking-hyperv, networking-l2gw, 
> networking-odl, networking-ovn, networking-sfc, neutron, 
> neutron-dynamic-routing, neutron-fwaas, neutron-lbaas, 
> neutron-lbaas-dashboard, neutron-vpnaas, nova, nova-lxd, octavia, 
> openstack-trove, openvswitch (2.10.0), panko, sahara, sahara-dashboard, 
> senlin, swift, trove-dashboard, vmware-nsx, watcher, and zaqar.
>
> For a full list of packages and versions, please refer to:
> http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/rocky_versions.html
>
> Python 3 support
> -
> Python 3 packages are now available for all of the above packages except 
> swift. All of these packages have successfully been unit tested with at least 
> Python 3.6. Function testing is ongoing and fixes will continue to be 
> backported to Rocky.
>
> Python 3 enablement
> --
> In Rocky, Python 2 packages will still be installed by default for all 
> packages except gnocchi and octavia, which are Python 3 by default. In a 
> future release, we will switch all packages to Python 3 by default.
>
> To enable Python 3 for existing installations:
> # upgrade to latest Rocky package versions first, then:
> sudo apt install python3- [1]
> sudo apt install libapache2-mod-wsgi-py3  # not required for all packages 
> [2]
> sudo apt purge python- [1]
> sudo apt autoremove --purge
> sudo systemctl restart -*
> sudo systemctl restart apache2  # not required for all packages [2]
>
> For example:
> sudo apt install aodh-*
> sudo apt install python3-aodh libapache2-mod-wsgi-py3
> sudo apt purge python-aodh
> sudo apt autoremove --purge
> sudo systemctl restart aodh-* apache2
>
> To enable Python 3 for new installations:
> sudo apt install python3- [1]
> sudo apt install libapache2-mod-wsgi-py3  # not required for all packages 
> [2]
> sudo apt install -
>
> For example:
> sudo apt install python3-aodh libapache2-mod-wsgi-py3 aodh-api
>
> [1] The naming convention of python packages is generally python- 
> and python3-. For horizon, however, the packages are named 
> python-django-horizon and python3-django-horizon.
>
> [2] The following packages are run under apache2 and require installation of 
> libapache2-mod-wsgi-py3 to enable Python 3 support:
> aodh-api, cinder-api, barbican-api, keystone, nova-placement-api, 
> openstack-dashboard, panko-api, sahara-api
>
> Other notable changes
> 
> sahara-api: sahara API now runs under apache2 with mod_wsgi
>
> Branch Package Builds
> -
> If you would like to try out the latest updates to branches, we deliver 
> continuously integrated packages on each upstream commit via the following 
> PPA’s:
>
> sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka
> sudo add-apt-repository ppa:openstack-ubuntu-testing/ocata
> sudo add-apt-repository ppa:openstack-ubuntu-testing/pike
> sudo add-apt-repository ppa:openstack-ubuntu-testing/queens
> sudo add-apt-repository ppa:openstack-ubuntu-testing/rocky
>
> Reporting bugs
> ---
> If you have any issues please report bugs using the 'ubuntu-bug' tool to 
> ensure that bugs get logged in the right place in Launchpad:
>
> sudo ubuntu-bug nova-conductor
>
> Thanks to everyone who has contributed to OpenStack Rocky, both upstream and 
> downstream. Special thanks to the Puppet OpenStack modules team and the 
> OpenStack Charms team for their continued early testing of the Ubuntu Cloud 
> Archive, as well as the Ubuntu and Debian OpenStack teams for all of their 
> contributions.
>
> Have fun and see you in Stein!
>
> Cheers,
> Corey
> (on behalf of the Ubuntu OpenStack team)
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

[openstack-dev] [octavia] Weekly IRC meeting cancelled Sept. 12th

[Michael Johnson]

Hello Octavia community,

As many of us will be attending the OpenStack PTG next week, I am
cancelling the weekly Octavia IRC meeting on September 12th.

We will resume our normal schedule on September 19th.

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

Re: [openstack-dev] [octavia] Proposing Carlos Goncalves (cgoncalves) as an Octavia core reviewer

[Michael Johnson]

With a unanimous vote I would like to welcome Carlos to the Octavia Core team!

Michael


On Fri, Aug 31, 2018 at 10:42 AM Adam Harwell  wrote:
>
> +1 for sure!
>
> On Sat, Sep 1, 2018, 01:41 Carlos Goncalves  wrote:
>>
>> Ha! Gracias for the kind words, Miguel! :-)
>>
>> On Fri, Aug 31, 2018 at 5:55 PM, Miguel Lavalle  wrote:
>>>
>>> Well, I don't vote here but I stiil want to express my +1. I knew this was 
>>> going to happen sooner rather than later
>>>
>>> On Thu, Aug 30, 2018 at 10:24 PM, Michael Johnson  
>>> wrote:
>>>>
>>>> Hello Octavia community,
>>>>
>>>> I would like to propose Carlos Goncalves as a core reviewer on the
>>>> Octavia project.
>>>>
>>>> Carlos has provided numerous enhancements to the Octavia project,
>>>> including setting up the grenade gate for Octavia upgrade testing.
>>>>
>>>> Over the last few releases he has also been providing quality reviews,
>>>> in line with the other core reviewers [1]. I feel that Carlos would
>>>> make an excellent addition to the Octavia core reviewer team.
>>>>
>>>> Existing Octavia core reviewers, please reply to this email with your
>>>> support or concerns with adding Jacky to the core team.
>>>>
>>>> Michael
>>>>
>>>> [1] http://stackalytics.com/report/contribution/octavia-group/90
>>>>
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
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] Proposing Carlos Goncalves (cgoncalves) as an Octavia core reviewer

[Michael Johnson]

Hello Octavia community,

I would like to propose Carlos Goncalves as a core reviewer on the
Octavia project.

Carlos has provided numerous enhancements to the Octavia project,
including setting up the grenade gate for Octavia upgrade testing.

Over the last few releases he has also been providing quality reviews,
in line with the other core reviewers [1]. I feel that Carlos would
make an excellent addition to the Octavia core reviewer team.

Existing Octavia core reviewers, please reply to this email with your
support or concerns with adding Jacky to the core team.

Michael

[1] http://stackalytics.com/report/contribution/octavia-group/90

__
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] [all][Election] [Octavia] Stein Octavia PTL candidacy

[Michael Johnson]

My fellow OpenStack community,

I would like to nominate myself for Octavia PTL for Stein. I am currently
the PTL for the Rocky release series and would like to continue helping our
team provide network load balancing services for OpenStack.

In the Rocky release, we were able to add support for provider drivers,
improve the user experience when using Barbican, listener timeouts, dashboard
auto refresh, and creating members designated as "backup" members.

Looking forward to Stein I expect the team to finish out some major new
features, such as Active/Active load balancers and flavors.

Thank you for your support of Octavia during Rocky and your consideration for
Stein,

Michael Johnson (johnsom)

__
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] [Ironic][Octavia][Congress] The usage of Neutron API

[Michael Johnson]

Octavia is done. Thank you for the patch!

Michael
On Tue, Jul 24, 2018 at 8:35 AM Hongbin Lu  wrote:
>
> Hi folks,
>
>
>
> Neutron has landed a patch to enable strict validation on query parameters 
> when listing resources [1]. I tested the Neutorn’s change in your project’s 
> gate and the result suggested that your projects would need the fixes 
> [2][3][4] to keep the gate functioning.
>
>
>
> Please feel free to reach out if there is any question or concern.
>
>
>
> [1] https://review.openstack.org/#/c/574907/
>
> [2] https://review.openstack.org/#/c/583990/
>
> [3] https://review.openstack.org/#/c/584000/
>
> [4] https://review.openstack.org/#/c/584112/
>
>
>
> Best regards,
>
> Hongbin
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [octavia] Make amphora-agent support http rest api

[Michael Johnson]

I saw your storyboard for this.  Thank you for creating a story.

Since the controllers manage the certificates for the amphora (both
generation and rotation) the overhead to an operator should be
extremely low and limited to initial installation configuration.
Since we have automated the certificate handling we felt it was better
to only allow TLS connections for the management traffice to the
amphora.
Please feel free to discuss on the Storyboard story,
Michael

On Wed, Jul 18, 2018 at 7:52 PM Jeff Yang  wrote:
>
> In some private cloud environments, the possibility of vm being attacked is 
> very small, and all personnel are trusted. At this time, the administrator 
> hopes to reduce the complexity of octavia deployment and operation and 
> maintenance. We can let the amphora-agent provide the http api so that the 
> administrator can ignore the issue of the certificate.
> https://storyboard.openstack.org/#!/story/2003027
> __
> 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] [octavia][ptg] Stein PTG Planning etherpad for Octavia

[Michael Johnson]

Hi Octavia folks!

I have created an etherpad [1] for topics at the Stein PTG in Denver.
Please indicate if you will be attending or not and any topics you
think we should cover.

Michael

[1] https://etherpad.openstack.org/p/octavia-stein-ptg

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

Re: [openstack-dev] [requirements][taskflow] networkx migration

[Michael Johnson]

Octavia passed tempest with this change and networkx 2.1.

Michael

On Tue, Jul 10, 2018 at 9:29 AM Doug Hellmann  wrote:
>
> Excerpts from Matthew Thode's message of 2018-07-10 10:59:33 -0500:
> > On 18-07-09 15:15:23, Matthew Thode wrote:
> > > We have a patch that looks good, can we get it merged?
> > >
> > > https://review.openstack.org/#/c/577833/
> > >
> >
> > Anyone from taskflow around?  Maybe it's better to just mail the ptl.
> >
>
> We could use more reviewers on taskflow (and have needed them for a
> while). Perhaps we can get some of the consuming projects to give it a
> little live so the Oslo folks who are less familiar with it feel
> confident of the change(s) this close to the final release date for
> non-client libraries.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [octavia] Some tips about amphora driver

[Michael Johnson]

Hi Jeff,
Thank you for your comments. I will reply on the story.

Michael

On Thu, Jul 5, 2018 at 8:02 PM Jeff Yang  wrote:
>
> Recently, my team plans to provider load balancing services with octavia.I 
> recorded some of the needs and suggestions of our team members.The following 
> suggestions about amphora may be very useful.
>
> [1] User can specify image and flavor for amphora.
> [2] Enable multi processes(version<1.8) or multi threads(version>=1.8) for 
> haproxy
> [3] Provider a script to check and clean up bad loadbalancer and amphora. 
> Moreover we alse need to clean up neutron and nova resources about these 
> loadblancer and amphora.
>
> The implementation of [1] and [2] depend on provider flavor framework. So 
> it's time to implement provider flavor framework.
> About [3], We can't delete loadbalancer by API if the loadbalancer's status 
> is PENDING_UPDATE or PENDING_CREATE. And we haven't api for delete amphora, 
> so if the status of this amphora is not active it will always exists. So the 
> script is necessary.
>
> https://storyboard.openstack.org/#!/story/2002896
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [all] [release] How to handle "stable" deliverables releases

[Michael Johnson]

I think we should continue with option 1.

It is an indicator that a project is active in OpenStack and is
explicit about which code should be used together.

Both of those statements hold no technical water, but address the
"human" factor of "What is OpenStack?", "What do I need to deploy?",
"What is an active project and what is not?", and "How do we advertise
what OpenStack can provide?".

I think 2 and 3 will just lead to confusion and frustration for folks.

Michael
On Mon, Jun 11, 2018 at 7:50 AM Doug Hellmann  wrote:
>
> Excerpts from Thierry Carrez's message of 2018-06-11 11:53:52 +0200:
> > Hi everyone,
> >
> > As some of the OpenStack deliverables get more mature, we need to adjust
> > our release policies to best handle the case of deliverables that do not
> > need to be updated that much. This discussion started with how to handle
> > those "stable" libraries, but is actually also relevant for "stable"
> > services.
> >
> > Our current models include cycle-tied models (with-intermediary,
> > with-milestones, trailing) and a purely cycle-independent model. Main
> > OpenStack deliverables (the service components that you can deploy to
> > build an OpenStack cloud) are all "released" on a cycle. Libraries are
> > typically maintained per-cycle as well. What happens if no change is
> > pushed to a service or library during a full cycle ? What should we do
> > then ?
> >
> > Options include:
> >
> > 1/ Force artificial releases, even if there are no changes
> >
> > This is the current state. It allows to reuse the exact same process,
> > but creates useless churn and version number confusion.
> >
> > 2/ Do not force releases, but still create branches from latest releases
> >
> > In this variant we would not force an artificial re-release, but we
> > would still create a branch from the last available release, in order to
> > be able to land future patches and do bugfix or security releases as needed.
> >
> > 2bis/ Like 2, but only create the branch when needed
> >
> > Same as the previous one, except that rather than proactively create the
> > stable branch around release time, we'd wait until the branch is
> > actually needed to create it.
> >
> > 3/ Do not force releases, and reuse stable branches from cycle to cycle
> >
> > In this model, if there is no change in a library in Rocky, stable/rocky
> > would never be created, and stable/queens would be used instead. Only
> > one branch would get maintained for the 2 cycles. While this reduces the
> > churn, it's a bit complex to wrap your head around the consequences, and
> > measure how confusing this could be in practice...
> >
> > 4/ Stop worrying about stable branches at all for those "stable" things
> >
> > The idea here would be to stop doing stable branches for those things
> > that do not release that much anymore. This could be done by switching
> > them to the "independent" release model, or to a newly-created model.
> > While good for "finished" deliverables, this option could create issues
> > for things that are inactive for a couple cycles and then pick up
> > activity again -- switching back to being cycle-tied would likely be
> > confusing.
> >
> >
> > My current preference is option 2.
> >
> > It's a good trade-off which reduces churn while keeping a compatibility
> > with the system used for more active components. Compared to 2bis, it's
> > a bit more work (although done in one patch during the release process),
> > but creating the branches in advance means they are ready to be used
> > when someone wants to backport something there, likely reducing process
> > pain.
> >
> > One caveat with this model is that we need to be careful with version
> > numbers. Imagine a library that did a 1.18.0 release for queens (which
> > stable/queens is created from). Nothing happens in Rocky, so we create
> > stable/rocky from the same 1.18.0 release. Same in Stein, so we create
> > stable/stein from the same 1.18.0 release. During the Telluride[1] cycle
> > some patches land and we want to release that. In order to leave room
> > for rocky and stein point releases, we need to skip 1.18.1 and 1.19.0,
> > and go directly to 1.20.0. I think we can build release checks to ensure
> > that, but that's something to keep in mind.
> >
> > Thoughts ?
> >
> > [1] It's never too early to campaign for your favorite T name
>
> Although I originally considered it separate, reviewing your summary
> I suspect option 2bis is most likely to turn into option 3, in
> practice.
>
> I think having the choice between options 2 and switching to an
> independent release model (maybe only for libraries) is going to
> be best, at least to start out.
>
> Stein will be the first series where we have to actually deal with
> this, so we can see how it goes and discuss alternatives if we run
> into issues.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 

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

[Michael Johnson]

Octavia also has an informal rule about two cores from the same
company merging patches. I support this because it makes sure we have
a diverse perspective on the patches. Specifically it has worked well
for us as all of the cores have different cloud designs, so it catches
anything that would limit/conflict with the different OpenStack
topologies.

That said, we don't hard enforce this or police it, it is just an
informal policy to make sure we get input from the wider team.
Currently we only have one company with two cores.

That said, my issue with the current diversity calculations is they
tend to be skewed by the PTL role. People have a tendency to defer to
the PTL to review/comment/merge patches, so if the PTL shares a
company with another core the diversity numbers get skewed heavily
towards that company.

Michael

On Wed, Jun 6, 2018 at 5:06 AM,   wrote:
>> -Original Message-
>> From: Doug Hellmann 
>> Sent: Monday, June 4, 2018 5:52 PM
>> To: openstack-dev 
>> Subject: Re: [openstack-dev] [tc] Organizational diversity tag
>>
>> Excerpts from Zane Bitter's message of 2018-06-04 17:41:10 -0400:
>> > On 02/06/18 13:23, Doug Hellmann wrote:
>> > > Excerpts from Zane Bitter's message of 2018-06-01 15:19:46 -0400:
>> > >> On 01/06/18 12:18, Doug Hellmann wrote:
>> > >
>> > > [snip]
>> > Apparently enough people see it the way you described that this is
>> > probably not something we want to actively spread to other projects at
>> > the moment.
>>
>> I am still curious to know which teams have the policy. If it is more
>> widespread than I realized, maybe it's reasonable to extend it and use it as
>> the basis for a health check after all.
>>
>
> A while back, Trove had this policy. When Rackspace, HP, and Tesora had core 
> reviewers, (at various times, eBay, IBM and Red Hat also had cores), the 
> agreement was that multiple cores from any one company would not merge a 
> change unless it was an emergency. It was not formally written down (to my 
> knowledge).
>
> It worked well, and ensured that the operators didn't get surprised by some 
> unexpected thing that took down their service.
>
> -amrith
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [octavia] TERMINATED_HTTPS + SSL to backend server

[Michael Johnson]

Hi Mihaela,

Backend re-encryption is on our roadmap[1], but not yet implemented.
We have all of the technical pieces to make this work, it's just
someone getting time to do the API additions and update the flows.

[1] 
https://wiki.openstack.org/wiki/Octavia/Roadmap#Considerations_for_Octavia_3.0.2B

Michael

On Wed, May 30, 2018 at 1:45 AM,   wrote:
> Hello,
>
>
>
> Is there any user story for the scenario below?
>
>
>
> -  Octavia is set to TERMINATED_HTTPS and also initiates SSL to
> backend servers
>
>
>
> After testing all the combination possible and after looking at the Octavia
> haproxy templates in Queens version I understand that this kind of setup is
> currently not supported.
>
>
>
> Thanks,
>
> Mihaela
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [devstack][python/pip][octavia] pip failure during octavia/pike image build by devstack

[Michael Johnson]

Yes, this just started occurring with Thursday/Fridays updates to the
Ubuntu cloud image upstream of us.

I have posted a patch for Queens here: https://review.openstack.org/#/c/569531

We will be back porting that as soon as we can to the other stable
releases. Please review the backports as they come out to help the
team merge them as soon as possible.

Michael (johnsom)

On Fri, May 18, 2018 at 10:16 PM, rezroo  wrote:
> Hi - let's try this again - this time with pike :-)
> Any suggestions on how to get the image builder to create a larger loop
> device? I think that's what the problem is.
> Thanks in advance.
>
> 2018-05-19 05:03:04.523 | 2018-05-19 05:03:04.523 INFO
> diskimage_builder.block_device.level1.mbr [-] Write partition entry blockno
> [0] entry [0] start [2048] length [4190208]   [57/1588]
> 2018-05-19 05:03:04.523 | 2018-05-19 05:03:04.523 INFO
> diskimage_builder.block_device.utils [-] Calling [sudo sync]
> 2018-05-19 05:03:04.538 | 2018-05-19 05:03:04.537 INFO
> diskimage_builder.block_device.utils [-] Calling [sudo kpartx -avs
> /dev/loop3]
> 2018-05-19 05:03:04.642 | 2018-05-19 05:03:04.642 INFO
> diskimage_builder.block_device.utils [-] Calling [sudo mkfs -t ext4 -i 4096
> -J size=64 -L cloudimg-rootfs -U 376d4b4d-2597-4838-963a-3d
> 9c5fcb5d9c -q /dev/mapper/loop3p1]
> 2018-05-19 05:03:04.824 | 2018-05-19 05:03:04.823 INFO
> diskimage_builder.block_device.utils [-] Calling [sudo mkdir -p
> /tmp/dib_build.zv2VZo3W/mnt/]
> 2018-05-19 05:03:04.833 | 2018-05-19 05:03:04.833 INFO
> diskimage_builder.block_device.level3.mount [-] Mounting [mount_mkfs_root]
> to [/tmp/dib_build.zv2VZo3W/mnt/]
> 2018-05-19 05:03:04.834 | 2018-05-19 05:03:04.833 INFO
> diskimage_builder.block_device.utils [-] Calling [sudo mount
> /dev/mapper/loop3p1 /tmp/dib_build.zv2VZo3W/mnt/]
> 2018-05-19 05:03:04.850 | 2018-05-19 05:03:04.850 INFO
> diskimage_builder.block_device.blockdevice [-] create() finished
> 2018-05-19 05:03:05.527 | 2018-05-19 05:03:05.527 INFO
> diskimage_builder.block_device.blockdevice [-] Getting value for
> [image-block-device]
> 2018-05-19 05:03:06.168 | 2018-05-19 05:03:06.168 INFO
> diskimage_builder.block_device.blockdevice [-] Getting value for
> [image-block-devices]
> 2018-05-19 05:03:06.845 | 2018-05-19 05:03:06.845 INFO
> diskimage_builder.block_device.blockdevice [-] Creating fstab
> 2018-05-19 05:03:06.845 | 2018-05-19 05:03:06.845 INFO
> diskimage_builder.block_device.utils [-] Calling [sudo mkdir -p
> /tmp/dib_build.zv2VZo3W/built/etc]
> 2018-05-19 05:03:06.855 | 2018-05-19 05:03:06.855 INFO
> diskimage_builder.block_device.utils [-] Calling [sudo cp
> /tmp/dib_build.zv2VZo3W/states/block-device/fstab
> /tmp/dib_build.zv2VZo3W/bui
> lt/etc/fstab]
> 2018-05-19 05:03:12.946 | dib-run-parts Sat May 19 05:03:12 UTC 2018
> Sourcing environment file
> /tmp/in_target.d/finalise.d/../environment.d/10-bootloader-default-cmdline
> 2018-05-19 05:03:12.947 | + source
> /tmp/in_target.d/finalise.d/../environment.d/10-bootloader-default-cmdline
> 2018-05-19 05:03:12.947 | ++ export 'DIB_BOOTLOADER_DEFAULT_CMDLINE=nofb
> nomodeset vga=normal'
> 2018-05-19 05:03:12.947 | ++ DIB_BOOTLOADER_DEFAULT_CMDLINE='nofb nomodeset
> vga=normal'
> 2018-05-19 05:03:12.948 | dib-run-parts Sat May 19 05:03:12 UTC 2018
> Sourcing environment file
> /tmp/in_target.d/finalise.d/../environment.d/10-dib-init-system.bash
> 2018-05-19 05:03:12.950 | + source
> /tmp/in_target.d/finalise.d/../environment.d/10-dib-init-system.bash
> 2018-05-19 05:03:12.950 |  dirname
> /tmp/in_target.d/finalise.d/../environment.d/10-dib-init-system.bash
> 2018-05-19 05:03:12.951 | +++
> PATH='$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/tmp/in_target.d/finalise.d/../environment.d/..'
> 2018-05-19 05:03:12.951 | +++ dib-init-system
> 2018-05-19 05:03:12.953 | ++ DIB_INIT_SYSTEM=systemd
> 2018-05-19 05:03:12.953 | ++ export DIB_INIT_SYSTEM
> 2018-05-19 05:03:12.954 | dib-run-parts Sat May 19 05:03:12 UTC 2018
> Sourcing environment file
> /tmp/in_target.d/finalise.d/../environment.d/10-pip-cache
> 2018-05-19 05:03:12.955 | + source
> /tmp/in_target.d/finalise.d/../environment.d/10-pip-cache
> 2018-05-19 05:03:12.955 | ++ export PIP_DOWNLOAD_CACHE=/tmp/pip
> 2018-05-19 05:03:12.955 | ++ PIP_DOWNLOAD_CACHE=/tmp/pip
> 2018-05-19 05:03:12.956 | dib-run-parts Sat May 19 05:03:12 UTC 2018
> Sourcing environment file
> /tmp/in_target.d/finalise.d/../environment.d/10-ubuntu-distro-name.bash
> 2018-05-19 05:03:12.958 | + source
> /tmp/in_target.d/finalise.d/../environment.d/10-ubuntu-distro-name.bash
> 2018-05-19 05:03:12.958 | ++ export DISTRO_NAME=ubuntu
> 2018-05-19 05:03:12.958 | ++ DISTRO_NAME=ubuntu
> 2018-05-19 05:03:12.958 | ++ export DIB_RELEASE=xenial
> 2018-05-19 05:03:12.958 | ++ DIB_RELEASE=xenial
> 2018-05-19 05:03:12.959 | dib-run-parts Sat May 19 05:03:12 UTC 2018
> Sourcing environment file
> /tmp/in_target.d/finalise.d/../environment.d/11-dib-install-type.bash
> 2018-05-19 

Re: [openstack-dev] [devstack][python/pip][octavia] pip failure during octavia/ocata image build by devstack

[Michael Johnson]

Hi rezroo,

Yes, the recent release of pip 10 broke the disk image building.
There is a patch posted here: https://review.openstack.org/#/c/562850/
pending review that works around this issue for the ocata branch by
pining the pip used for the image building to a version that does not
have this issue.

Michael


On Thu, May 17, 2018 at 7:38 PM, rezroo  wrote:
> Hello - I'm trying to install a working local.conf devstack ocata on a new
> server, and some python packages have changed so I end up with this error
> during the build of octavia image:
>
> 2018-05-18 01:00:26.276 |   Found existing installation: Jinja2 2.8
> 2018-05-18 01:00:26.280 | Uninstalling Jinja2-2.8:
> 2018-05-18 01:00:26.280 |   Successfully uninstalled Jinja2-2.8
> 2018-05-18 01:00:26.839 |   Found existing installation: PyYAML 3.11
> 2018-05-18 01:00:26.969 | Cannot uninstall 'PyYAML'. It is a distutils
> installed project and thus we cannot accurately determine which files belong
> to it which would lead to only a partial uninstall.
>
> 2018-05-18 02:05:44.768 | Unmount
> /tmp/dib_build.2fbBBePD/mnt/var/cache/apt/archives
> 2018-05-18 02:05:44.796 | Unmount /tmp/dib_build.2fbBBePD/mnt/tmp/pip
> 2018-05-18 02:05:44.820 | Unmount
> /tmp/dib_build.2fbBBePD/mnt/tmp/in_target.d
> 2018-05-18 02:05:44.844 | Unmount /tmp/dib_build.2fbBBePD/mnt/tmp/ccache
> 2018-05-18 02:05:44.868 | Unmount /tmp/dib_build.2fbBBePD/mnt/sys
> 2018-05-18 02:05:44.896 | Unmount /tmp/dib_build.2fbBBePD/mnt/proc
> 2018-05-18 02:05:44.920 | Unmount /tmp/dib_build.2fbBBePD/mnt/dev/pts
> 2018-05-18 02:05:44.947 | Unmount /tmp/dib_build.2fbBBePD/mnt/dev
> 2018-05-18 02:05:50.668 |
> +/opt/stack/octavia/devstack/plugin.sh:build_octavia_worker_image:1
> exit_trap
> 2018-05-18 02:05:50.679 | +./devstack/stack.sh:exit_trap:494 local
> r=1
> 2018-05-18 02:05:50.690 | ++./devstack/stack.sh:exit_trap:495 jobs
> -p
> 2018-05-18 02:05:50.700 | +./devstack/stack.sh:exit_trap:495 jobs=
> 2018-05-18 02:05:50.710 | +./devstack/stack.sh:exit_trap:498 [[ -n
> '' ]]
> 2018-05-18 02:05:50.720 | +./devstack/stack.sh:exit_trap:504
> kill_spinner
> 2018-05-18 02:05:50.731 | +./devstack/stack.sh:kill_spinner:390  '[' '!'
> -z '' ']'
> 2018-05-18 02:05:50.741 | +./devstack/stack.sh:exit_trap:506 [[ 1
> -ne 0 ]]
> 2018-05-18 02:05:50.751 | +./devstack/stack.sh:exit_trap:507 echo
> 'Error on exit'
> 2018-05-18 02:05:50.751 | Error on exit
> 2018-05-18 02:05:50.761 | +./devstack/stack.sh:exit_trap:508
> generate-subunit 1526608058 1092 fail
> 2018-05-18 02:05:51.148 | +./devstack/stack.sh:exit_trap:509 [[ -z
> /tmp ]]
> 2018-05-18 02:05:51.157 | +./devstack/stack.sh:exit_trap:512
> /home/stack/devstack/tools/worlddump.py -d /tmp
>
> I've tried pip uninstalling PyYAML and pip installing it before running
> stack.sh, but the error comes back.
>
> $ sudo pip uninstall PyYAML
> The directory '/home/stack/.cache/pip/http' or its parent directory is not
> owned by the current user and the cache has been disabled. Please check the
> permissions and owner of that directory. If executing pip with sudo, you may
> want sudo's -H flag.
> Uninstalling PyYAML-3.12:
>   /usr/local/lib/python2.7/dist-packages/PyYAML-3.12.dist-info/INSTALLER
>   /usr/local/lib/python2.7/dist-packages/PyYAML-3.12.dist-info/METADATA
>   /usr/local/lib/python2.7/dist-packages/PyYAML-3.12.dist-info/RECORD
>   /usr/local/lib/python2.7/dist-packages/PyYAML-3.12.dist-info/WHEEL
>   /usr/local/lib/python2.7/dist-packages/PyYAML-3.12.dist-info/top_level.txt
>   /usr/local/lib/python2.7/dist-packages/_yaml.so
> Proceed (y/n)? y
>   Successfully uninstalled PyYAML-3.12
>
> I've posted my question to the pip folks and they think it's an openstack
> issue: https://github.com/pypa/pip/issues/4805
>
> Is there a workaround here?
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5

[Michael Johnson]

The Octavia project had other breakage due to sphinx > 1.7 but we have
already resolved those issues.

Back story: the way arguments are handled for apidoc changed.
An example patch for the fix would be: https://review.openstack.org/#/c/568383/

Michael (johnsom)

On Wed, May 16, 2018 at 1:59 PM, Matthew Thode
 wrote:
> Sphinx has breaking changes (yet again) and we need to figure out how to
> deal with it.  I think the fix will be simple for affected projects, but
> we should probably move forward on this.  The error people are getting
> seems to be 'Field list ends without a blank line; unexpected unindent.'
>
> I'd like to keep on 1.7.4 and have the affected projects fix the error
> so we can move on, but the revert has been proposed (and approved to get
> gate unbroken for them).  https://review.openstack.org/568248  Any
> advice from the community is welcome.
>
> --
> Matthew Thode (prometheanfire)
>
> __
> 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] [octavia] Weekly IRC meeting cancelled May 23rd

[Michael Johnson]

Some of the team will be attending the OpenStack summit in Vancouver,
so I am cancelling the weekly IRC meeting for the 23rd.

We will resume our normal schedule on the 30th.

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

Re: [openstack-dev] [octavia] Sometimes amphoras are not re-created if they are not reached for more than heartbeat_timeout

[Michael Johnson]

I have commented on both of those stories. Thank you for submitting them.

As for the values,this is hard as those settings depend on a lot of
factors. The default values are targeted towards developers and likely
need to be adjusted for production. We have not yet put together our
deployment guide where we would cover this type of tuning. Sigh, so
much to do and not enough team members.

Here are some comments I can give on those settings:
[health_manager]
failover_threads - This is the maximum number of parallel failovers
each instance (process) of the octavia-healthmanager can process at
the same time. Beyond this number they queue until a thread becomes
available. If your cloud is fairly stable and you have few health
managers, this can be a reasonably low number. Consider the maximum
number of amphora you would have on a single compute host should it
fail. Also take into account the CPU power available on the health
manager host.

status_update_threads - This is the maximum number of health heartbeat
messages each instance (process) of the octavia-healthmanager can
process at the same time.  The more octavia-healthmanagers you have,
the lower this can be. The upper limit on this is related to how fast
your database is processing the updates. Should this number be too
low, the heatlh manager will start logging warnings that you need more
health managers.

[haproxy_amphora]
build_rate_limit
build_active_retries
These two settings are only used if build rate limiting is enabled
(not by default). This would be set if your Nova infrastructure cannot
handle the rate of instance builds Octavia is asking of it. This will
prioritize instance builds based on the need and will limit the rate
of instance builds Octavia asks Nova for.  The only impact to the
Octavia controllers is increased memory utilization if there are a
large number of builds being queued waiting for Nova.

You missed these two:
connection_max_retries
connection_retry_interval
These values are typically adjusted in production environments as they
are tuned for exceeding slow development systems (virtualbox, etc.)
where booting instances can take up to twenty minutes. This is the
time after Nova declares the instance "ACTIVE" and when the kernel
finishes booting in the instance and the amphora agent is running. The
default is to wait 25 minutes. In production you would expect to drop
this number significantly.  On a typical cloud this should take less
than thirty seconds, but you should give it some buffer in case a host
is especially busy.  Again this depends on the performance of your
cloud.


[controller_worker]
workers - This is the number of worker threads pulling user requests
from the oslo messaging queue for each instance of the octavia-worker
process.  This number would be tuned depending on the number of worker
controllers you have in your cloud and the rate of user requests
(create, update, delete) that need to be serviced by a worker. GET
calls do not require a worker. This will also be limited by the
controller host CPU and RAM capacities.

amp_active_retries
amp_active_wait_sec
Both of these values depend on the performance of your Nova
environment. This is how many times and how often we check Nova to see
if a requested instance has become "ACTIVE". Unless your Nova
environment is unusually slow, you should not need to change these
values.


[task_flow]
max_workers - This value limits the parallelism inside the TaskFlow
flows used by the controllers. Currently there is little reason to
adjust this value as the degrees of parallelism in our flows are not
higher than this value. However, when we release Active-Active load
balancers this value will control the number of parallel amphora
builds up to the build limit above.

Michael

On Thu, May 3, 2018 at 1:51 AM,  <mihaela.ba...@orange.com> wrote:
> Hi Michael,
>
> I build a new amphora image with the latest patches and I reproduced two 
> different bugs that I see in my environment. One of them is similar to the 
> one initially described in this thread. I opened two stories as you advised:
>
> https://storyboard.openstack.org/#!/story/2001960
> https://storyboard.openstack.org/#!/story/2001955
>
> Meanwhile, can you provide some recommendation of values for the following 
> parameters (maybe in relation with number of workers, cores, computes etc)?
>
> [health_manager]
> failover_threads
> status_update_threads
>
> [haproxy_amphora]
> build_rate_limit
> build_active_retries
>
> [controller_worker]
> workers
> amp_active_retries
> amp_active_wait_sec
>
> [task_flow]
> max_workers
>
> Thank you for your help,
> Mihaela Balas
>
> -Original Message-
> From: Michael Johnson [mailto:johnso...@gmail.com]
> Sent: Friday, April 27, 2018 8:24 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [oc

Re: [openstack-dev] [api] [lbaas] Neutron LBaaS V2 docs incompatibility

[Michael Johnson]

Hi Artem,

You are correct that the API reference at
https://developer.openstack.org/api-ref/network/v2/index.html#pools is
incorrect. As you figured out, someone mistakenly merged the long
dead/removed LBaaS v1 API specification into the LBaaS v2 API
specification at that link.

The current, and up to date load balancing API reference is at:
https://developer.openstack.org/api-ref/load-balancer/v2/index.html

This documents the Octavia API which is a superset of the the LBaaS v2
API, so it should help you clarify any issues you run into.

That said, due to the deprecation of neutron-lbaas and spin out from
neutron we decided to explicitly not support neutron-lbaas in the
OpenStack Client. neutron-lbaas is only supported using the neutron
client.  You can continue to use the neutron client CLI with
neutron-lbaas through the neutron-lbaas deprecation cycle.

When you move to using Octavia you can switch to using the
python-octaviaclient OSC plugin.

Michael

On Wed, Apr 25, 2018 at 5:51 AM, Artem Goncharov
 wrote:
> Hi all,
>
> after working with OpenStackSDK in my cloud I have found one difference in
> the Neutron LBaaS (yes, I know it is deprecated, but it is still used). The
> fix would be small and fast, unfortunately I have faced problems with the
> API description:
> - https://wiki.openstack.org/wiki/Neutron/LBaaS/API_2.0#Pools describes,
> that the LB pool has healthmonitor_id attribute (what eventually also fits
> reality of my cloud)
> - https://developer.openstack.org/api-ref/network/v2/index.html#pools (which
> is referred to from the previous link in the deprecation note) describes,
> that the LB pool has healthmonitors (and healthmonitors_status) as list of
> IDs. Basically in this regards it is same as
> https://wiki.openstack.org/wiki/Neutron/LBaaS/API_1.0#Pool description
> - unfortunately even
> https://github.com/openstack/neutron-lib/blob/master/api-ref/source/v2/lbaas-v2.inc
> describes Pool.healthmonitors (however it also contains
> https://github.com/openstack/neutron-lib/blob/master/api-ref/source/v2/samples/lbaas/pools-list-response2.json
> sample with the Pool.healthmonitor_id)
> - OpenStackSDK contains network.pool.health_monitors (with underscore)
>
> I want to bring this all in an order and enable managing of the loadbalancer
> through OSC for my OpenStack cloud, but I can't figure out what is the
> correct behavior here.
>
> Can anybody, please, help in figuring out the truth here?
>
> Thanks,
> Artem
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [octavia] Sometimes amphoras are not re-created if they are not reached for more than heartbeat_timeout

[Michael Johnson]

Hi Mihaela,

I am sorry to hear you are having trouble with the queens release of
Octavia.  It is true that a lot of work has gone into the failover
capability, specifically working around a python threading issue and
making it more resistant to certain neutron failure situations
(missing ports, etc.).

I know of one open bug against the failover flows,
https://storyboard.openstack.org/#!/story/2001481, "failover breaks in
Active/Standby mode if both amphroae are down".

Unfortunately the log snippet above does not give me enough
information about the problem to help with this issue. From the
snippet it looks like the failovers were initiated, but the
controllers are unable to reach the amphora-agent on the replacement
amphora. It will continue those retry attempts, but eventually will
fail the amphora into ERROR if it doesn't succeed.

One thought I have is if you created you amphora image in the last two
weeks, you may have built an amphora using the master branch of
octavia, which had a bug that impacted active/standby images. This was
introduced working around the new pip 10 issues.  That patch has been
fixed: https://review.openstack.org/#/c/564371/

If neither of these situations match your environment, please open a
story (https://storyboard.openstack.org/#!/dashboard/stories) for us
and include the health manager logs from the point you delete the
amphora up until it starts these connection attempts.  We will dig
through those logs to see what the issue might be.

Michael (johnsom)

On Wed, Apr 25, 2018 at 4:07 AM,   wrote:
> Hello,
>
>
>
> I am testing Octavia Queens and I see that the failover behavior is very
> much different than the one in Ocata (this is the version we are currently
> running in production).
>
> One example of such behavior is:
>
>
>
> I create 4 load balancers and after the creation is successful, I shut off
> all the 8 amphoras. Sometimes, even the health-manager agent does not reach
> the amphoras, they are not deleted and re-created. The logs look like shown
> below even when the heartbeat timeout is long passed. Sometimes the amphoras
> are deleted and re-created. Sometimes,  they are partially re-created – part
> of them remain in shut off.
>
> Heartbeat_timeout is set to 60 seconds.
>
>
>
>
>
>
>
> [octavia-health-manager-3662231220-nxnt3] 2018-04-25 10:57:26.244 11 WARNING
> octavia.amphorae.drivers.haproxy.rest_api_driver
> [req-339b54a7-ab0c-422a-832f-a444cd710497 - a5f15235c0714365b98a50a11ec956e7
> - - -] Could not connect to instance. Retrying.: ConnectionError:
> HTTPSConnectionPool(host='192.168.0.15', port=9443): Max retries exceeded
> with url:
> /0.5/listeners/285ad342-5582-423e-b654-1f0b50d91fb2/certificates/octaviasrv2.orange.com.pem
> (Caused by NewConnectionError(' object at 0x7f559862c710>: Failed to establish a new connection: [Errno 113]
> No route to host',))
>
> [octavia-health-manager-3662231220-3lssd] 2018-04-25 10:57:26.464 13 WARNING
> octavia.amphorae.drivers.haproxy.rest_api_driver
> [req-a63b795a-4b4f-4b90-a201-a4c9f49ac68b - a5f15235c0714365b98a50a11ec956e7
> - - -] Could not connect to instance. Retrying.: ConnectionError:
> HTTPSConnectionPool(host='192.168.0.14', port=9443): Max retries exceeded
> with url:
> /0.5/listeners/a45bdef3-e7da-4a18-9f1f-53d5651efe0f/1615c1ec-249e-4fa8-9d73-2397e281712c/haproxy
> (Caused by NewConnectionError(' object at 0x7f8a0de95e10>: Failed to establish a new connection: [Errno 113]
> No route to host',))
>
> [octavia-health-manager-3662231220-nxnt3] 2018-04-25 10:57:27.772 11 WARNING
> octavia.amphorae.drivers.haproxy.rest_api_driver
> [req-10febb10-85ea-4082-9df7-daa48894b004 - a5f15235c0714365b98a50a11ec956e7
> - - -] Could not connect to instance. Retrying.: ConnectionError:
> HTTPSConnectionPool(host='192.168.0.19', port=9443): Max retries exceeded
> with url:
> /0.5/listeners/96ce5862-d944-46cb-8809-e1e328268a66/fc5b7940-3527-4e9b-b93f-1da3957a5b71/haproxy
> (Caused by NewConnectionError(' object at 0x7f5598491c90>: Failed to establish a new connection: [Errno 113]
> No route to host',))
>
> [octavia-health-manager-3662231220-nxnt3] 2018-04-25 10:57:34.252 11 WARNING
> octavia.amphorae.drivers.haproxy.rest_api_driver
> [req-339b54a7-ab0c-422a-832f-a444cd710497 - a5f15235c0714365b98a50a11ec956e7
> - - -] Could not connect to instance. Retrying.: ConnectionError:
> HTTPSConnectionPool(host='192.168.0.15', port=9443): Max retries exceeded
> with url:
> /0.5/listeners/285ad342-5582-423e-b654-1f0b50d91fb2/certificates/octaviasrv2.orange.com.pem
> (Caused by NewConnectionError(' object at 0x7f5598520790>: Failed to establish a new connection: [Errno 113]
> No route to host',))
>
> [octavia-health-manager-3662231220-3lssd] 2018-04-25 10:57:34.476 13 WARNING
> octavia.amphorae.drivers.haproxy.rest_api_driver
> [req-a63b795a-4b4f-4b90-a201-a4c9f49ac68b - a5f15235c0714365b98a50a11ec956e7
> - - -] Could not connect to instance. Retrying.: ConnectionError:
> 

Re: [openstack-dev] [all] [api] Re-Reminder on the state of WSME

[Michael Johnson]

I am willing to help with maintenance (patch reviews/gate fixes), but
I cannot commit time to development work on it.

Michael

On Wed, Apr 11, 2018 at 6:21 AM, Chris Dent  wrote:
> On Wed, 11 Apr 2018, Dougal Matthews wrote:
>
>> I would like to see us move away from WSME. I'm not sure I have time to
>> drive an effort in finding a replacement (and migration path) but I would
>> certainly like to help.
>
>
> Dougal and I talked about this in IRC and agreed that being able to
> merge changes in WSME would help the goal of establishing a
> migration path. So I've added him to WSME cores.
>
>
> --
> 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
>

__
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] [api] Re-Reminder on the state of WSME

[Michael Johnson]

I echo Ben's question about what is the recommended replacement.

Not long ago we were advised to use WSME over the alternatives which
is why Octavia is using the WSME types and pecan extension.

Thanks,
Michael

On Mon, Apr 9, 2018 at 10:16 AM, Ben Nemec  wrote:
>
>
> On 04/09/2018 07:22 AM, Chris Dent wrote:
>>
>>
>> A little over two years ago I sent a reminder that WSME is not being
>> actively maintained:
>>
>>
>> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088658.html
>>
>> Today I was reminded of this becasue a random (typo-related)
>> patchset demonstrated that the tests were no longer passing and
>> fixing them is enough of a chore that I (at least temporarily)
>> marked one test as an expected failure.o
>>
>>  https://review.openstack.org/#/c/559717/
>>
>> The following projects appear to still use WSME:
>>
>>  aodh
>>  blazar
>>  cloudkitty
>>  cloudpulse
>>  cyborg
>>  glance
>>  gluon
>>  iotronic
>>  ironic
>>  magnum
>>  mistral
>>  mogan
>>  octavia
>>  panko
>>  qinling
>>  radar
>>  ranger
>>  searchlight
>>  solum
>>  storyboard
>>  surveil
>>  terracotta
>>  watcher
>>
>> Most of these are using the 'types' handling in WSME and sometimes
>> the pecan extension, and not the (potentially broken) Flask
>> extension, so things should be stable.
>>
>> However: nobody is working on keeping WSME up to date. It is not a
>> good long term investment.
>
>
> What would be the recommended alternative, either for new work or as a
> migration path for existing projects?
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [ALL][PTLs] [Community goal] Toggle the debug option at runtime

[Michael Johnson]

Yeah, neutron-lbaas runs in the context of the neutron service (it is
a neutron extension), so would be covered by neutron completing the
goal.

Michael

On Fri, Apr 6, 2018 at 3:37 AM, Sławek Kapłoński  wrote:
> Hi,
>
> Thanks Akihiro for help. I added „neutron-dynamic-routing” task to this story 
> and I will push patch for it soon.
> There is still so many things that I need to learn about OpenStack and 
> Neutron :)
>
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
>
>
>
>
>> Wiadomość napisana przez Akihiro Motoki  w dniu 
>> 06.04.2018, o godz. 11:34:
>>
>>
>> Hi Slawek,
>>
>> 2018-04-06 17:38 GMT+09:00 Sławek Kapłoński :
>> Hi,
>>
>> One more question about implementation of this goal. Should we take care 
>> (and add to story board [1]) projects like:
>>
>> In my understanding, tasks in the storyboard story are prepared per project 
>> team listed in the governance.
>> IMHO, repositories which belong to a project team should be handled as a 
>> single task.
>>
>> The situations vary across repositories.
>>
>>
>> openstack/neutron-lbaas
>>
>> This should be covered by octavia team.
>>
>> openstack/networking-cisco
>> openstack/networking-dpm
>> openstack/networking-infoblox
>> openstack/networking-l2gw
>> openstack/networking-lagopus
>>
>> The above repos are not official repos.
>> Maintainers of each repo can follow the community goal, but there is no need 
>> to be tracked as the neutron team.
>>
>> openstack/neutron-dynamic-routing
>>
>> This repo is part of the neutron team. We, the neutron team need to cover 
>> this.
>>
>> FYI: The official repositories covered by the neutron team is available here.
>> https://governance.openstack.org/tc/reference/projects/neutron.html
>>
>> Thanks,
>> Akihiro
>>
>>
>> Which looks that should be probably also changed in some way. Or maybe list 
>> of affected projects in [1] is „closed” and if some project is not there it 
>> shouldn’t be changed to accomplish this community goal?
>>
>> [1] https://storyboard.openstack.org/#!/story/2001545
>>
>> —
>> Best regards
>> Slawek Kaplonski
>> sla...@kaplonski.pl
>>
>>
>>
>>
>> > Wiadomość napisana przez ChangBo Guo  w dniu 
>> > 26.03.2018, o godz. 14:15:
>> >
>> >
>> > 2018-03-22 16:12 GMT+08:00 Sławomir Kapłoński :
>> > Hi,
>> >
>> > I took care of implementation of [1] in Neutron and I have couple 
>> > questions to about this goal.
>> >
>> > 1. Should we only change "restart_method" to mutate as is described in [2] 
>> > ? I did already something like that in [3] - is it what is expected?
>> >
>> >  Yes , let's the only  thing.  we need test if that if it works .
>> >
>> > 2. How I can check if this change is fine and config option are mutable 
>> > exactly? For now when I change any config option for any of neutron agents 
>> > and send SIGHUP to it it is in fact "restarted" and config is reloaded 
>> > even with this old restart method.
>> >
>> > good question, we indeed thought this question when we proposal  the 
>> > goal.  But It seems difficult to test  that consuming projects like 
>> > Neutron automatically.
>> >
>> > 3. Should we add any automatic tests for such change also? Any examples of 
>> > such tests in other projects maybe?
>> >  There is no example for tests now, we only have some unit tests  in 
>> > oslo.service .
>> >
>> > [1] 
>> > https://governance.openstack.org/tc/goals/rocky/enable-mutable-configuration.html
>> > [2] https://docs.openstack.org/oslo.config/latest/reference/mutable.html
>> > [3] https://review.openstack.org/#/c/554259/
>> >
>> > —
>> > Best regards
>> > Slawek Kaplonski
>> > sla...@kaplonski.pl
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> > --
>> > ChangBo Guo(gcb)
>> > Community Director @EasyStack
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Re: [openstack-dev] [octavia] Proposing Jacky Hu (dayou) as an Octavia core reviewer

[Michael Johnson]

That is quorum.  Welcome Jacky our new core reviewer for Octavia.

Michael

On Tue, Mar 27, 2018 at 7:40 AM, Nir Magnezi <nmagn...@redhat.com> wrote:
> +1. Well earned Jacky, Congratulations!
>
> On Tue, Mar 27, 2018 at 8:31 AM, Adam Harwell <flux.a...@gmail.com> wrote:
>>
>> +1, definitely a good contributor! Thanks especially for your work on the
>> dashboard!
>>
>> On Tue, Mar 27, 2018 at 2:09 PM German Eichberger
>> <german.eichber...@rackspace.com> wrote:
>>>
>>> +1
>>>
>>> Really excited to work with Jacky --
>>>
>>> German
>>>
>>> On 3/26/18, 8:33 PM, "Michael Johnson" <johnso...@gmail.com> wrote:
>>>
>>> Hello Octavia community,
>>>
>>> I would like to propose Jacky Hu (dayou) as a core reviewer on the
>>> Octavia project.
>>>
>>> Jacky has done amazing work on Octavia dashboard, specifically
>>> updating the look and feel of our details pages to be more user
>>> friendly.  Recently he has contributed support for L7 policies in the
>>> dashboard and caught us up with the wider Horizon framework advances.
>>>
>>> Jacky has also contributed thoughtful reviews on the main Octavia
>>> project as well as contributed to the L3 Active/Active work in
>>> progress.
>>>
>>> Jacky's review statistics are in line with the other core reviewers
>>> [1] and I feel Jacky would make a great addition to the Octavia core
>>> reviewer team.
>>>
>>> Existing Octavia core reviewers, please reply to this email with your
>>> support or concerns with adding Jacky to the core team.
>>>
>>> Michael
>>>
>>> [1] http://stackalytics.com/report/contribution/octavia-group/90
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
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][PTLs] [Community goal] Toggle the debug option at runtime

[Michael Johnson]

Does anyone know how this will work with services that are using
cotyledon instead of oslo.service (for eliminating eventlet)?

Michael

On Mon, Mar 26, 2018 at 5:35 AM, Sławomir Kapłoński  wrote:
> Hi,
>
>
>> Wiadomość napisana przez ChangBo Guo  w dniu 
>> 26.03.2018, o godz. 14:15:
>>
>>
>> 2018-03-22 16:12 GMT+08:00 Sławomir Kapłoński :
>> Hi,
>>
>> I took care of implementation of [1] in Neutron and I have couple questions 
>> to about this goal.
>>
>> 1. Should we only change "restart_method" to mutate as is described in [2] ? 
>> I did already something like that in [3] - is it what is expected?
>>
>>  Yes , let's the only  thing.  we need test if that if it works .
>
> Ok, so please take a look at my patch for neutron if that is what we should 
> do :)
>
>>
>> 2. How I can check if this change is fine and config option are mutable 
>> exactly? For now when I change any config option for any of neutron agents 
>> and send SIGHUP to it it is in fact "restarted" and config is reloaded even 
>> with this old restart method.
>>
>> good question, we indeed thought this question when we proposal  the 
>> goal.  But It seems difficult to test  that consuming projects like Neutron 
>> automatically.
>
> I was asking rather about some manual test instead of automatic one.
>
>>
>> 3. Should we add any automatic tests for such change also? Any examples of 
>> such tests in other projects maybe?
>>  There is no example for tests now, we only have some unit tests  in 
>> oslo.service .
>>
>> [1] 
>> https://governance.openstack.org/tc/goals/rocky/enable-mutable-configuration.html
>> [2] https://docs.openstack.org/oslo.config/latest/reference/mutable.html
>> [3] https://review.openstack.org/#/c/554259/
>>
>> —
>> Best regards
>> Slawek Kaplonski
>> sla...@kaplonski.pl
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> --
>> ChangBo Guo(gcb)
>> Community Director @EasyStack
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
>
>
> __
> 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] [octavia] Proposing Jacky Hu (dayou) as an Octavia core reviewer

[Michael Johnson]

Hello Octavia community,

I would like to propose Jacky Hu (dayou) as a core reviewer on the
Octavia project.

Jacky has done amazing work on Octavia dashboard, specifically
updating the look and feel of our details pages to be more user
friendly.  Recently he has contributed support for L7 policies in the
dashboard and caught us up with the wider Horizon framework advances.

Jacky has also contributed thoughtful reviews on the main Octavia
project as well as contributed to the L3 Active/Active work in
progress.

Jacky's review statistics are in line with the other core reviewers
[1] and I feel Jacky would make a great addition to the Octavia core
reviewer team.

Existing Octavia core reviewers, please reply to this email with your
support or concerns with adding Jacky to the core team.

Michael

[1] http://stackalytics.com/report/contribution/octavia-group/90

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

Re: [openstack-dev] [Octavia] Using Octavia without neutron's extensions allowed-address-pairs and security-groups.

[Michael Johnson]

Hi Vadim,

Yes, currently the only network driver available for Octavia (called
allowed-address-pairs) uses the allowed-address-pairs feature of
neutron. This allows active/standby and VIP migration during failover
situations.

If you need to run without that feature, an non-allowed-address-pairs
driver will need to be created. This driver would not support the
active/standby load balancer topology.

Michael

On Thu, Mar 15, 2018 at 1:39 AM, Вадим Пономарев  wrote:
> Hi,
>
> I'm trying to install Octavia (from branch master) in my openstack
> installation. In my installation, neutron works with disabled extension
> allowed-address-pairs and disabled extension security-groups. This is done
> to improve performance. At the moment, i see that Octavia supporting for
> neutron only the network_driver allowed_address_pairs_driver, but this
> driver requires the extensions [1]. How can i use Octavia without the
> extensions? Or the only option is to write your own driver?
>
> [1]
> https://github.com/openstack/octavia/blob/master/octavia/network/drivers/neutron/allowed_address_pairs.py#L57
>
> --
> Best regards,
> Vadim Ponomarev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [QA][all] Migration of Tempest / Grenade jobs to Zuul v3 native

[Michael Johnson]

FYI, Octavia has started to use the new devstack-tempest parent here:
https://review.openstack.org/#/c/543034/17/zuul.d/jobs.yaml
There is a lot of work still left to do on our tempest-plugin but we
are making progress.

Thanks for the communication out!

Michael


On Tue, Feb 20, 2018 at 1:22 PM, Andrea Frittoli
 wrote:
> Dear all,
>
> updates:
>
> - host/group vars: zuul now supports declaring host and group vars in the
> job definition [0][1] - thanks corvus and infra team!
>   This is a great help towards writing the devstack and tempest base
> multinode jobs [2][3]
>   * NOTE: zuul merges dict variables through job inheritance. Variables in
> host/group_vars override global ones. I will write some examples further
> clarify this.
>
> - stable/pike: devstack ansible changes have been backported to stable/pike,
> so we can now run zuulv3 jobs against stable/pike too - thank you tosky!
>   next change in progress related to pike is to provide tempest-full-pike
> for branchless repositories [4]
>
> - documentation: devstack now publishes documentation on its ansible roles
> [5].
>   More devstack documentation patches are in progress to provide jobs
> reference, examples and a job migration how-to [6].
>
>
> Andrea Frittoli (andreaf)
>
> [0]
> https://docs.openstack.org/infra/zuul/user/config.html#attr-job.host_vars
> [1]
> https://docs.openstack.org/infra/zuul/user/config.html#attr-job.group_vars
> [2] https://review.openstack.org/#/c/545696/
> [3] https://review.openstack.org/#/c/545724/
> [4] https://review.openstack.org/#/c/546196/
> [5] https://docs.openstack.org/devstack/latest/roles.html
> [6] https://review.openstack.org/#/c/545992/
>
>
> On Mon, Feb 19, 2018 at 2:46 PM Andrea Frittoli 
> wrote:
>>
>> Dear all,
>>
>> updates:
>> - tempest-full-queens and tempest-full-py3-queens are now available for
>> testing of branchless repositories [0]. They are used for tempest and
>> devstack-gate. If you own a tempest plugin in a branchless repo, you may
>> consider adding similar jobs to your plugin if you use it for tests on
>> stable/queen as well.
>> - if you have migrated jobs based on devstack-tempest please let me know,
>> I'm building reference docs and I'd like to include as many examples as
>> possible
>> - work on multi-node is in progress, but not ready still - you can follow
>> the patches in the multinode branch [1]
>> - updates on some of the points from my previous email are inline below
>>
>> Andrea Frittoli (andreaf)
>>
>> [0] http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n73
>> [1]
>> https://review.openstack.org/#/q/status:open++branch:master+topic:multinode
>>
>>
>> On Thu, Feb 15, 2018 at 11:31 PM Andrea Frittoli
>>  wrote:
>>>
>>> Dear all,
>>>
>>> this is the first or a series of ~regular updates on the migration of
>>> Tempest / Grenade jobs to  Zuul v3 native.
>>>
>>> The QA team together with the infra team are working on providing the
>>> OpenStack community with a set of base Tempest / Grenade jobs that can be
>>> used as a basis to write new CI jobs / migrate existing legacy ones with a
>>> minimal effort and very little or no Ansible knowledge as a precondition.
>>>
>>> The effort is tracked in an etherpad [0]; I'm trying to keep the etherpad
>>> up to date but it may not always be a source of truth.
>>>
>>> Useful jobs available so far:
>>> - devstack-tempest [0] is a simple tempest/devstack job that runs
>>> keystone glance nova cinder neutron swift and tempest *smoke* filter
>>> - tempest-full [1] is similar but runs a full test run - it replaces the
>>> legacy tempest-dsvm-neutron-full from the integrated gate
>>> - tempest-full-py3 [2] runs a full test run on python3 - it replaces the
>>> legacy tempest-dsvm-py35
>>
>>
>> Some more details on this topic: what I did not mention in my previous
>> email is that the autogenerated Tempest / Grenade CI jobs (legacy-*
>> playbooks) are not meant to be used as a basis for Zuul V3 native jobs. To
>> create Zuul V3 Tempest / Grenade native jobs for your projects you need to
>> through away the legacy playbooks and defined new jobs in .zuul.yaml, as
>> documented in the zuul v3 docs [2].
>> The parent job for a single node Tempest job will usually be
>> devstack-tempest. Example migrated jobs are avilable, for instance: [3] [4].
>>
>> [2]
>> https://docs.openstack.org/infra/manual/zuulv3.html#howto-update-legacy-jobs
>> [3]
>> http://git.openstack.org/cgit/openstack/sahara-tests/tree/.zuul.yaml#n21
>> [4] https://review.openstack.org/#/c/543048/5
>>
>>>
>>>
>>> Both tempest-full and tempest-full-py3 are part of integrated-gate
>>> templates, starting from stable/queens on.
>>> The other stable branches still run the legacy jobs, since devstack
>>> ansible changes have not been backported (yet). If we do backport it will be
>>> up to pike maximum.
>>>
>>> Those jobs work in single node mode only at the moment. Enabling
>>> multinode 

Re: [openstack-dev] [neutron][lbaas][neutron-lbaas][octavia] Announcing the deprecation of neutron-lbaas and neutron-lbaas-dashboard

[Michael Johnson]

Hi Gary,

All of the answers to your questions are on the FAQ linked in the announcement.

1: If you are already using the Octavia driver or the neutron-lbaas
proxy driver, you are already migrated. We will provide a port
migration tool to migrate the neutron port ownership from
neutron-lbaas if neutron-lbaas was configured to create your VIP ports
for the Octavia driver.  For other drivers we will provide a migration
tool during Rocky. The databases are very similar so migrating from
neutron-lbaas will be fairly straight forward.
2: You are correct that currently there are no vendor drivers for
Octavia.  As you probably know, the new and improved driver interface
specification was merged during Queens (A representative from your
employer contributed to the specification).  We expect over the course
of Rocky vendor drivers will become available. This is part of the
motivation for announcing the start of deprecation.
3: This is in no way like the migration from LBaaS v1 to v2. The
largest reason is the LBaaS v2 API is fully compatible with the
Octavia API (it implements LBaaS v2). We did not change the model. The
current load balancer team can't really talk to the choices made in
the V1 to V2 API migrations.

As I have mentioned in the FAQ and on your patch comments,
neutron-lbaas will be maintained with bug fixes for the duration of
the deprecation cycle, which will be a minimum of two OpenStack
releases.

I am sorry you did not get to participate in the discussions and vote
for the start of the deprecation cycle.  We announced that we were
going to work towards this a year and a half ago in a specification
approved by the neutron cores:
http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html
It has been a major topic at our PTG sessions, summits, and weekly
meetings since then.  The team vote that we are ready to announce was
unanimous at our 1/24/2018 IRC meeting.

I hope you will join us going forward to make this deprecation a
success.  We meet weekly on IRC and will be at the PTG.

Michael

On Mon, Feb 12, 2018 at 4:12 AM, Gary Kotton  wrote:
> Hi,
> I have a number of issues with this:
> 1. I do not think that we should mark this as deprecated until we have a 
> clear and working migration patch. Let me give an example. Say I have a user 
> who is using Pike or Queens and has N LBaaS load balancers up and running. 
> What if we upgrade to T and there is no LBaaS, only Octavia. What is the 
> migration path here? Maybe I have missed this and would be happy to learn how 
> this was done.
> 2. I think that none of the load balancing vendors have code in Octavia and 
> this may be a problem (somewhat related to #1). I guess that there is enough 
> warning but this is still concerning
> 3. The migration from V1 to V2 was not successful. So, I have some concerns 
> about going to a new service completely.
> I prefer that we hold off on this until there is a clear picture.
> Thanks
> Gary
>
> On 2/1/18, 9:22 AM, "Andreas Jaeger"  wrote:
>
> On 2018-01-31 22:58, Akihiro Motoki wrote:
> > I don't think we need to drop translation support NOW (at least for
> > neutron-lbaas-dashboard).
> > There might be fixes which affects translation and/or there might be
> > translation improvements.
> > I don't think a deprecation means no translation fix any more. It
> > sounds too aggressive.
> > Is there any problem to keep translations for them?
>
> Reading the whole FAQ - since bug fixes are planned, translations can
> merge back. So, indeed we can keep translation infrastructure set up.
>
> I recommend to translators to remove neutron-lbaas-dashboard from the
> priority list,
>
> Andreas
>
> > Akihiro
> >
> > 2018-02-01 3:28 GMT+09:00 Andreas Jaeger :
> >> In that case, I suggest to remove translation jobs for these 
> repositories,
> >>
> >> Andreas
> >> --
> >>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
> >>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> >>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> >>HRB 21284 (AG Nürnberg)
> >> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 
> A126
> >>
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > 
> __
> > OpenStack 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] [PTL][SIG][PTG]Team Photos

[Michael Johnson]

Hi Kendall,

Can you put Octavia down for 2:10 on Thursday after neutron?
Thanks,
Michael


On Wed, Feb 7, 2018 at 9:15 PM, Kendall Nelson  wrote:
> Hello PTLs and SIG Chairs!
>
> So here's the deal, we have 50 spots that are first come, first served. We
> have slots available before and after lunch both Tuesday and Thursday.
>
> The google sheet here[1] should be set up so you have access to edit, but if
> you can't for some reason just reply directly to me and I can add your team
> to the list (I need team/sig name and contact email).
>
> I will be locking the google sheet on Monday February 26th so I need to know
> if your team is interested by then.
>
> See you soon!
>
> - Kendall Nelson (diablo_rojo)
>
> [1]
> https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [ptg] Track around release cycle, consumption models and stable branches

[Michael Johnson]

I am interested in contributing to this discussion.

Michael


On Wed, Feb 7, 2018 at 3:42 AM, Thierry Carrez  wrote:
> Hi everyone,
>
> I was wondering if anyone would be interested in brainstorming the
> question of how to better align our release cycle and stable branch
> maintenance with the OpenStack downstream consumption models. That
> includes discussing the place of the distributions, the need for LTS,
> and where does the open source upstream project stop.
>
> I have hesitated to propose it earlier, as it sounds like a topic that
> should be discussed with the wider community at the Forum. And it will,
> but it feels like this needs a deeper pre-discussion in a productive
> setting, and tonyb and eumel8 have been proposing that topic on the
> missing topics etherpad[1], so we might as well take some time at the
> PTG to cover that.
>
> Would anyone be interested in such a discussion ? It would be scheduled
> on the Tuesday. How much time would we need ? I was thinking we could
> use only Tuesday afternoon.
>
> [1] https://etherpad.openstack.org/p/PTG-Dublin-missing-topics
>
> --
> 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

__
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] Rocky Octavia PTL candidacy

[Michael Johnson]

My fellow OpenStack community,

I would like to nominate myself for Octavia PTL for Rocky. I am currently
the PTL for the Queens release series and would like to continue helping our
team provide network load balancing services for OpenStack.

For those of you that do not know me, I work for Rackspace. Prior to joining
Rackspace I worked for Hewlett-Packard for fifteen years on data center
automation, distributed network systems, embedded system design, and big data.

In the Queens release, we were able to add support for batch member updates,
QoS on the load balancer VIPs, support for Castellan, operator tooling, and
many more enhancements. Beyond that work, we laid the ground work for Rocky.

Looking forward to Rocky I expect the team to finish out some major new
features, such as Active/Active load balancers, UDP protocol support,
provider drivers, flavors, additional tempest tests and additional operator
tooling. I plan to continue working on improving our documentation,
specifically with detailed installation, high availability, and neutron-lbaas
migration guides.

Thank you for your support of Octavia during Queens and your consideration for
Rocky,

Michael Johnson (johnsom)

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

Re: [openstack-dev] [neutron-lbaas][octavia]Octavia request poll interval not respected

[Michael Johnson]

Hi Mihaela,

The polling logic that the neutron-lbaas octavia driver uses to update
the neutron database is as follows:

Once a Create/Update/Delete action is executed against a load balancer
using the Octavia driver a polling thread is created.
On every request_poll_interval the thread queries the Octavia v1 API
to check the status of the object modified.
It will save the updated state in the neutron databse and exit if the
objects provisioning status becomes on of: "ACTIVE", "DELETED", or
"ERROR".
It will repeat this polling until one of those provisioning statuses
is met, or the request_poll_timeout is exceeded.

My suspicion is the GET requests you are seeing for those objects is
occurring from another source.
You can test this by running neutron-lbaas in debug mode.  I will then
log a debug message for every polling interval.

The code for this thread is located here:
https://github.com/openstack/neutron-lbaas/blob/stable/ocata/neutron_lbaas/drivers/octavia/driver.py#L66

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] [neutron][lbaas][neutron-lbaas][octavia] Announcing the deprecation of neutron-lbaas and neutron-lbaas-dashboard

[Michael Johnson]

Today we are announcing the start of the deprecation cycle for
neutron-lbaas and neutron-lbaas-dashboard. As part of the neutron
stadium evolution [1], neutron-lbaas was identified as a project that
should spin out of neutron and become its own project. The
specification detailing this process was approved [2] during the
newton OpenStack release cycle.

OpenStack load balancing no longer requires deep access into the
neutron code base and database. All of the required networking
capabilities are now available via stable APIs. This change de-couples
the load balancing release versioning from the rest of the OpenStack
deployment. Since Octavia uses stable APIs when interacting with other
OpenStack services, you can run a different version of Octavia in
relation to your OpenStack cloud deployment.

Per OpenStack deprecation policy, both projects will continue to
receive support and bug fixes during the deprecation cycle, but no new
features will be added to either project. All future feature
enhancements will now occur on the Octavia project(s) [3].

We are not announcing the end of the deprecation cycle at this time,
but it will follow OpenStack policy of at least two release cycles
prior to retirement. This means that the first release that these
projects could be retired would be the “T” OpenStack release cycle.

We have created a Frequently Asked Questions (FAQ) wiki page to help
answer additional questions you may have about this process:
https://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation

For more information or if you have additional questions, please see
the following resources:

The FAQ: https://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation

The Octavia documentation: https://docs.openstack.org/octavia/latest/

Reach out to us via IRC on the Freenode IRC network, channel #openstack-lbaas

Weekly Meeting: 20:00 UTC on Wednesdays in #openstack-lbaas on the
Freenode IRC network.

Sending email to the OpenStack developer mailing list: openstack-dev
[at] lists [dot] openstack [dot] org. Please prefix the subject with
'[openstack-dev][Octavia]'

Thank you for your support and patience during this transition,

Michael Johnson
Octavia PTL

[1] 
http://specs.openstack.org/openstack/neutron-specs/specs/newton/neutron-stadium.html
[2] 
http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html
[3] https://governance.openstack.org/tc/reference/projects/octavia.html

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

Re: [openstack-dev] [cliff][osc][barbican][oslo][sdk][all] avoiding option name conflicts with cliff and OSC plugins

[Michael Johnson]

Should be no issues with python-octaviaclient, we do not use the short options.

Michael

On Fri, Jan 26, 2018 at 1:03 PM, Doug Hellmann  wrote:
> Excerpts from Doug Hellmann's message of 2018-01-18 10:15:16 -0500:
>> We've been working this week to resolve an issue between cliff and
>> barbicanclient due to a collision in the option namespace [0].
>> Barbicanclient was using the -s option, and then cliff's lister
>> command base class added that option as an alias for sort-columns.
>>
>> The first attempt at resolving the conflict was to set the conflict
>> handler in argparse to 'resolve' [1]. Several reviewers pointed out
>> that this would have the unwanted side-effect of making some OSC
>> commands support the -s as an alias for --sort-columns while the
>> barbicanclient commands would use it for a different purpose.
>>
>> For now we have removed the -s alias from within cliff. However,
>> we want to avoid this problem coming up in the future so we want a
>> better solution.
>>
>> The OSC project has a policy that its command plugins do not use
>> short options (single letter). There are relatively few of them,
>> and it's easy to introduce collisions.  Therefore, they are seen
>> as reserved for more common "global" options such as provided by
>> the base classes in OSC and cliff.
>>
>> I propose that for Rocky we update cliff to change the way options
>> are registered so that conflicting options added by command subclasses
>> are ignored. This would effectively let cliff "own" the short option
>> namespace, and require command classes to use long option names.
>>
>> The implementation details need to be worked out a bit, but I think
>> we can do that by subclassing ArgumentParser and adding a new
>> conflict handler method similar to the existing _handle_conflict_error()
>> and _handle_conflict_resolve().
>>
>> This is going to introduce backwards-incompatible changes in the
>> commands derived from cliff, so before we take any action I wanted
>> to solicit input in the plan.
>>
>> Please let me know what you think,
>> Doug
>>
>> [0] https://bugs.launchpad.net/python-barbicanclient/+bug/1743578
>> [1] https://docs.python.org/3.5/library/argparse.html#conflict-handler
>
> I have a patch up to implement this in https://review.openstack.org/538335
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [gate][devstack][neutron][qa][release] Switch to lib/neutron in gate

[Michael Johnson]

This sounds great Ihar!

Let us know when we should make the changes to the neutron-lbaas projects.

Michael


On Wed, Jan 17, 2018 at 11:26 AM, Ihar Hrachyshka  wrote:
> Hi all,
>
> tl;dr I propose to switch to lib/neutron devstack library in Queens. I
> ask for buy-in to the plan from release and QA teams, something that
> infra asked me to do.
>
> ===
>
> Last several cycles we were working on getting lib/neutron - the new
> in-tree devstack library to deploy neutron services - ready to deploy
> configurations we may need in our gates. Some pieces of the work
> involved can be found in:
>
> https://review.openstack.org/#/q/topic:new-neutron-devstack-in-gate
>
> I am happy to announce that the work finally got to the point where we
> can consistently pass both devstack-gate and neutron gates:
>
> (devstack-gate) https://review.openstack.org/436798
> (neutron) https://review.openstack.org/441579
>
> One major difference between the old lib/neutron-legacy library and
> the new lib/neutron one is that service names for neutron are
> different. For example, q-svc is now neutron-api, q-dhcp is now
> neutron-dhcp, etc. (In case you wonder, this q- prefix links us back
> to times when Neutron was called Quantum.) The way lib/neutron is
> designed is that whenever a single q-* service name is present in
> ENABLED_SERVICES, the old lib/neutron-legacy code is triggered to
> deploy services.
>
> Service name changes are a large part of the work. The way the
> devstack-gate change linked above is designed is that it changes names
> for deployed neutron services starting from Queens (current master),
> so old branches and grenade jobs are not affected by the change.
>
> While we validated the change switching to new names against both
> devstack-gate and neutron gates that should cover 90% of our neutron
> configurations, and followed up with several projects that - we
> induced - may be affected by the change - there is always a chance
> that some job in some project gate would fail because of it, and we
> would need to push a (probably rather simple) follow-up to unbreak the
> affected job. Due to the nature of the work, the span of impact, and
> the fact that infra repos are not easily gated against with Depends-On
> links, we may need to live with the risk.
>
> Of course, there are several aspects of the project life involved,
> including QA and release delivery efforts. I was advised to reach out
> to both of those teams to get a buy-in to proceed with the move. If we
> have support for the switch now, as per Clark, infra is ready to
> support the switch.
>
> Note that the effort span several cycles, partially due to low review
> velocity in several affected repos (devstack, devstack-gate),
> partially because new changes in all affected repos were pulling us
> back from the end goal. This is one of the reasons why I would like us
> to do the switch sooner rather than later, since chasing this moving
> goalpost became rather burdensome.
>
> What are QA and release team thoughts on the switch? Are we ready to
> do it in next weeks?
>
> Thanks for attention,
> Ihar
>
> __
> 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] [octavia] Weekly IRC meeting 12/27/17 cancelled

[Michael Johnson]

Hi everyone,

With many member of the Octavia team taking an end-of-year vacation we
are cancelling the next weekly meeting on 12/27/2017.  We will resume
our regular weekly meetings on 1/3/18.

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

Re: [openstack-dev] [octavia] cannot create loadbalancer on pike

[Michael Johnson]

Hi Kim,

Sorry you are having trouble after your upgrade.

From the log it appears that the neutron-lbaas Octavia driver is
unable to reach keystone to request an auth token.

Please make sure there is a [service_auth] section configured in your
neutron_lbaas.conf/neutron.conf file(s).

An example:

[service_auth]
auth_version = 3
admin_password = password
admin_user = admin
admin_tenant_name = admin
auth_url = http://172.21.21.134/identity/v3

Michael


On Thu, Dec 7, 2017 at 3:02 AM, Kim-Norman Sahm  wrote:
> after pupgrading ocata to pike i'm unable to create loadbalancer.
>
> # neutron lbaas-loadbalancer-create pike_sub
> neutron CLI is deprecated and will be removed in the future. Use openstack
> CLI instead.
> Driver error: The resource could not be found. (HTTP 404) (Request-ID:
> req-dff560fc-d1ed-49a8-9172-cc7c24bb4770)
> Neutron server returns request_ids:
> ['req-b00b6b7e-7ad1-4c7b-a147-acaa3cf267a7']
>
> neutron-server.log:
> 2017-12-07 10:58:25.698 19 INFO neutron_lbaas.services.loadbalancer.plugin
> [req-b00b6b7e-7ad1-4c7b-a147-acaa3cf267a7 339147b1f6df45508eff9388fd9931d7
> 1e90ad56f51b4daaa73a4f12fd422f43 - default default] Calling driver operation
> LoadBalancerManager.create
> 2017-12-07 10:58:25.811 19 DEBUG neutron_lbaas.drivers.driver_mixins
> [req-b00b6b7e-7ad1-4c7b-a147-acaa3cf267a7 339147b1f6df45508eff9388fd9931d7
> 1e90ad56f51b4daaa73a4f12fd422f43 - default default] Starting
> failed_completion method after a failed driver action. failed_completion
> /usr/lib/python2.7/dist-packages/neutron_lbaas/drivers/driver_mixins.py:185
> 2017-12-07 10:58:25.813 19 DEBUG neutron_lbaas.drivers.driver_mixins
> [req-b00b6b7e-7ad1-4c7b-a147-acaa3cf267a7 339147b1f6df45508eff9388fd9931d7
> 1e90ad56f51b4daaa73a4f12fd422f43 - default default] Updating load balancer
> a71dd90b-8f0f-4e00-9dd1-c4622c503431 to provisioning_status = ERROR,
> operating_status = OFFLINE. failed_completion
> /usr/lib/python2.7/dist-packages/neutron_lbaas/drivers/driver_mixins.py:191
> 2017-12-07 10:58:25.831 19 ERROR neutron_lbaas.services.loadbalancer.plugin
> [req-b00b6b7e-7ad1-4c7b-a147-acaa3cf267a7 339147b1f6df45508eff9388fd9931d7
> 1e90ad56f51b4daaa73a4f12fd422f43 - default default] There was an error in
> the driver: NotFound: The resource could not be found. (HTTP 404)
> (Request-ID: req-dff560fc-d1ed-49a8-9172-cc7c24bb4770)
> 2017-12-07 10:58:25.831 19 ERROR neutron_lbaas.services.loadbalancer.plugin
> Traceback (most recent call last):
> 2017-12-07 10:58:25.831 19 ERROR neutron_lbaas.services.loadbalancer.plugin
> File
> "/usr/lib/python2.7/dist-packages/neutron_lbaas/services/loadbalancer/plugin.py",
> line 176, in _call_driver_operation
> 2017-12-07 10:58:25.831 19 ERROR neutron_lbaas.services.loadbalancer.plugin
> driver_method(context, db_entity, **kwargs)
> 2017-12-07 10:58:25.831 19 ERROR neutron_lbaas.services.loadbalancer.plugin
> File
> "/usr/lib/python2.7/dist-packages/neutron_lbaas/drivers/octavia/driver.py",
> line 118, in func_wrapper
> 2017-12-07 10:58:25.831 19 ERROR neutron_lbaas.services.loadbalancer.plugin
> args[0].failed_completion(args[1], args[2])
> 2017-12-07 10:58:25.831 19 ERROR neutron_lbaas.services.loadbalancer.plugin
> File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in
> __exit__
> 2017-12-07 10:58:25.831 19 ERROR neutron_lbaas.services.loadbalancer.plugin
> self.force_reraise()
> 2017-12-07 10:58:25.831 19 ERROR neutron_lbaas.services.loadbalancer.plugin
> File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in
> force_reraise
> 2017-12-07 10:58:25.831 19 ERROR neutron_lbaas.services.loadbalancer.plugin
> six.reraise(self.type_, self.value, self.tb)
> 2017-12-07 10:58:25.831 19 ERROR neutron_lbaas.services.loadbalancer.plugin
> File
> "/usr/lib/python2.7/dist-packages/neutron_lbaas/drivers/octavia/driver.py",
> line 108, in func_wrapper
> 2017-12-07 10:58:25.831 19 ERROR neutron_lbaas.services.loadbalancer.plugin
> r = func(*args, **kwargs)
> 2017-12-07 10:58:25.831 19 ERROR neutron_lbaas.services.loadbalancer.plugin
> File
> "/usr/lib/python2.7/dist-packages/neutron_lbaas/drivers/octavia/driver.py",
> line 243, in create
> 2017-12-07 10:58:25.831 19 ERROR neutron_lbaas.services.loadbalancer.plugin
> self.driver.req.post(self._url(lb), args)
> 2017-12-07 10:58:25.831 19 ERROR neutron_lbaas.services.loadbalancer.plugin
> File
> "/usr/lib/python2.7/dist-packages/neutron_lbaas/drivers/octavia/driver.py",
> line 151, in post
> 2017-12-07 10:58:25.831 19 ERROR neutron_lbaas.services.loadbalancer.plugin
> return self.request('POST', url, args)
> 2017-12-07 10:58:25.831 19 ERROR neutron_lbaas.services.loadbalancer.plugin
> File
> "/usr/lib/python2.7/dist-packages/neutron_lbaas/drivers/octavia/driver.py",
> line 136, in request
> 2017-12-07 10:58:25.831 19 ERROR neutron_lbaas.services.loadbalancer.plugin
> headers['X-Auth-Token'] = self.auth_session.get_token()
> 2017-12-07 10:58:25.831 19 ERROR 

Re: [openstack-dev] [octavia][tricircle] About enabling automatic installation of octavia with tricircle

[Michael Johnson]

I think the steps listed in that document seem reasonable.  There are
a few typos here and there, but in general it looks ok.

Michael

On Mon, Dec 4, 2017 at 10:14 PM, Yipei Niu  wrote:
> Hi, all
>
> Tricircle team has already enabled LBaaS with tricircle. Here is the guide
> https://github.com/openstack/tricircle/blob/master/doc/source/install/installation-lbaas.rst.
>
> However, automatic installation and configuration of Octavia in tricircle is
> not implemented yet, since some modifications are needed to adapt Octavia.
> The detailed info is presented the section of "Setup & Installation" in
> https://github.com/openstack/tricircle/blob/master/doc/source/install/installation-lbaas.rst#setup--installation
>
> What do you think? Look forward to your comments on automatic installation
> of Octavia with tricircle.
>
> Best regards,
> Yipei
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [octavia] openstack CLI output don't match neutron lbaas-* output

[Michael Johnson]

 Hi Volodymyr,

This is a known issue with the neutron (neutron-lbaas) database
getting out of sync and/or not properly handling driver errors.
This is one reason we are moving to deprecate neutron-lbaas. If you
can, we recommend you move to exclusively using Octavia without
neutron-lbaas.

The fundamental issue is that neutron-lbaas does not use database
transactions properly and does not lock records and the API correctly
so multiple requests/threads can modify neutron database records for
the load balancers. This is particularly an issue if you are doing a
high rate of changes against the neutron-lbaas API. To correct all of
these would require rewriting a significant amount of the
neutron-lbaas API code which doesn't make much sense given we are
moving towards deprecating it in favor of the Octavia API that does
not have this issue.

To mitigate this to some degree you can enable the multiple
synchronization features that push data back to the neutron database
correcting the inaccuracies in the neutron database.
event_streamer_driver and sync_provisioning_status can be enabled in
the octavia.conf [health_manager] section.
https://docs.openstack.org/octavia/latest/configuration/configref.html#health_manager.event_streamer_driver

This tells octavia to be aggressive at pushing status information back
up to the neutron database getting it back in sync with reality.

Michael

On Wed, Nov 29, 2017 at 4:41 AM, Volodymyr Litovka  wrote:
> Hi colleagues,
>
> just to inform you: openstack CLI extension output don't match corresponsing
> 'neutron lbaas-*' CLI output, e.g.
>
> doka@lagavulin(admin@bush):~/heat$ neutron lbaas-loadbalancer-show
> db8ae876-b6eb-4c45-95d1-33e0ca6193de
> neutron CLI is deprecated and will be removed in the future. Use openstack
> CLI instead.
> +-++
> | Field   | Value  |
> +-++
> | admin_state_up  | True   |
> | description ||
> | id  | db8ae876-b6eb-4c45-95d1-33e0ca6193de   |
> | listeners   | {"id": "3ce73276-9c80-4645-aa0c-263fae736ef5"} |
> | name| nbt-balancer   |
> | operating_status| ONLINE |
> | pools   | {"id": "e106e039-af27-4cfa-baa2-7238acd3078e"} |
> | provider| octavia|
> | provisioning_status | ACTIVE |
> | tenant_id   | c1114776e144400da17d8e060856be8c   |
> | vip_address | 10.1.1.13  |
> | vip_port_id | 6898f149-9d6c-4fa7-b16c-af582cd18efa   |
> | vip_subnet_id   | ecb891c1-b7e5-45e0-8815-8675381d70d2   |
> +-++
> doka@lagavulin(admin@bush):~/heat$ openstack loadbalancer show
> db8ae876-b6eb-4c45-95d1-33e0ca6193de
> +-+--+
> | Field   | Value|
> +-+--+
> | admin_state_up  | True |
> | created_at  | 2017-11-29T12:02:55  |
> | description |  |
> | flavor  |  |
> | id  | db8ae876-b6eb-4c45-95d1-33e0ca6193de |
> | listeners   | 3ce73276-9c80-4645-aa0c-263fae736ef5 |
> | name| nbt-balancer |
> | operating_status| OFFLINE  |
> | pools   | e106e039-af27-4cfa-baa2-7238acd3078e |
> | project_id  | c1114776e144400da17d8e060856be8c |
> | provider| octavia  |
> | provisioning_status | ACTIVE   |
> | updated_at  | 2017-11-29T12:04:40  |
> | vip_Address | 10.1.1.13|
> | vip_network_id  | 141f1af9-c309-4263-b7f9-dab3922957c3 |
> | vip_port_id | 6898f149-9d6c-4fa7-b16c-af582cd18efa |
> | vip_subnet_id   | ecb891c1-b7e5-45e0-8815-8675381d70d2 |
> +-+--+
>
> more difference between corresponding command pairs for listeners and pools.
>
> Also, member list shows NO_MONITOR status for members
>
> doka@lagavulin(admin@bush):~/heat$ openstack loadbalancer member list
> nbt-pool
> +--+--+--+-+---+---+--++
> | id   | name | 

Re: [openstack-dev] [octavia] connection to external network

[Michael Johnson]

Hello Volodymyr,

You have two options:
1. When you create your VIP, simply put in your external network as
the vip-subnet-id or vip-network-id. This will allocate a public IP to
the VIP.
2. Use neutron to assign a floating IP to the VIP address of the load
balancer.  From your example, let's say the VIP address of lb1 is
10.0.0.10 on the nbt-subnet with port ID
7e11e63e-7dcb-4b2c-835e-f5cd7ca79acf.  You would use "openstack
floating ip create --port 7e11e63e-7dcb-4b2c-835e-f5cd7ca79acf
external".  This will assign a floating IP to the VIP address.

Option 1 will have better performance as there is no NAT occurring
like there is with a floating IP.

Michael


On Mon, Nov 27, 2017 at 1:30 AM, Volodymyr Litovka  wrote:
> Hello colleagues,
>
> I think I'm missing something architectural in LBaaS / Octavia, thus asking
> there - how to connect Amphora agent to external network? My current lab
> topology is the following:
>
> +
> |
> |++
> +   ++ n1 |
> |+-+|++
> ++ Amphora ++
> |+-+|++
>   m | n ++ n2 |
>   g | b |+++ e
>   m | t |  | x
>   t |   |++| t
> | s ++ vR ++ e
> | u |++| r
>++ b |  | n
>| Controller | n |++| a
>++ e |+ n3 |+ l
>   t |++
> +
>
> where "Amphora" is agent which loadbalances requests between "n1" and "n2":
>
> openstack loadbalancer create --name lb1 --vip-subnet-id nbt-subnet
> --project bush
> openstack loadbalancer listener create --protocol TCP --protocol-port 80
> --name lis1 lb1
> openstack loadbalancer pool create --protocol TCP --listener lis1 --name
> lpool1 --lb-algorithm ROUND_ROBIN
> openstack loadbalancer member create --protocol-port 80 --name n1 --address
> 1.1.1.11 lpool1
> openstack loadbalancer member create --protocol-port 80 --name n2 --address
> 1.1.1.14 lpool1
>
> Everything works (n3-sourced connections to Amphora-agent return answers
> from n1 and n2 respectively in round robin way) and the question is how to
> connect Amphora-agent to external network in order to service requests from
> outside?
>
> In example above, nbt-subnet (which is VIP network) has a virtual router
> which is connected to external network and has all abilities to provide e.g.
> floating ip to Amphora, but I see nothing in octavia config files regarding
> floating ip functions.
>
> Am I missing something? Any ways on connect Web-servers in closed
> (project's) networks with Internet using Octavia / LBaaS?
>
> Thank you!
>
> --
> Volodymyr Litovka
>   "Vision without Execution is Hallucination." -- Thomas Edison
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [release][ptl] Improving the process for release marketing

[Michael Johnson]

Is there a template for this?  I wouldn't want to have 12 different
formatting styles for the page (Yes, I'm looking at Amrith and the
blinking red text. grin)

Michael


On Tue, Nov 21, 2017 at 6:28 AM, Amrith Kumar  wrote:
> Very cool, thanks Sean!
>
>
> -amrith
>
>
> On Mon, Nov 20, 2017 at 12:18 PM, Sean McGinnis 
> wrote:
>>
>> Hello PTL's, release liaisons, and all those interested.
>>
>> The changes on our side to support a release cycle highlights page have
>> been
>> completed, and things have settled a bit from the Summit activies, so I
>> think
>> now is a good time to get things going again for this.
>>
>> See below for the background, but if you missed it or have forgotten by
>> now, we
>> plan to have an easier way to collect significant "highlights" for each
>> release
>> cycle in order to collect "key features" flagged by each team that
>> marketing
>> teams can use during release communication times. The goal is to reduce
>> the
>> number of times PTL's get asked by various groups to "tell us what changed
>> in
>> this release."
>>
>> The way we are approaching this is by adding a "cycle-highlights" key to
>> the
>> deliverable file for your project [1]. This field will take RST formatted
>> text
>> that will then be rendered into the highlights page we will share with
>> marketing.
>>
>> Our goal is to have roughly three "highlights" per team for each release,
>> but
>> this will vary based on the needs of the team and the amount of work done
>> during the cycle. If there is only one significant change to share, that
>> is
>> fine. If there are five, that's OK too. Just keep in mind that these
>> should be
>> limited to only the significant changes that you feel are worth
>> communicating
>> to the marketing, sales, and end users out there that need to know what to
>> expect.
>>
>> We will want to start collecting this information as we near RC releases,
>> but
>> feel free to start adding items of interest with the upcoming Queens-2
>> release
>> if you already have changes worth noting.
>>
>> And please ask here or in the #openstack-release channel if you have any
>> questions about how this works.
>>
>> Thanks,
>> Sean
>>
>> [1] http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n466
>>
>> P.S. This is for cycle_* deliverables only. If you see a need for this
>> with the
>> independent releases, let me know and we can talk about how that might
>> look.
>>
>>
>> On Tue, Sep 26, 2017 at 02:33:09PM -0700, Anne Bertucio wrote:
>> > Release marketing is a critical part of sharing what’s new in each
>> > release, and we want to rework how the marketing community and projects 
>> > work
>> > together to make the release communications happen.
>> >
>> > Having multiple, repetetive demands to summarize "top features" during
>> > release time can be pestering and having to recollect the information each
>> > time isn't an effective use of time. Being asked to make polished,
>> > "press-friendly" messages out of release notes can feel too far outside of
>> > the PTL's focus areas or skills. At the same time, for technical content
>> > marketers, attempting to find the key features from release notes, ML 
>> > posts,
>> > specs, Roadmap, etc., means interesting features are sometimes overlooked.
>> > Marketing teams don't have the latest on what features landed and with what
>> > caveats.
>> >
>> > To address this gap, the Release team and Foundation marketing team
>> > propose collecting information as part of the release tagging process.
>> > Similar to the existing (unused) "highlights" field for an individual tag,
>> > we will collect some text in the deliverable file to provide highlights for
>> > the series (about 3 items). That text will then be used to build a landing
>> > page on release.openstack.org that shows the "key features" flagged by PTLs
>> > that marketing teams should be looking at during release communication
>> > times. The page will link to the release notes, so marketers can start 
>> > there
>> > to gather additional information, eliminating repetitive asks of PTLs. The
>> > "pre selection" of features means marketers can spend more time diving into
>> > release note details and less sifting through them.
>> >
>> > To supplement the written information, the marketing community is also
>> > going to work together to consolidate follow up questions and deliver them
>> > in "press corps" style (i.e. a single phone call to be asked questions from
>> > multiple parties vs. multiple phone calls from individuals).
>> >
>> > We will provide more details about the implementation for the highlights
>> > page when that is ready, but want to gather feedback about both aspects of
>> > the plan early.
>> >
>> > Thanks for your input,
>> > Anne Bertucio and Sean McGinnis
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > __
>> > OpenStack Development Mailing List 

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

[Michael Johnson]

Yipei,

Yeah, we have clearly identified the problem.  Those two default route
lines should not be different.  See my devstack:
sudo: unable to resolve host amphora-20a717b4-eb97-4b5c-a11a-0633fe61f135
default via 10.0.0.1 dev eth1  table 1 onlink
default via 10.0.0.1 dev eth1 onlink

So the issue here is the gateway neutron gave us for the subnet is
different than the one the amphora is receiving via DHCP.

The "default via 10.0.1.1 dev eth1  table 1 onlink " would not be
present if neutron didn't give us a gateway address and there are not
host routes on the subnet.

Did the gateway for the subnet changed after the amphora was booted?
Was the amphora live-migrated? Was there a host route on that subnet?

Michael

On Tue, Nov 14, 2017 at 12:29 AM, Yipei Niu  wrote:
> Hi, Michael,
>
> Please ignore my last two mails. Sorry about that.
>
> The results of the two commands are as follows.
>
> ubuntu@amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f:~$ sudo ip netns exec
> amphora-haproxy ip route show table all
> sudo: unable to resolve host amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f
> default via 10.0.1.1 dev eth1  table 1 onlink
> default via 10.0.1.10 dev eth1
> 10.0.1.0/24 dev eth1  proto kernel  scope link  src 10.0.1.8
> broadcast 10.0.1.0 dev eth1  table local  proto kernel  scope link  src
> 10.0.1.8
> local 10.0.1.4 dev eth1  table local  proto kernel  scope host  src 10.0.1.8
> local 10.0.1.8 dev eth1  table local  proto kernel  scope host  src 10.0.1.8
> broadcast 10.0.1.255 dev eth1  table local  proto kernel  scope link  src
> 10.0.1.8
> fe80::/64 dev eth1  proto kernel  metric 256  pref medium
> unreachable default dev lo  table unspec  proto kernel  metric 4294967295
> error -101 pref medium
> local fe80::f816:3eff:febe:5ad5 dev lo  table local  proto none  metric 0
> pref medium
> ff00::/8 dev eth1  table local  metric 256  pref medium
> unreachable default dev lo  table unspec  proto kernel  metric 4294967295
> error -101 pref medium
>
> ubuntu@amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f:~$ sudo ip netns exec
> amphora-haproxy ip rule show
> sudo: unable to resolve host amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f
> 0: from all lookup local
> 100: from 10.0.1.4 lookup 1
> 32766: from all lookup main
> 32767: from all lookup default
>
> I think I know the source. When haproxy receives packets sent by curl, it
> responds with taking VIP as source ip for 3-way handshake. Before adding
> “100: from 10.0.1.9 lookup 1”, the datagrams are routed based on main table.
> After adding "100: from 10.0.1.9 lookup 1", the haproxy tries to find the
> gateway based on "default via 10.0.1.1 dev eth1  table 1 onlink". However,
> if there is no router, the gateway ip is missing, making haproxy fails to
> build tcp connection.
>
> Best regards,
> Yipei
>
>
> On Tue, Nov 14, 2017 at 11:04 AM, Yipei Niu  wrote:
>>
>> Hi, Michael,
>>
>> Sorry about the typo in the last mail. Please just ignore the last mail.
>>
>> In the environment where octavia and tricircle are installed together, I
>> created a router and attached subnet1 to it. Then I bind the mac address of
>> 10.0.1.10 (real gateway) to ip of 10.0.1.1 in the amphora arp cache,
>> manually making amphora knows the mac address of 10.0.1.1 (actually it is
>> the mac of 10.0.1.10, since 10.0.1.1 does not exist), it works.
>>
>> I also run the commands in this environment.
>>
>> ubuntu@amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f:~$ sudo ip netns exec
>> amphora-haproxy ip route show table all
>> sudo: unable to resolve host amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f
>> default via 10.0.1.1 dev eth1  table 1 onlink
>> default via 10.0.1.10 dev eth1
>> 10.0.1.0/24 dev eth1  proto kernel  scope link  src 10.0.1.8
>> broadcast 10.0.1.0 dev eth1  table local  proto kernel  scope link  src
>> 10.0.1.8
>> local 10.0.1.4 dev eth1  table local  proto kernel  scope host  src
>> 10.0.1.8
>> local 10.0.1.8 dev eth1  table local  proto kernel  scope host  src
>> 10.0.1.8
>> broadcast 10.0.1.255 dev eth1  table local  proto kernel  scope link  src
>> 10.0.1.8
>> fe80::/64 dev eth1  proto kernel  metric 256  pref medium
>> unreachable default dev lo  table unspec  proto kernel  metric 4294967295
>> error -101 pref medium
>> local fe80::f816:3eff:febe:5ad5 dev lo  table local  proto none  metric 0
>> pref medium
>> ff00::/8 dev eth1  table local  metric 256  pref medium
>> unreachable default dev lo  table unspec  proto kernel  metric 4294967295
>> error -101 pref medium
>> ubuntu@amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f:~$ sudo ip netns exec
>> amphora-haproxy ip rule show
>> sudo: unable to resolve host amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f
>> 0: from all lookup local
>> 100: from 10.0.1.4 lookup 1
>> 32766: from all lookup main
>> 32767: from all lookup default
>>
>>
>> To make the situation clear, I run the commands in the environment
>> installed octavia alone. Please note that in this environment, there is no
>> router. 

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

[Michael Johnson]

Yipei,

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

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

and

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

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

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

and

sudo ip netns exec amphora-haproxy ip rule show

from the failing amphora?

Michael

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

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

[Michael Johnson]

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

Michael


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

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

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

[Michael Johnson]

The actual gateway address does not matter to Octavia/amphora.  It
gets that value from DHCP or from neutron if a static address was
assigned from neutron.
My concern is that the subnet gateway 10.0.1.10 does not match the
gateway address DHCP gave us 10.0.1.1.
Technically, since the two addresses are on the same IP subnet the
router should not matter, it was just an observation that I noticed as
something is not right with neutron.
From inside the amphora-haproxy namespace, can you curl and/or ping to 10.0.1.3?
From inside the qdhcp-310fea4b-36ae-4617-b499-5936e8eda842 namespace
on the host, can you curl/ping your member 10.0.1.3?

I am thinking that the host qdhcp-310fea4b-36ae-4617-b499-5936e8eda842
namespace does not have connectivity to to the nova instances somehow.

Michael


On Fri, Nov 10, 2017 at 1:24 AM, Yipei Niu  wrote:
> Hi, Michael,
>
> Thanks a lot for your reply.
>
> I can make sure that there is no router or multiple dhcp services in my
> environment.
>
> As shown in my first mail, the haproxy in the amphora tries to find the
> gateway ip 10.0.1.1 that does not exist in the environment.
>
> ubuntu@amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f:~$ sudo ip netns exec
> amphora-haproxy tcpdump -i eth1 -nn
> sudo: unable to resolve host amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
> ^C07:25:24.225614 IP 10.0.1.2.55294 > 10.0.1.4.80: Flags [S], seq
> 1637781601, win 28200, options [mss 1410,sackOK,TS val 30692602 ecr
> 0,nop,wscale 7], length 0
> 07:25:24.237854 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
> 07:25:25.224801 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
> 07:25:25.228610 IP 10.0.1.2.55294 > 10.0.1.4.80: Flags [S], seq 1637781601,
> win 28200, options [mss 1410,sackOK,TS val 30692853 ecr 0,nop,wscale 7],
> length 0
> 07:25:26.224533 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
> 07:25:27.230911 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
> 07:25:27.250858 IP 10.0.1.2.55294 > 10.0.1.4.80: Flags [S], seq 1637781601,
> win 28200, options [mss 1410,sackOK,TS val 30693359 ecr 0,nop,wscale 7],
> length 0
> 07:25:28.228796 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
> 07:25:29.228697 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
> 07:25:29.290551 ARP, Request who-has 10.0.1.4 tell 10.0.1.2, length 28
> 07:25:29.290985 ARP, Reply 10.0.1.4 is-at fa:16:3e:be:5a:d5, length 28
> 07:25:31.251122 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
> 07:25:32.248737 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
> 07:25:33.250309 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
>
> So if the subnet is not attached to any router, why does haproxy try to find
> the gateway ip that does not exist at all? Maybe that is the reason why
> haproxy receives the packet from curl but fail to respond.
>
> I think the gateway ip (10.0.1.10) confuses you. Actually, in my environment
> octavia and tricircle (https://wiki.openstack.org/wiki/Tricircle) are
> installed together. Because of the cross-neutron mechanism of tricircle, the
> gateway ip of subnet in that region is 10.0.1.10. But I can make sure that
> gateway ip (10.0.1.1 or 10.0.1.10) does not exist in the network, since
> there is no router at all. This error also happens in my another environment
> where octavia is installed alone. The environment is installed on Oct. 6,
> and all the repos are the latest at that time.
>
> Best regards,
> Yipei
>
>
> On Thu, Nov 9, 2017 at 2:50 PM, Yipei Niu  wrote:
>>
>> Hi, Michael,
>>
>> Based on your mail, the information is as follows.
>>
>> 1. The version of Octavia I used is Queens, and the latest commit message
>> is
>> commit 2ab2836d0ebdd0fd5bc32d3adcc44a92557c8c1d
>> Author: OpenStack Proposal Bot 
>> Date:   Fri Nov 3 17:58:59 2017 +
>>
>> Updated from global requirements
>>
>> Change-Id: I9047e289b8a3c931156da480b3f9f676c54a8358
>>
>> 2. The info of the amphora and other VMs is as follows.
>>
>> +--+--+++-+-+
>> | ID   | Name
>> | Status | Task State | Power State | Networks
>> |
>>
>> +--+--+++-+-+
>> | 33bd02cb-f853-404d-a705-99bc1b04a178 |
>> amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f | ACTIVE | -  | Running
>> | lb-mgmt-net1=192.168.1.4; net1=10.0.1.8 |
>> | dd046fc9-e2bf-437d-8c51-c397bccc3dc1 | client1
>> | ACTIVE | -  | Running | net1=10.0.1.3
>> |
>> | 

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

[Michael Johnson]

Hi Yipei,

I see a few things that are odd:
stack@devstack-1:/opt/stack/octavia$ sudo ip netns exec
qdhcp-310fea4b-36ae-4617-b499-5936e8eda842 curl 10.0.1.4
curl: (7) Failed to connect to 10.0.1.4 port 80: Connection timed out

This means that the connection is not working between curl and the
HAProxy process.  If HAProxy was just unable to reach the member you
would get a 503 error.

The other thing that does not make sense is the routing table on the
amphora-haproxy namespace.
It has a route of:
default 10.0.1.10.0.0.0 UG0  00 eth1

But your subnet has a gateway:
|gateway_ip| 10.0.1.10   |

Are there multiple routers on the VIP network? Or multiple DHCP
services? Since neutron is configured for DHCP on that subnet the
amphora will get it's default gateway from the DHCP packet it uses to
configure the base interface eth1.

Michael

On Wed, Nov 8, 2017 at 10:50 PM, Yipei Niu  wrote:
> Hi, Michael,
>
> Based on your mail, the information is as follows.
>
> 1. The version of Octavia I used is Queens, and the latest commit message is
> commit 2ab2836d0ebdd0fd5bc32d3adcc44a92557c8c1d
> Author: OpenStack Proposal Bot 
> Date:   Fri Nov 3 17:58:59 2017 +
>
> Updated from global requirements
>
> Change-Id: I9047e289b8a3c931156da480b3f9f676c54a8358
>
> 2. The info of the amphora and other VMs is as follows.
> +--+--+++-+-+
> | ID   | Name
> | Status | Task State | Power State | Networks
> |
> +--+--+++-+-+
> | 33bd02cb-f853-404d-a705-99bc1b04a178 |
> amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f | ACTIVE | -  | Running
> | lb-mgmt-net1=192.168.1.4; net1=10.0.1.8 |
> | dd046fc9-e2bf-437d-8c51-c397bccc3dc1 | client1
> | ACTIVE | -  | Running | net1=10.0.1.3
> |
> | 50446c75-7cb7-43eb-b057-4b6b89a926bc | client3
> | ACTIVE | -  | Running | net4=10.0.4.3
> |
> +--+--+++-+-+
>
> 3. The info of the load balancer is as follows.
> +-++
> | Field   | Value  |
> +-++
> | admin_state_up  | True   |
> | description ||
> | id  | 51cba1d5-cc3c-48ff-b41e-839619093334   |
> | listeners   | {"id": "b20ad920-c6cd-4e71-a9b9-c134e57ecd20"} |
> | name| lb1|
> | operating_status| ONLINE |
> | pools   | {"id": "d0042605-da50-4048-b298-660420b0a1d2"} |
> | provider| octavia|
> | provisioning_status | ACTIVE |
> | tenant_id   | c2a97a04cb6d4f25bdcb8b3f263c869e   |
> | vip_address | 10.0.1.4   |
> | vip_port_id | 2209a819-0ac8-4211-b878-f0b41ac4727b   |
> | vip_subnet_id   | cbcf4f04-da6d-4800-8b40-4b141972c2bf   |
> +-++
>
> 4. The info of the listener is as follows.
> +---++
> | Field | Value
> |
> +---++
> | admin_state_up| True
> |
> | connection_limit  | -1
> |
> | default_pool_id   | d0042605-da50-4048-b298-660420b0a1d2
> |
> | default_tls_container_ref |
> |
> | description   |
> |
> | id| b20ad920-c6cd-4e71-a9b9-c134e57ecd20
> |
> | loadbalancers | {"id": "51cba1d5-cc3c-48ff-b41e-839619093334"}
> |
> | name  | listener1
> |
> | protocol  | HTTP
> |
> | protocol_port | 80
> |
> | sni_container_refs|
> |
> | tenant_id | c2a97a04cb6d4f25bdcb8b3f263c869e
> |
> +---++
>
> 5. The members of the load balancer lb1 are as follows.
> 

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

[Michael Johnson]

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

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

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

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

Michael

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

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

[Michael Johnson]

Hi Yipei,

I need some more information to help you out.  Can you provide the following?

1. What version of Octavia you are using.
2. "openstack server list" output for the amphora.
3. "openstack loadbalancer show" for the load balancer.
4. "openstack loadbalancer listener show" for the listener.
5. "openstack loadbalancer member list" for the load balancer.
6. "openstack subnet list" showing all of the subnets used by the
lb-mgmt-net, VIP, and the members.
7. "openstack subnet show" for each of the lb-mgmt-net, VIP, and member subnets
8. "ifconfig" from inside the amphora and from inside the netns on the amphora
9. curl command you are using to connect to the VIP
10. "netstat -rn" from the host you are running curl from
11. Inside the amphora, cd /opt/amphora-agent, "git log" cut/paste the
top two commit messages.

That should help us see what your configuration is and narrow down
what is going on.
As always, you can also try to have an interactive session with us in
#openstack-lbaas on IRC. However, with the summit the hours folks are
available to answer questions may be a bit limited this week.

Michael


On Tue, Nov 7, 2017 at 11:32 PM, Yipei Niu  wrote:
> Hi, all,
>
> I created a lb whose vip is 10.0.1.4. When requesting the vip, i cannot
> receive the responses. Hence, I console in the amphora and trace packets
> handled by eth0 in the amphora-haproxy network namespace. The detailed info
> is as follows.
>
> ubuntu@amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f:~$ sudo ip netns exec
> amphora-haproxy tcpdump -i eth1 -nn
> sudo: unable to resolve host amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
> ^C07:25:24.225614 IP 10.0.1.2.55294 > 10.0.1.4.80: Flags [S], seq
> 1637781601, win 28200, options [mss 1410,sackOK,TS val 30692602 ecr
> 0,nop,wscale 7], length 0
> 07:25:24.237854 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
> 07:25:25.224801 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
> 07:25:25.228610 IP 10.0.1.2.55294 > 10.0.1.4.80: Flags [S], seq 1637781601,
> win 28200, options [mss 1410,sackOK,TS val 30692853 ecr 0,nop,wscale 7],
> length 0
> 07:25:26.224533 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
> 07:25:27.230911 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
> 07:25:27.250858 IP 10.0.1.2.55294 > 10.0.1.4.80: Flags [S], seq 1637781601,
> win 28200, options [mss 1410,sackOK,TS val 30693359 ecr 0,nop,wscale 7],
> length 0
> 07:25:28.228796 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
> 07:25:29.228697 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
> 07:25:29.290551 ARP, Request who-has 10.0.1.4 tell 10.0.1.2, length 28
> 07:25:29.290985 ARP, Reply 10.0.1.4 is-at fa:16:3e:be:5a:d5, length 28
> 07:25:31.251122 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
> 07:25:32.248737 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
> 07:25:33.250309 ARP, Request who-has 10.0.1.1 tell 10.0.1.4, length 28
>
> 14 packets captured
> 14 packets received by filter
> 0 packets dropped by kernel
>
> As shown above, the amphora can receive the requests comes from outside but
> it fails to find 10.0.1.1. As a result, amphora cannot send the request to
> its load balancing member.
>
> To further demonstrate my environment, the route table and arp cache are
> listed as follows.
>
> ubuntu@amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f:~$ sudo ip netns exec
> amphora-haproxy route
> sudo: unable to resolve host amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric RefUse
> Iface
> default 10.0.1.10.0.0.0 UG0  00 eth1
> 10.0.1.0*   255.255.255.0   U 0  00 eth1
>
> ubuntu@amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f:~$ sudo ip netns exec
> amphora-haproxy arp
> sudo: unable to resolve host amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f
> Address  HWtype  HWaddress   Flags Mask
> Iface
> 10.0.1.2 ether   fa:16:3e:62:68:a8   C
> eth1
> 10.0.1.1 (incomplete)
> eth1
>
> What do you think? Look forward to your comments. Thank you.
>
> Best regards,
> Yipei
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

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

[Michael Johnson]

I think we helped you get going again in the IRC channel.  Please ping
us again in the IRC channel if you need more assistance.

Michael

On Thu, Nov 2, 2017 at 4:42 AM, Kim-Norman Sahm
 wrote:
> Hi,
>
> after a rabbitmq problem octavia has removed all amphora instances.
> the loadbalancers are in provisioning_status "ACTIVE"
>
> ~$ neutron lbaas-loadbalancer-list
> neutron CLI is deprecated and will be removed in the future. Use
> openstack CLI instead.
> | 07b41df6-bb75-4502-975a-20140b0832dd | Load Balancer
> 4   | 260b0c452e214accaf6cc0e98fb10fc0 |
> 192.168.1.18   | ACTIVE  | octavia  |
> | 25664be7-15cb-426b-ad09-6102afb62b14 | Load Balancer
> 2   | 260b0c452e214accaf6cc0e98fb10fc0 |
> 192.168.1.7| ACTIVE  | octavia  |
> | 927eb754-7c52-4060-b130-1f5e82d92555 | Load Balancer
> 6   | 260b0c452e214accaf6cc0e98fb10fc0 |
> 192.168.1.17   | ACTIVE  | octavia  |
> | b4d93c68-89d6-4e4f-b06c-117d4ea933fa | Load Balancer
> 5   | 260b0c452e214accaf6cc0e98fb10fc0 |
> 192.168.1.24   | ACTIVE  | octavia  |
> | d7699f8d-2106-42d6-8797-5feb72de6e2e | Load Balancer
> 1   | 260b0c452e214accaf6cc0e98fb10fc0 |
> 192.168.1.5| ACTIVE  | octavia  |
> | dd6114ae-21e9-41bd-b155-325287aed420 | Load Balancer
> 3   | 260b0c452e214accaf6cc0e98fb10fc0 |
> 192.168.1.23   | ACTIVE  | octavia  |
>
> How can we trigger octavia to rebuild the amphore instances?
> I've tried to restart the octavia services but it didn't solved the
> problem.
>
> Best regards
> Kim
>
>
> Kim-Norman Sahm
> Cloud & Infrastructure(OCI)
> noris network AG
> Thomas-Mann-Straße 16-20
> 90471 Nürnberg
> Deutschland
> Tel +49 911 9352 1433
> Fax +49 911 9352 100
>
> kim-norman.s...@noris.de
> https://www.noris.de - Mehr Leistung als Standard
> Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel
> Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [octavia] how to list/find the amphoras serving a load balancer

[Michael Johnson]

Hi Mihaela,

Welcome to the Octavia club!

In an Ocata release you are correct that there is no API way to
identify amphora related to a given load balancer.

In the queens release we have introduced a new administrator API for
amphora that provides the functionality you are looking for:
https://developer.openstack.org/api-ref/load-balancer/v2/index.html#list-amphora

By using the filter capabilities of our Octavia v2 API you can query
the API for a list of amphora that are associated to a load balancer
ID.

Michael


On Fri, Oct 13, 2017 at 1:51 AM,   wrote:
> Hi,
>
>
>
> We are about to deploy Octavia (Ocata) in a multi-tenant Openstack
> environment. All amphoras (for all tenants) will be spawned in a “service”
> tenant. What is the easiest way to list the amphora instances of a certain
> load balancer? As far as I could see, there is no API call returning such
> result. The best way I can do it is by checking the security group
> associated to the amphora port: the security group name includes the load
> balancer ID.
>
>
>
> Thank you,
>
> Mihaela
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [octavia] Proposing Nir Magnezi as Octavia core reviewer

[Michael Johnson]

Ok, that is quorum.

Congratulations Nir!

Michael


On Mon, Oct 9, 2017 at 3:18 PM, Adam Harwell <flux.a...@gmail.com> wrote:
> +1
>
>
> On Thu, Oct 5, 2017, 05:48 Daniel Mellado <daniel.mellado...@ieee.org>
> wrote:
>>
>> +1
>>
>> Go, Nir, Go!
>>
>> congrats!
>>
>> On 10/05/2017 03:51 AM, German Eichberger wrote:
>> > +1
>> >
>> > Welcome Nir, well earned.
>> >
>> > German
>> >
>> > On 10/4/17, 4:28 PM, "Michael Johnson" <johnso...@gmail.com> wrote:
>> >
>> > Hello OpenStack folks,
>> >
>> > I would like to propose Nir Magnezi as a core reviewer on the
>> > Octavia project.
>> >
>> > He has been an active contributor to the Octavia projects for a few
>> > releases and has been providing solid patch review comments. His
>> > review stats are also in line with other core reviewers.
>> >
>> > Octavia cores, please reply to this e-mail with your
>> > agreement/disagreement to this proposal.
>> >
>> > 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 Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

[openstack-dev] [octavia] New meeting time and channel

[Michael Johnson]

Hello OpenStack load balancing folks,

Summary: Octavia/neutron-lbaas weekly IRC meeting will be 20:00 UTC on
Wednesdays in the #openstack-lbaas channel.

As discussed at the last two weekly meetings[1], we are moving our
meeting time back to the previous time slot.  Unfortunately the
earlier time slot did not work for some team members and attendance
dropped.

Based on the results from the doodle poll [2], our old meeting time
works better for folks when taking into account that some folks are
transitioning to other work. With the recent TC resolution allowing
meetings in the team channels[3] we will be having the weekly IRC
meeting in the #openstack-lbaas channel.

The core team is also available in the #openstack-lbaas channel
covering a wide time window, so please feel free to utilize the
#openstack-lbaas channel if you are unable to attend the weekly
meeting.

Michael (johnsom)

[1] 
https://wiki.openstack.org/wiki/Octavia/Meeting_Minutes#2017-10-04_Weekly_meeting:
[2] https://beta.doodle.com/poll/p65x9xxkec52ecaw
[3] 
https://governance.openstack.org/tc/resolutions/20170718-allow-scheduling-meetings-on-team-channels.html

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

[openstack-dev] [octavia] Proposing Nir Magnezi as Octavia core reviewer

[Michael Johnson]

Hello OpenStack folks,

I would like to propose Nir Magnezi as a core reviewer on the Octavia project.

He has been an active contributor to the Octavia projects for a few
releases and has been providing solid patch review comments. His
review stats are also in line with other core reviewers.

Octavia cores, please reply to this e-mail with your
agreement/disagreement to this proposal.

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

Re: [openstack-dev] Odp.: Odp.: [neutron][lbaasv2][agent implementation] L7 policy support

[Michael Johnson]

Hi Mihaela,

The old neutron-lbaas haproxy namespace driver does not have L7
support. Only the Octavia driver and some vendor provider drivers have
L7 support.

Michael


On Tue, Oct 3, 2017 at 11:35 PM, Pawel Suder  wrote:
> Hello,
>
>
> It seems that HaproxyOnHostPluginDriver from
> https://github.com/openstack/neutron-lbaas/blob/mitaka-eol/neutron_lbaas/drivers/haproxy/plugin_driver.py#L21
> extends AgentDriverBase
> https://github.com/openstack/neutron-lbaas/blob/mitaka-eol/neutron_lbaas/drivers/common/agent_driver_base.py#L301
> where I could not located L7 things.
>
> L7 things might be related to Octavia (only?). What I found is that HAProxy
> (https://www.haproxy.com/doc/aloha/7.0/haproxy/index.html) has L7 things.
>
>
> It seems that in old good times that thing was not taken into the
> consideration.
>
>
> Cheers,
>
> Paweł
>
> 
> Od: mihaela.ba...@orange.com 
> Wysłane: 3 października 2017 14:45:11
> Do: OpenStack Development Mailing List (not for usage questions)
> Temat: Re: [openstack-dev] Odp.: [neutron][lbaasv2][agent implementation] L7
> policy support
>
>
> Hi,
>
>
>
> I appreciate the help. In neutron-server I have the following service
> providers enabled:
>
>
>
> service_provider =
> LOADBALANCERV2:Haproxy:neutron_lbaas.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default
>
> service_provider =
> LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver
>
>
>
> With Octavia provider L7 policy works fine. With haproxy (agent provider) I
> receive the error below.
>
>
>
> On the haproxy agent I have the following setting (however, the
> neutron-server throws that error and not even sends any request to agent):
>
>
>
> interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
>
> device_driver =
> neutron_lbaas.drivers.haproxy.namespace_driver.HaproxyNSDriver
>
>
>
> Mihaela
>
>
>
> From: Pawel Suder [mailto:pawel.su...@corp.ovh.com]
> Sent: Tuesday, October 03, 2017 3:10 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] Odp.: [neutron][lbaasv2][agent implementation] L7
> policy support
>
>
>
> Hello Mihaela,
>
>
>
> It seems that you are referring to that part of code
> https://github.com/openstack/neutron-lbaas/blob/mitaka-eol/neutron_lbaas/drivers/driver_base.py#L36
>
>
>
> I found that document for Mitaka
> https://docs.openstack.org/mitaka/networking-guide/config-lbaas.html
>
>
>
> It might be related to incorrectly configured driver for LBaaS (or indeed
> not implemented driver for L7 policy for specific driver).
>
>
>
> Questions:
>
>
>
> * What do you have configured in neutron configuration in section
> [service_providers]?
>
> * Which driver do you want to use?
>
>
>
> Example line
>
>
>
> service_provider =
> LOADBALANCERV2:Haproxy:neutron_lbaas.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default
>
>
>
> Cheers,
>
> Paweł
>
> 
>
> Od: mihaela.ba...@orange.com 
> Wysłane: 3 października 2017 11:13:34
> Do: OpenStack Development Mailing List (not for usage questions)
> Temat: [openstack-dev] [neutron][lbaasv2][agent implementation] L7 policy
> support
>
>
>
> Hello,
>
>
>
> Does the agent implementation of LBaaSv2 support L7 policies? I am testing
> with Mitaka version and I get “Not Implemented Error”.
>
>
>
> {"asctime": "2017-10-03 07:34:42.764","process": "18","levelname":
> "INFO","name": "neutron_lbaas.services.loadbalancer.plugin", "request_id":
> "req-186bf812-1cdf-496b-a117-711f1e42c6bd", "user_identity": {"user_id":
> "44364a07de754daa9ffeb2911fe3620a", "project_id":
> "a5f15235c0714365b98a50a11ec956e7", "domain_id": "-", "user_domain_id": "-",
> "project_domain_id": "-"},"instance": {},"message":"Calling driver operation
> NotImplementedManager.create"}
>
> {"asctime": "2017-10-03 07:34:42.765","process": "18","levelname":
> "ERROR","name": "neutron_lbaas.services.loadbalancer.plugin", "request_id":
> "req-186bf812-1cdf-496b-a117-711f1e42c6bd", "user_identity": {"user_id":
> "44364a07de754daa9ffeb2911fe3620a", "project_id":
> "a5f15235c0714365b98a50a11ec956e7", "domain_id": "-", "user_domain_id": "-",
> "project_domain_id": "-"},"instance": {},"message":"There was an error in
> the driver"}
>
> 2017-10-03 07:34:42.765 18 TRACE neutron_lbaas.services.loadbalancer.plugin
>>Traceback (most recent call last):
>
> 2017-10-03 07:34:42.765 18 TRACE neutron_lbaas.services.loadbalancer.plugin
>>  File
> "/opt/neutron/lib/python2.7/site-packages/neutron_lbaas/services/loadbalancer/plugin.py",
> line 486, in _call_driver_operation
>
> 2017-10-03 07:34:42.765 18 TRACE neutron_lbaas.services.loadbalancer.plugin
>>driver_method(context, db_entity)
>
> 2017-10-03 07:34:42.765 18 TRACE neutron_lbaas.services.loadbalancer.plugin
>>  File
> "/opt/neutron/lib/python2.7/site-packages/neutron_lbaas/drivers/driver_base.py",
> line 36, 

Re: [openstack-dev] [octavia] haproxy fails to receive datagram

[Michael Johnson]

Hi Yipei,
Even running through neutron-lbaas I get the same successful test.

Just to double check, you are using the Octavia driver?

stack@devstackpy27-2:~$ sudo ip netns exec
qdhcp-4bcefe3e-038f-4a77-af4f-a560b6316a7a curl 172.21.1.16
Welcome to 172.21.1.17 connection 3

Michael

On Thu, Sep 28, 2017 at 7:46 AM, Yipei Niu  wrote:
> Hi, Michael,
>
> Thanks a lot. Look forward  to your further test. I try deploying a new
> environment, too. Hope it can work well this time.
>
> Best regards,
> Yipei
>
> On Wed, Sep 27, 2017 at 10:27 AM, Yipei Niu  wrote:
>>
>> Hi, Michael,
>>
>> The instructions are listed as follows.
>>
>> First, create a net1.
>> $ neutron net-create net1
>> $ neutron subnet-create net1 10.0.1.0/24 --name subnet1
>>
>> Second, boot two vms in net1
>> $ nova boot --flavor 1 --image $image_id --nic net-id=$net1_id vm1
>> $ nova boot --flavor 1 --image $image_id --nic net-id=$net1_id vm2
>>
>> Third, logon to the two vms, respectively. Here take vm1 as an example.
>> $ MYIP=$(ifconfig eth0|grep 'inet addr'|awk -F: '{print $2}'| awk '{print
>> $1}')
>> $ while true; do echo -e "HTTP/1.0 200 OK\r\n\r\nWelcome to $MYIP" | sudo
>> nc -l -p 80 ; done&
>>
>> Fourth, exit vms and update the default security group shared by the vms
>> by adding a rule of allowing traffic to port 80.
>> $ neutron security-group-rule-create --direction ingress --protocol tcp
>> --port-range-min 80 --port-range-max 80 --remote-ip-refix 0.0.0.0/0
>> $default_security_group
>> Note: make sure "sudo ip netns exec $qdhcp-net1_id curl -v $vm_ip" works.
>> In other words, make sure the vms can accept HTTP requests and return its
>> IP, respectively.
>>
>> Fifth, create a lb, a listener, and a pool. Then add the two vms to the
>> pool as members.
>> $ neutron lbaas-loadbalancer-create --name lb1 subnet1
>> $ neutron lbaas-listener-create --loadbalancer lb1 --protocol HTTP
>> --protocol-port 80 --name listener1
>> $ neutron lbaas-pool-create --lb-algorithm ROUND_ROBIN --listener
>> listener1 --protocol HTTP --name pool1
>> $ neutron baas-member-create --subnet subnet1 --address $vm1_ip
>> --protocol-port 80 pool1
>> $ neutron baas-member-create --subnet subnet1 --address $vm2_ip
>> --protocol-port 80 pool1
>>
>> Finally, try "sudo ip netns qdhcp-net1_id curl -v $VIP" to see whether
>> lbaas works.
>>
>> Best regards,
>> Yipei
>>
>> On Wed, Sep 27, 2017 at 1:30 AM, Yipei Niu  wrote:
>>>
>>> Hi, Michael,
>>>
>>> I think the octavia is the latest, since I pull the up-to-date repo of
>>> octavia manually to my server before installation.
>>>
>>> Anyway, I run "sudo ip netns exec amphora-haproxy ip route show table 1"
>>> in the amphora, and find that the route table exists. The info is listed as
>>> follows.
>>>
>>> default via 10.0.1.1 dev eth1 onlink
>>>
>>> I think it may not be the source.
>>>
>>> Best regards,
>>> Yipei
>>
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [octavia] haproxy fails to receive datagram

[Michael Johnson]

Hi Yipei,

I ran this scenario today using octavia and had success.  I'm not sure
what could be different.
I see you are using neutron-lbaas.  I will build a devstack with
neutron-lbaas enabled and try that, but I can't think of what would
impact this test case by going through the neutron-lbaas path.

Michael


On Tue, Sep 26, 2017 at 7:27 PM, Yipei Niu  wrote:
> Hi, Michael,
>
> The instructions are listed as follows.
>
> First, create a net1.
> $ neutron net-create net1
> $ neutron subnet-create net1 10.0.1.0/24 --name subnet1
>
> Second, boot two vms in net1
> $ nova boot --flavor 1 --image $image_id --nic net-id=$net1_id vm1
> $ nova boot --flavor 1 --image $image_id --nic net-id=$net1_id vm2
>
> Third, logon to the two vms, respectively. Here take vm1 as an example.
> $ MYIP=$(ifconfig eth0|grep 'inet addr'|awk -F: '{print $2}'| awk '{print
> $1}')
> $ while true; do echo -e "HTTP/1.0 200 OK\r\n\r\nWelcome to $MYIP" | sudo nc
> -l -p 80 ; done&
>
> Fourth, exit vms and update the default security group shared by the vms by
> adding a rule of allowing traffic to port 80.
> $ neutron security-group-rule-create --direction ingress --protocol tcp
> --port-range-min 80 --port-range-max 80 --remote-ip-refix 0.0.0.0/0
> $default_security_group
> Note: make sure "sudo ip netns exec $qdhcp-net1_id curl -v $vm_ip" works. In
> other words, make sure the vms can accept HTTP requests and return its IP,
> respectively.
>
> Fifth, create a lb, a listener, and a pool. Then add the two vms to the pool
> as members.
> $ neutron lbaas-loadbalancer-create --name lb1 subnet1
> $ neutron lbaas-listener-create --loadbalancer lb1 --protocol HTTP
> --protocol-port 80 --name listener1
> $ neutron lbaas-pool-create --lb-algorithm ROUND_ROBIN --listener listener1
> --protocol HTTP --name pool1
> $ neutron baas-member-create --subnet subnet1 --address $vm1_ip
> --protocol-port 80 pool1
> $ neutron baas-member-create --subnet subnet1 --address $vm2_ip
> --protocol-port 80 pool1
>
> Finally, try "sudo ip netns qdhcp-net1_id curl -v $VIP" to see whether lbaas
> works.
>
> Best regards,
> Yipei
>
> On Wed, Sep 27, 2017 at 1:30 AM, Yipei Niu  wrote:
>>
>> Hi, Michael,
>>
>> I think the octavia is the latest, since I pull the up-to-date repo of
>> octavia manually to my server before installation.
>>
>> Anyway, I run "sudo ip netns exec amphora-haproxy ip route show table 1"
>> in the amphora, and find that the route table exists. The info is listed as
>> follows.
>>
>> default via 10.0.1.1 dev eth1 onlink
>>
>> I think it may not be the source.
>>
>> Best regards,
>> Yipei
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [octavia] haproxy fails to receive datagram

[Michael Johnson]

Hi Yipei,

I just tried to reproduce this and was not successful.

I setup a tenant network, added a web server to it, created a
loadbalancer VIP on the tenant network, added the webserver as a
member on the load balancer.  I can curl from the tenant network
qdhcp- netns without issue.

Are you running a recent version of Octavia?  This bug might be
impacting you: https://review.openstack.org/501915

Can you check if this routing table is present inside your amphora netns?

root@amphora-f58cdb7c-8fde-4eea-bd40-780664cfa49f:~# ip netns exec
amphora-haproxy ip route show table 1

default via  dev eth1 onlink

It could be that since they are all on the same subnet there is a
return path issue in the kernel which this patch fixes with a policy
based route.

Michael

On Mon, Sep 25, 2017 at 1:33 AM, Yipei Niu  wrote:
> Hi, all,
>
> I encounter some problems when using Octavia. After installing octavia with
> devstack, I create a load balancer named lb1 (VIP: 10.0.1.9, IP of VRRP
> port: 10.0.1.3) for a subnet (10.0.1.0/24), then a listener, a pool, and two
> members. All the resources are created successfully. The two members (VMs)
> reside in the same subnet, whose IP are 10.0.1.6 and 10.0.1.7, respectively.
> To simulate a web server in each VM, I run "while true; do echo -e "HTTP/1.0
> 200 OK\r\n\r\nWelcome to $VM_IP" | sudo nc -l -p 80;done" to listen on port
> 80 and return the VM's IP if the request is accepted. I run "sudo ip netns
> exec qdhcp- curl -v $VM_IP" to send requests to VMs, the "web servers"
> in VMs work (already added corresponding security rules to the VMs). Then I
> tried to run "sudo ip netns exec qdhcp- curl -v $VIP" to send requests,
> the VMs do not respond, and finally returns a timeout error.
>
> The configuration details in local.conf are as follows.
>
> [[local|localrc]]
>
> DATABASE_PASSWORD=password
> RABBIT_PASSWORD=password
> SERVICE_PASSWORD=password
> SERVICE_TOKEN=password
> ADMIN_PASSWORD=password
>
> HOST_IP=192.168.56.9
>
> LOGFILE=/opt/stack/logs/stack.sh.log
> VERBOSE=True
> LOG_COLOR=True
> SCREEN_LOGDIR=/opt/stack/logs
>
> # Neutron LBaaS
> enable_plugin neutron-lbaas https://github.com/openstack/neutron-lbaas.git
> enable_plugin octavia https://github.com/openstack/octavia.git
> ENABLED_SERVICES+=,q-lbaasv2
> ENABLED_SERVICES+=,octavia,o-cw,o-hk,o-hm,o-api
>
> disable_service horizon
> disable_service tempest
>
> To investigate the source of the error, I logon to the amphora. The details
> of interfaces of amphora_haproxy network namespace are as follows.
>
> 1: lo:  mtu 65536 qdisc noop state DOWN group default qlen 1
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 3: eth1:  mtu 1450 qdisc pfifo_fast state
> UP group default qlen 1000
> link/ether fa:16:3e:42:bf:d9 brd ff:ff:ff:ff:ff:ff
> inet 10.0.1.3/24 brd 10.0.1.255 scope global eth1
>valid_lft forever preferred_lft forever
> inet 10.0.1.9/24 brd 10.0.1.255 scope global secondary eth1:0
>valid_lft forever preferred_lft forever
> inet6 fe80::f816:3eff:fe42:bfd9/64 scope link
>valid_lft forever preferred_lft forever
>
> So I run "sudo ip netns exec amphora-haproxy tcpdump -i eth1 -nn 'tcp'" to
> check whether amphora receive the request. The details are as follows.
>
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
> ^C06:11:49.048973 IP 10.0.1.2.33700 > 10.0.1.9.80: Flags [S], seq
> 1717936594, win 28200, options [mss 1410,sackOK,TS val 28032309 ecr
> 0,nop,wscale 7], length 0
> 06:11:50.031976 IP 10.0.1.2.33700 > 10.0.1.9.80: Flags [S], seq 1717936594,
> win 28200, options [mss 1410,sackOK,TS val 28032559 ecr 0,nop,wscale 7],
> length 0
> 06:11:52.026565 IP 10.0.1.2.33700 > 10.0.1.9.80: Flags [S], seq 1717936594,
> win 28200, options [mss 1410,sackOK,TS val 28033060 ecr 0,nop,wscale 7],
> length 0
> 06:11:56.002577 IP 10.0.1.2.33700 > 10.0.1.9.80: Flags [S], seq 1717936594,
> win 28200, options [mss 1410,sackOK,TS val 28034062 ecr 0,nop,wscale 7],
> length 0
> 06:12:03.909721 IP 10.0.1.2.33700 > 10.0.1.9.80: Flags [S], seq 1717936594,
> win 28200, options [mss 1410,sackOK,TS val 28036064 ecr 0,nop,wscale 7],
> length 0
>
> Based on the trace, we can see that amphora do receive the request, but
> haproxy does not send handshake datagram to respond. Then, to see whether
> haproxy in the amphora listens on the right IP and port, I print
> /var/lib/octavia/ec5ee7c5-7474-424f-9f44-71b338cf3e57/haproxy.cfg in the
> console and see the following info.
>
> # Configuration for lb1
> global
> daemon
> user nobody
> log /dev/log local0
> log /dev/log local1 notice
> stats socket /var/lib/octavia/ec5ee7c5-7474-424f-9f44-71b338cf3e57.sock
> mode 0666 level user
>
> defaults
> log global
> retries 3
> option redispatch
> timeout connect 5000
> timeout client 5
> 

Re: [openstack-dev] Garbage patches for simple typo fixes

[Michael Johnson]

A recent extreme example:
https://review.openstack.org/#/c/494981/1/specs/version0.8/active_passive_loadbalancer.rst

I would love to have a boilerplate statement I can use as a template
for things like this.  I feel bad -1/-2 these as I want to encourage
involvement, but they are a drain on the system.

Michael


On Fri, Sep 22, 2017 at 4:18 PM, Zhipeng Huang  wrote:
> Hi Doug,
>
> Absolutely glad to help on this matter. We could take this offline first via
> email or irc chat and then comes up with a solution for the broader
> community to review
>
> On Sat, Sep 23, 2017 at 2:47 AM, Doug Hellmann 
> wrote:
>>
>> Excerpts from Davanum Srinivas (dims)'s message of 2017-09-22 13:47:06
>> -0400:
>> > Doug,
>> > Howard (cc'ed) already did a bunch of reaching out especially on
>> > wechat. We should request his help.
>> >
>> > Howard,
>> > Can you please help with communications and follow up?
>> >
>> > Thanks,
>> > Dims
>>
>> Thanks, Dims and Howard,
>>
>> I think the problem has reached a point where it would be a good
>> idea to formalize our approach to outreach. We should track the
>> patches or patch series identified as problematic, so reviewers
>> know not to bother with them. We can also track who is contacting
>> whom (and how) so we don't have a bunch of people replicating work
>> or causing confusion for people who are trying to contribute. Having
>> that information will also help us figure out when we need to
>> escalate by finding the right managers to be talking to.
>>
>> Let's put together a small team to manage this instead of letting
>> it continue to cause frustration for everyone.
>>
>> Doug
>>
>> >
>> > On Fri, Sep 22, 2017 at 1:43 PM, Doug Hellmann 
>> > wrote:
>> > > Excerpts from Matt Riedemann's message of 2017-09-22 08:26:31 -0500:
>> > >> On 9/22/2017 7:10 AM, Tom Barron wrote:
>> > >> > FWIW I think it is better not to attribute motivation in these
>> > >> > cases.
>> > >> > Perhaps the code submitter is trying to pad stats, but perhaps they
>> > >> > are
>> > >> > just a new contributor trying to learn the process with a
>> > >> > "harmless"
>> > >> > patch, or just a compulsive clean-upper who hasn't thought through
>> > >> > the
>> > >> > costs in reviewer time and CI resources.
>> > >>
>> > >> I agree. However, the one that set me off last night was a person
>> > >> from
>> > >> one company who I've repeatedly -1ed the same types of patches in
>> > >> nova
>> > >> for weeks, including on stable branches, and within 10 minutes of
>> > >> each
>> > >> other across several repos, so it's clearly part of some daily
>> > >> routine.
>> > >> That's what prompted me to send something to the mailing list.
>> > >>
>> > >
>> > > As fungi points out, education and communication are likely to be
>> > > our best solution. Maybe one approach is to identify the companies
>> > > and individuals involved and find one of our community members to
>> > > contact them directly via email.  We would want the person doing
>> > > that to be willing to explain all of the reasons the community does
>> > > not want the sort of activity we are rejecting and to provide
>> > > guidance about more useful contributions (Matt's comment is a great
>> > > start on both). I imagine that conversation would take a good deal
>> > > of patience, especially after the second or third time, but a personal
>> > > touch frequently makes all the difference in these sorts of cases.
>> > >
>> > > If we have someone willing to step into that sort of role, I would
>> > > be happy to help craft the initial contact messages and advise as
>> > > needed.
>> > >
>> > > Does anyone want to volunteer to work with me and actually send the
>> > > emails?
>> > >
>> > > 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
>> >
>
>
>
>
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Product Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>
> __
> 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: 

Re: [openstack-dev] [Neutron] Denver Team Dinner

[Michael Johnson]

+1 Miguel, thanks for putting this together!

Michael

On Wed, Sep 13, 2017 at 9:09 PM, Akihiro Motoki  wrote:
> +1 thanks for organizing this
>
> 2017-09-12 17:23 GMT-06:00 Miguel Lavalle :
>> Dear Neutrinos,
>>
>> Our social event will take place on Thursday September 12th at 7:30pm. The
>> venue is going to be https://www.famousdaves.com/Denver-Stapleton. It is
>> located 0.4 miles from the Renaissance Hotel, which translates to an easy 9
>> minutes walk.
>>
>> I have a reservation for a group of 30 people under my name. Please respond
>> to this message with your attendance confirmation by Wednesday night, so I
>> can get a more accurate head count.
>>
>> Looking forward to see y'all Thursday night
>>
>> Best regards
>>
>> Miguel
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [neutron] [octavia] Neutron LBaaS V2 with haproxy namespace driver HA

[Michael Johnson]

Hi Liping,

FYI, Neutron LBaaS is no longer part of Neutron.  Load balancing has
been consolidated under the Octavia project. I have added that tag to
the subject.

We currently do not have plans to add HA capabilities to the haproxy
namespace driver. The intention behind building the octavia driver was
to enable a scalable and HA load balancing driver.
There would be a number of complications to enabling this and given
the limitations of the haproxy namespace driver most environments with
HA requirements use the octavia driver.

Michael

On Sun, Sep 10, 2017 at 6:44 AM, Liping Mao (limao)  wrote:
> Hi Neutron LBaaS team,
>
> One quick question about HA LBaaS V2 with haproxy namespace driver(not 
> Octavia).
> Do we have any plan to support Haproxy HA with Keepalived?
> (Something similar with L3 HA).
>
> I see we got some patch supported some level HA[1][2], but
> Still need sometime(Mins) to failover when the active node is down.
>
> Thanks for your help.
>
> [1]https://review.openstack.org/#/c/28/
> [2]https://review.openstack.org/#/c/327966/
>
> Regards,
> Liping Mao
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [octavia][l7policy] Is redirect to pool supported?

[Michael Johnson]

Yes, you can redirect to a pool.  Multiple pools can be created under
the load balancer object and then referenced from the L7 Policy.

This example shows a load balancer with a redirect to pool L7 policy:
https://docs.openstack.org/octavia/latest/user/guides/l7-cookbook.html#send-requests-starting-with-js-or-images-to-static-pool
Note that the first step in the example is to create the pool on the
load balancer.

Michael (johnsom)

On Fri, Sep 8, 2017 at 12:09 AM,   wrote:
> Sorry, I forgot the link to this documentation:
> https://docs.openstack.org/octavia/latest/user/guides/l7-cookbook.html
>
>
>
> From: mihaela.ba...@orange.com [mailto:mihaela.ba...@orange.com]
> Sent: Friday, September 08, 2017 10:07 AM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [octavia][l7policy] Is redirect to pool supported?
>
>
>
> Hello,
>
>
>
> Is redirect_to_pool policy currently supported with Octavia? Since a
> listener can only have one pool (the default pool) I cannot see how this can
> be configured. However, this documentation details a lot of scenarios. I am
> testing Octavia Ocata version.
>
>
>
> Thank you,
>
> Mihaela Balas
>
> _
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
>
> Thank you.
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [nova] [neutron] Should we continue providing FQDNs for instance hostnames?

[Michael Johnson]

FYI, code in Octavia that checks for the extensions you could borrow:
https://github.com/openstack/octavia/blob/master/octavia/network/drivers/neutron/base.py#L49

On Mon, Sep 4, 2017 at 11:18 PM, Gary Kotton  wrote:
>
>
> On 9/4/17, 3:47 PM, "Stephen Finucane"  wrote:
>
> On Mon, 2017-09-04 at 11:51 +, Gary Kotton wrote:
> > On 9/4/17, 11:18 AM, "Stephen Finucane"  wrote:
> > > Nova has a feature whereby it will provide instance host names that 
> cloud-
> > > init can extract and use inside the guest, i.e. this won't happen 
> without
> > > cloud-init. These host names are fully qualified domain names (FQDNs) 
> based
> > > upon the instance name and local domain name. However, as noted in bug
> > > #1698010 [1], the domain name part of this is based up nova's 
> 'dhcp_domain'
> > > option, which is a nova-network option that has been deprecated [2].
> > >
> > > I've started work on a fix [3] that will allow us to retrieve this
> > > information from neutron instead, uncoupling us from this legacy 
> option.
> > > However, some commentators have pointed out that this may not 
> necessarily
> > > be what we want to do: a FQDN is a hostname and domain name, and 
> using one
> > > as a hostname may not be that clever nor correct.
> > >
> > > My networking fu isn't strong enough to deliver a verdict so I'm 
> hoping
> > > someone else can make my mind up for me: do we want to migrate this 
> feature
> > > to neutron, or do we want to stop using FQDN and just use instance 
> names?
> >
> > Hi,
> >
> > Your patch https://review.openstack.org/#/c/480616/ requires that 
> neutron
> > expose the ‘DNS Integration’ extension be support by neutron and the 
> relevant
> > networking plugin. If it does not then will be a regression and things 
> will
> > not work.
> >
> > In addition to this that is per network and not global so there will 
> also be
> > a regression for running instances if nova is updated.
>
> OK, so ultimately this isn't something we can rely on from neutron?
> [Gary] No, you can rely on it from Neutron – you just need to be aware that 
> if the extension is supported then it can be used. If not then you should 
> continue to use the existing configuration vaiable
>
>  Does that
> mean we should abandon the idea of providing FQDN when using neutron? 
> Mores to
> the original point, is there any reason we would want to/should use FQDN?
>
> [Gary] Yes, we should support this. Applications make use of this and hence 
> the support
>
> Stephen
>
> > > [1] https://bugs.launchpad.net/nova/+bug/1698010
> > > [2] https://review.openstack.org/#/c/395683/
> > > [3] https://review.openstack.org/#/c/480616/
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Octavia]Questions about octavia flavors spec

[Michael Johnson]

Hi,

Flavors are intended to be setup by the operator/admin only.  They
capture details of the load balancer offering and any local specific
configuration.  The intent here is the flavor options and descriptions
will be visible to end users, but creation/modification would require
an admin role.  End users will be able to specify the flavor they
would like to use for the load balancer at load balancer creation time
via the load balancer create API.

We are just now starting to work on providers.  The providers
implementation needs a spec and review process. I hope we can create
this spec and create the providers interface during the Queens series.

Michael


On Tue, Aug 15, 2017 at 7:09 PM, 何庆  wrote:
> Hi, I'm trying to figure out how the flavor will be implemented and have few
> questions about the flavor spec[1]
>
> 1. What does "RO" mean in API /flavors? Is it short for ReadOnly?
> In my understanding, user need create flavor by himself, so the flavor API
> should not be readonly.
>
> FLAVOR(/flavors)
>
> +-+---+-+-++-+
> |Attribute|Type   |Access   |Default  |Validation/ |Description
> |
> |Name |   | |Value|Conversion  |
> |
> +=+===+=+=++=+
> |id   |string |RO, admin|generated|N/A |identity
> |
> | |(UUID) | | ||
> |
> +-+---+-+-++-+
> |name |string |RO, admin|''   |string  |human-readable
> |
> | |   | | ||name
> |
> +-+---+-+-++-+
> |description  |string |RO, admin|''   |string  |human-readable
> |
> | |   | | ||description
> |
> +-+---+-+-++-+
> |enabled  |bool   |RO, admin|true |bool|toggle
> |
> | |   | | ||
> |
> +-+---+-+-++-+
> |flavor_profile_id|string |RO, admin| |string  |human-readable
> |
> | |   | | |
> |flavor_profile_id|
> +-+---+-+-++-+
>
> 2. Do we also need an API like /providers to query providers and metadata
> available？
>
>
>
> [1] https://review.openstack.org/#/c/392485/
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

[Michael Johnson]

Awesome Monty. This is a great proposal.  I have no preference on which way 
these merge, but see huge value in straightening this out.  Frankly I think 
some of the tempest plugin work could benefit from having an official and well 
maintained SDK as well.

So, I am in favor of getting the ball rolling here. I was really hoping to be 
able to use this for our dashboard work in Queens, but giving the work here I 
may need to do something in the interim. Maybe if these patches merge for 
python-openstacksdk I can use that for now and migrate as new SDK becomes 
available.

Michael

-Original Message-
From: Monty Taylor [mailto:mord...@inaugust.com] 
Sent: Friday, August 4, 2017 9:53 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [python-openstacksdk] Status of 
python-openstacksdk project

Conclusion
--

As I mentioned at the top, I'd been thinking some of this already and had 
planned on chatting with folks in person at the PTG, but it seems we're at a 
place where that's potentially counter productive.

Depending on what people think I can follow this up with some governance 
resolutions and more detailed specs.

Thanks!
Monty

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


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

[openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

[Michael Johnson]

Hi OpenStack developers,

I was wondering what is the current status of the python-openstacksdk
project.  The Octavia team has posted some patches implementing our new
Octavia v2 API [1] in the SDK, but we have not had any reviews.  I have also
asked some questions in #openstack-sdks with no responses.
I see that there are some maintenance patches getting merged and a pypi
release was made 6/14/17 (though not through releases project).  I'm not
seeing any mailing list traffic and the IRC meetings seem to have ended in
2016.

With all the recent contributor changes, I want to make sure the project
isn't adrift in the sea of OpenStack before we continue to spend development
time implementing the SDK for Octavia. We were also planning to use it as
the backing for our dashboard project.

Since it's not in the governance projects list I couldn't determine who the
PTL to ping would be, so I decided to ping the dev mailing list.

My questions:
1. Is this project abandoned?
2. Is there a plan to make it an official project?
3. Should we continue to develop for it?

Thanks,
Michael (johnsom)

[1]
https://review.openstack.org/#/q/project:openstack/python-openstacksdk+statu
s:open+topic:%255Eoctavia.*


__
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] PTL nomination

[Michael Johnson]

My fellow OpenStack community,

I would like to nominate myself for Octavia PTL for Queens. I am currently
the PTL for the Pike release series and would like to continue helping our
team provide network load balancing services for OpenStack.

For those of you that do not know me, I work for Rackspace. Prior to joining
Rackspace I worked for Hewlett-Packard for fifteen years on data center
automation, distributed network systems, embedded system design, and big
data.

During Pike, the Octavia team made huge progress by implementing the Octavia
v2 API, adding a new and up to date API reference, implementing a OpenStack
client plugin, new health monitoring capabilities, and many more
enhancements.

As we start to plan for Queens, I expect we will have a focus on adding the
provider interface to the Octavia v2 API, flavors, Active/Active load
balancer
support, and implement a new tempest plugin for Octavia.  I also want to
maintain our priority on providing onboarding support for new contributors
to
get involved with Octavia.

Thank you for your support of Octavia during Pike and your consideration for
Queens,

Michael Johnson (johnsom)


__
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 time and channel change

[Michael Johnson]

As discussed in today's octavia IRC meeting we are changing the meeting time
and IRC channel for the weekly meeting.

Starting next week we will now be meeting at 17:00 UTC on Wednesdays in
channel #openstack-meeting.

This is the same day, just three hours earlier to accommodate team members
in different time zones.

Details can be found here: http://eavesdrop.openstack.org/#Octavia_Meeting

An ICS file is available here:
http://eavesdrop.openstack.org/calendars/octavia-meeting.ics

The original proposal is here:
http://lists.openstack.org/pipermail/openstack-dev/2017-June/118363.html

The "Doodle" we used for voting is here:
https://doodle.com/poll/kxvii2tn9rydp6ed

I hope to see more of you joining us for the octavia meeting!

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

Re: [openstack-dev] [octavia] fail to plug vip to amphora

[Michael Johnson]

Hi Yipei,

 

I have meant to add this as a config option, but in the interim you can do the 
following to disable the automatic cleanup by disabling the revert flow in 
taskflow:

 

octavia/common/base_taskflow.py line 37 add “never_resolve=True,” to the engine 
load parameters.

 

Michael

 

From: Yipei Niu [mailto:newy...@gmail.com] 
Sent: Monday, June 26, 2017 11:34 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [octavia] fail to plug vip to amphora

 

Hi, Micheal,

 

Thanks a lot for your help, but I still have one question. 

 

In Octavia, once the controller worker fails plugging VIP to the amphora, the 
amphora is deleted immediately, making it impossible to trace the error. How to 
prevent Octavia from stopping and deleting the amphora? 

 

Best regards,

Yipei 

 

On Mon, Jun 26, 2017 at 11:21 AM, Yipei Niu  > wrote:

Hi, all,

 

I am trying to create a load balancer in octavia. The amphora can be booted 
successfully, and can be reached via icmp. However, octavia fails to plug vip 
to the amphora through the amphora client api and returns 500 status code, 
causing some errors as follows.

 

   |__Flow 
'octavia-create-loadbalancer-flow': InternalServerError: Internal Server Error

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
Traceback (most recent call last):

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
  File 
"/usr/local/lib/python2.7/dist-packages/taskflow/engines/action_engine/executor.py",
 line 53, in _execute_task

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
result = task.execute(**arguments)

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
  File 
"/opt/stack/octavia/octavia/controller/worker/tasks/amphora_driver_tasks.py", 
line 240, in execute

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
amphorae_network_config)

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
  File 
"/opt/stack/octavia/octavia/controller/worker/tasks/amphora_driver_tasks.py", 
line 219, in execute

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
amphora, loadbalancer, amphorae_network_config)

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
  File 
"/opt/stack/octavia/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 
137, in post_vip_plug

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
net_info)

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
  File 
"/opt/stack/octavia/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 
378, in plug_vip

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
return exc.check_exception(r)

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
  File "/opt/stack/octavia/octavia/amphorae/drivers/haproxy/exceptions.py", 
line 32, in check_exception

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
raise responses[status_code]()

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
InternalServerError: Internal Server Error

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker

 

To fix the problem, I log in the amphora and find that there is one http server 
process is listening on port 9443, so I think the amphora api services is 
active. But do not know how to further investigate what error happens inside 
the amphora api service and solve it? Look forward to your valuable comments.

 

Best regards,

Yipei 

 

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

Re: [openstack-dev] [octavia] fail to plug vip to amphora

[Michael Johnson]

Hello Yipei,

 

You are on the track to debug this.

When you are logged into the amphora, please check the following logs to see 
what the amphora-agent error is:

 

/var/log/amphora-agent.log

And

/var/log/syslog

 

One of those two logs will have the error information.

 

Michael

 

 

From: Yipei Niu [mailto:newy...@gmail.com] 
Sent: Sunday, June 25, 2017 8:21 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [octavia] fail to plug vip to amphora

 

Hi, all,

 

I am trying to create a load balancer in octavia. The amphora can be booted 
successfully, and can be reached via icmp. However, octavia fails to plug vip 
to the amphora through the amphora client api and returns 500 status code, 
causing some errors as follows.

 

   |__Flow 
'octavia-create-loadbalancer-flow': InternalServerError: Internal Server Error

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
Traceback (most recent call last):

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
  File 
"/usr/local/lib/python2.7/dist-packages/taskflow/engines/action_engine/executor.py",
 line 53, in _execute_task

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
result = task.execute(**arguments)

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
  File 
"/opt/stack/octavia/octavia/controller/worker/tasks/amphora_driver_tasks.py", 
line 240, in execute

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
amphorae_network_config)

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
  File 
"/opt/stack/octavia/octavia/controller/worker/tasks/amphora_driver_tasks.py", 
line 219, in execute

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
amphora, loadbalancer, amphorae_network_config)

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
  File 
"/opt/stack/octavia/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 
137, in post_vip_plug

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
net_info)

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
  File 
"/opt/stack/octavia/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 
378, in plug_vip

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
return exc.check_exception(r)

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
  File "/opt/stack/octavia/octavia/amphorae/drivers/haproxy/exceptions.py", 
line 32, in check_exception

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
raise responses[status_code]()

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker 
InternalServerError: Internal Server Error

2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker

 

To fix the problem, I log in the amphora and find that there is one http server 
process is listening on port 9443, so I think the amphora api services is 
active. But do not know how to further investigate what error happens inside 
the amphora api service and solve it? Look forward to your valuable comments.

 

Best regards,

Yipei 

__
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] [doc][ptls][all] Documentation publishing future

[Michael Johnson]

Hi Alex,

 

As you know I am a strong proponent of moving the docs into the project team 
repositories [1].

 

Personally I am in favor of pulling the Band-Aids off and doing option 1.  I 
think centralizing the documentation under one tree and consolidating the build 
into one job has benefits.  I can’t speak to the complexities of the 
documentation template(s?) and the sphinx configuration issues that might arise 
from this plan, but from a PTL/developer/doc writer I like the concept.  I 
fully understand this means work for us to move our API-REF, etc. but I think 
it is worth it.

 

As a secondary vote I am also ok with option 2.  I just think we might as well 
do a full consolidation.

 

I am not a fan of requiring project teams to setup separate repos for the docs, 
there is value to having them in tree for me.  So, I would vote against 3.

 

Michael

 

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

 

From: Alexandra Settle [mailto:a.set...@outlook.com] 
Sent: Monday, May 22, 2017 2:39 AM
To: OpenStack Development Mailing List (not for usage questions) 

Cc: 'openstack-d...@lists.openstack.org' 
Subject: [openstack-dev] [doc][ptls][all] Documentation publishing future

 

Hi everyone,

 

The documentation team are rapidly losing key contributors and core reviewers. 
We are not alone, this is happening across the board. It is making things 
harder, but not impossible.

Since our inception in 2010, we’ve been climbing higher and higher trying to 
achieve the best documentation we could, and uphold our high standards. This is 
something to be incredibly proud of.

 

However, we now need to take a step back and realise that the amount of work we 
are attempting to maintain is now out of reach for the team size that we have. 
At the moment we have 13 cores, of whom none are full time contributors or 
reviewers. This includes myself.

 

Until this point, the documentation team has owned several manuals that include 
content related to multiple projects, including an installation guide, admin 
guide, configuration guide, networking guide, and security guide. Because the 
team no longer has the resources to own that content, we want to invert the 
relationship between the doc team and project teams, so that we become liaisons 
to help with maintenance instead of asking for project teams to provide 
liaisons to help with content. As a part of that change, we plan to move the 
existing content out of the central manuals repository, into repositories owned 
by the appropriate project teams. Project teams will then own the content and 
the documentation team will assist by managing the build tools, helping with 
writing guidelines and style, but not writing the bulk of the text.

 

We currently have the infrastructure set up to empower project teams to manage 
their own documentation in their own tree, and many do. As part of this change, 
the rest of the existing content from the install guide and admin guide will 
also move into project-owned repositories. We have a few options for how to 
implement the move, and that's where we need feedback now.

 

1. We could combine all of the documentation builds, so that each project has a 
single doc/source directory that includes developer, contributor, and user 
documentation. This option would reduce the number of build jobs we have to 
run, and cut down on the number of separate sphinx configurations in each 
repository. It would completely change the way we publish the results, though, 
and we would need to set up redirects from all of the existing locations to the 
new locations and move all of the existing documentation under the new 
structure.

 

2. We could retain the existing trees for developer and API docs, and add a new 
one for "user" documentation. The installation guide, configuration guide, and 
admin guide would move here for all projects. Neutron's user documentation 
would include the current networking guide as well. This option would add 1 new 
build to each repository, but would allow us to easily roll out the change with 
less disruption in the way the site is organized and published, so there would 
be less work in the short term.

 

3. We could do option 2, but use a separate repository for the new 
user-oriented documentation. This would allow project teams to delegate 
management of the documentation to a separate review project-sub-team, but 
would complicate the process of landing code and documentation updates together 
so that the docs are always up to date.

 

Personally, I think option 2 or 3 are more realistic, for now. It does mean 
that an extra build would have to be maintained, but it retains that key 
differentiator between what is user and developer documentation and involves 
fewer changes to existing published contents and build jobs. I definitely think 
option 1 is feasible, and would be happy to make it work if the community 
prefers this. 

[openstack-dev] [LBaaS][octavia] Weekly IRC meeting cancelled for three weeks

[Michael Johnson]

Hi Octavia team,

At today's weekly LBaaS/Octavia IRC meeting we decided to cancel the next
three meetings due to the OpenStack summit, other conflicts, and vacations.
We just won't have quorum these weeks.

Safe travels for those attending the OpenStack summit and we will meet again
5/31/17.

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

Re: [openstack-dev] OpenStack "R" Release Naming Preliminary Results

[Michael Johnson]

Hmm, I never received an email to vote for the name, just for the TC election.

Michael


-Original Message-
From: Monty Taylor [mailto:mord...@inaugust.com] 
Sent: Friday, April 21, 2017 5:12 AM
To: OpenStack Development Mailing List (not for usage questions) 
; Openstack Users 

Subject: [openstack-dev] OpenStack "R" Release Naming Preliminary Results

Hello all!

We left the voting open for an additional week because of how long it took to 
get emails sent out and the subsequent email issues. We'll be looking at 
options for next time to make that better.

The raw results are below - however...

**PLEASE REMEMBER** that these now have to go through legal vetting. So it is 
too soon to say "All Hail OpenStack Radium" - the last several naming polls 
have produced issues with the top choice. So as exciting as a potentially 
Radioactive OpenStack release might be, we might also get a release that's 
obsessed with Interop and Consistent Logging, or one married to my cousin. It's 
_possible_ we even make it down to having a release that plays on the American 
Football Team of the University of Arkansas. There are so many great 
possibilities!

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

http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_e53f789ff7acc996

Result

1. Radium  (Condorcet winner: wins contests with all other choices) 2. Rocky  
loses to Radium by 807–556 3. Rex  loses to Radium by 807–532, loses to Rocky 
by 638–615 4. Razorback  loses to Radium by 796–516, loses to Rex by 630–626 5. 
Rock  loses to Radium by 841–464, loses to Razorback by 660–569 6. Root  loses 
to Radium by 866–442, loses to Rock by 581–527 7. Raspberry  loses to Radium by 
891–381, loses to Root by 579–536 8. Ray  loses to Radium by 906–355, loses to 
Raspberry by 553–539 9. Rambler  loses to Radium by 916–336, loses to Ray by 
542–525 10. Railspur  loses to Radium by 904–316, loses to Rambler by 507–468 
11. Rampart  loses to Radium by 926–301, loses to Railspur by 475–467 12. 
Richmond  loses to Radium by 929–306, loses to Rampart by 506–471 13. Rockies  
loses to Radium by 926–293, loses to Richmond by 475–462 14. Rosswood  loses to 
Radium by 938–290, loses to Rockies by 463–449 15. Rebecca  loses to Radium by 
911–350, loses to Rosswood by 484–481 16. Rupert  loses to Radium by 945–283, 
loses to Rebecca by 514–447 17. Revelstoke  loses to Radium by 949–269, loses 
to Rupert by 472–425 18. Robson  loses to Radium by 977–250, loses to 
Revelstoke by 439–423 19. Roderick  loses to Radium by 961–243, loses to Robson 
by 432–409 20. Rossland  loses to Radium by 966–241, loses to Roderick by 
401–394 21. Rambles  loses to Radium by 977–222, loses to Rossland by 421–381 
22. Raush  loses to Radium by 986–193, loses to Rambles by 405–379 23. Renfrew  
loses to Radium by 976–213, loses to Raush by 377–363

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


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

Re: [openstack-dev] [Taskflow] Current state or the project ?

[Michael Johnson]

Hi Robin,

 

The Octavia project (shameless plug: 
https://docs.openstack.org/developer/octavia/) relies on TaskFlow for the core 
workflow.  For us, the TaskFlow project is very stable.

 

Michael

 

From: Robin De-Lillo [mailto:rdeli...@rodeofx.com] 
Sent: Wednesday, April 19, 2017 11:14 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Taskflow] Current state or the project ?

 

Hello Guys,

 

I'm Robin a Software developer for a VFX company based in Canada. As the 
company grow up, we are currently looking into redesigning our internal 
processes and workflows in a more nodal/graph based approach.

 

Ideally we would like to start from an existing library so we don't 
re-implement things from scratch. We found out TaskFlow which, after a couple 
of tests, looks very promising to us. Good work with that !!

 

We were wondering what is the current state of this project ? Is that still 
something under active development or a priority for OpenStack ? As we would 
definitely be happy to contribute to this library in the future, we are just 
gathering information around for now to ensure we pick up the best solution 
which suit our needs.

 

Thanks a lot,

Robin De Lillo

__
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] [glance][ironic][octavia] oslo.config 4.0 will break projects' unit test

[Michael Johnson]

Thank you ChangBo, I have resolved the issues in octavia in this patch: 
https://review.openstack.org/457356 up for review.

 

Michael

 

From: ChangBo Guo [mailto:glongw...@gmail.com] 
Sent: Sunday, April 16, 2017 12:32 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [glance][ironic][octavia] oslo.config 4.0 will 
break projects' unit test

 

As I expect, there are some failures in periodic tasks recently [1] if we set 
enforce_type with True by default,  we'd better fix them before we release 
oslo.config 4.0.  Some guys had been working on this :
Nova: https://review.openstack.org/455534 should fix failures

tempest:  https://review.openstack.org/456445 fixed

Keystone:  https://review.openstack.org/455391 wait for oslo.config 4.0

 

We still need help from Glance/Ironic/Octavia

Glance:  https://review.openstack.org/#/c/455522/ need review

Ironic:  Need fix failure in 
http://logs.openstack.org/periodic/periodic-ironic-py27-with-oslo-master/680abfe/testr_results.html.gz
Octavia: Need fix failure in 
http://logs.openstack.org/periodic/periodic-octavia-py35-with-oslo-master/80fee03/testr_results.html.gz


[1] http://status.openstack.org/openstack-health/#/?groupKey=build_name 

 =hour=-with-oslo

 

2017-04-04 0:01 GMT+08:00 ChangBo Guo  >:

Hi ALL,


oslo_config provides method CONF.set_override[1] , developers usually use it to 
change config option's value in tests. That's convenient . By default  
parameter enforce_type=False,  it doesn't check any type or value of override. 
If set enforce_type=True , will check parameter override's type and value.  In 
production code(running time code),  oslo_config  always checks  config 
option's value. In short, we test and run code in different ways. so there's  
gap:  config option with wrong type or invalid value can pass tests when

parameter enforce_type = False in consuming projects.  that means some invalid 
or wrong tests are in our code base. 


We began to warn user about the change since Sep, 2016 in [2]. This change will 
notify consuming project to write correct test cases with config options. 

We would make enforce_type = true by default in [3], that may break some 
projects' tests, that's also raise wrong unit tests. The failure is easy to 
fix, which

is recommended. 



[1] 
https://github.com/openstack/oslo.config/blob/efb287a94645b15b634e8c344352696ff85c219f/oslo_config/cfg.py#L2613
[2] https://review.openstack.org/#/c/365476/
[3] https://review.openstack.org/328692



-- 

ChangBo Guo(gcb)




-- 

ChangBo Guo(gcb)

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

Re: [openstack-dev] [barbican] How to update cert in the secret

[Michael Johnson]

Hi Andrey,

 

As we discussed on IRC, the listeners in LBaaS v2 allow you to update the 
barbican container IDs.  This will start the certificate update process on the 
load balancers with the new content from barbican.

 

The neutron client, as you noted, does not appear to have this capability, but 
the API supports this as the primary means to update certificate content for 
LBaaS.  This will be included in the octavia OpenStack client.

 

Michael

 

From: Andrey Grebennikov [mailto:agrebenni...@mirantis.com] 
Sent: Monday, April 3, 2017 12:14 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [barbican] How to update cert in the secret

 

Hey Barbican folks, I have a question regarding the functionality of the 
secrets containers please.

 

If I got my secret created is there a way to update it down the road with 
another cert?

The usecase is pretty common - using barbican with neutron lbaas.

When the load balance from the lbaas backend gets the cert from barbican there 
is no way to update the neutron load balancer with the new secret seems so.

The only way to update the cert within the balancer is to update the barbican 
secret and trigger the balancer to re-request the cert (while adding the pool 
member for example).

 

Any help is greatly appreciated!

 

-- 

Andrey Grebennikov

__
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] Project Navigator Updates - Feedback Request

[Michael Johnson]

I have a few comments on the updated Project Navigator.

 

1.  I hope this is mostly automated at this point?  The current content for 
Project Navigator is very out of date (Mitaka?) and folks have asked why 
projects are not listed there.
2.  What is the policy around the tags?  For octavia I see that standard 
deprecation isn’t listed there even though our neutron-lbaas repository does 
have the tag.  Granted, I need to update the octavia repository to also have 
the tag, but with projects that have multiple sub-projects, how is this listing 
determined?
3.  How is the project age determined?  I see that octavia shows one year, 
but it has been an active project since 2014.  2012 if you count neutron-lbaas 
(now part of octavia).  This could be confusing for folks that have attended 
summit sessions in the past or downloaded the packages previously.
4.  API version history is another item I am curious to understand how it 
is calculated.  It seems confusing with actual project API 
versions/microversions when it links to the releases page.  API version history 
is not a one-to-one relationship with project releases.
5.  The “About this project” seems to come from the developer 
documentation.  Is this something the PTL can update?
6.  Is there a way to highlight that a blank adoption is because a project 
was not included in the survey?  This can also be deceiving and lead someone to 
think that a project is unused.  (Looking at page 54 of the April survey from 
2016 I expect load balancing is widely used)
7.  Finally, from reading my above questions/comments, it would be nice to 
have a “PTL guide to project navigator”.

 

Thank you for updating this, folks have asked us why octavia was not listed.

 

Michael

 

 

From: Lauren Sell [mailto:lau...@openstack.org] 
Sent: Friday, March 24, 2017 9:58 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] Project Navigator Updates - Feedback Request

 

Hi everyone,

 

We’ve been talking for some time about updating the project navigator, and we 
have a draft ready to share for community feedback before we launch and 
publicize it. One of the big goals coming out of the joint TC/UC/Board meeting 
a few weeks ago[1] was to help better communicate ‘what is openstack?’ and this 
is one step in that direction.

A few goals in mind for the redesign:
- Represent all official, user-facing projects and deployment services in the 
navigator
- Better categorize the projects by function in a way that makes sense to 
prospective users (this may evolve over time as we work on mapping the 
OpenStack landscape)
- Help users understand which projects are mature and stable vs emerging
- Highlight popular project sets and sample configurations based on different 
use cases to help users get started

For a bit of context, we’re working to give each OpenStack official project a 
stronger platform as we think of OpenStack as a framework of composable 
infrastructure services that can be used individually or together as a powerful 
system. This includes the project mascots (so we in effect have logos to 
promote each component separately), updates to the project navigator, and 
bringing back the “project updates” track at the Summit to give each PTL/core 
team a chance to provide an update on their project roadmap (to be recorded and 
promoted in the project navigator among other places!). 

We want your feedback on the project navigator v2 before it launches. Please 
take a look at the current version on the staging site and provide feedback on 
this thread.

http://devbranch.openstack.org/software/project-navigator/

Please review the overall concept and the data and description for your project 
specifically. The data is primarily pulled from TC tags[2] and Ops tags[3]. 
You’ll notice some projects have more information available than others for 
various reasons. That’s one reason we decided to downplay the maturity metric 
for now and the data on some pages is hidden. If you think your project is 
missing data, please check out the repositories and submit changes or again 
respond to this thread.

Also know this will continue to evolve and we are open to feedback. As I 
mentioned, a team that formed at the joint strategy session a few weeks ago is 
tackling how we map OpenStack projects, which may be reflected in the 
categories. And I suspect we’ll continue to build out additional tags and 
better data sources to be incorporated.

Thanks for your feedback and help.

Best,
Lauren

[1] 
http://superuser.openstack.org/articles/community-leadership-charts-course-openstack/
[2] https://governance.openstack.org/tc/reference/tags/
[3] https://wiki.openstack.org/wiki/Operations/Tags

 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [neutron][lbaasv2] Migrate LBaaS instance

[Michael Johnson]

Hi Saverio,

First, please note, in the future the best tag for load balancing is
[octavia] as it is no longer part of the neutron project.

I am sorry that you are so anxious and confused about the current state of
load balancing for OpenStack.  Let me clarify a few things:

1. LBaaSv2 is not going away and is not deprecated.  The neutron-lbaas code
base is going into deprecation in favor of the octavia code base.  I will
highlight two things, among others, we are doing to ease this transition for
operators:
a. For some time into the future you will be able to continue to use LBaaSv2
via neutron using the proxy driver in neutron-lbaas.
b. There will be migration procedures and scripts that will move, in place,
load balancers from neutron-lbaas into octavia.
2. Deprecation means we will not continue to develop features for
neutron-lbaas, but it will remain in the code base for at least two more
releases and continue to receive bug fixes.  It's a formal way of saying,
hey, in the future we are going to remove this.
3. New features will be added to the octavia code base.  It is only
neutron-lbaas that will be going into feature freeze for new feature
development due to the transition.
4. Any tools written against the neutron endpoint for neutron-lbaas using
the LBaaSv2 API will work with Octavia by updating the endpoint you are
pointing to from neutron to octavia.
5. We are not making any changes to stable/liberty, stable/mitaka,
stable/newton, or stable/ocata releases.  I will note, per OpenStack stable
release policy, liberty is EOL and mitaka will be next month and we are not
allowed to add new features to any previous releases.   Please see the
OpenStack stable policy here:
https://docs.openstack.org/project-team-guide/stable-branches.html
6. Octavia was available and, in fact, the reference load balancing driver
in Liberty.
7. Multiple operators are represented on the core review team for octavia.
We try really hard to listen to feedback we get and to do what is best for
folks using load balancing in OpenStack.  It is unfortunate our
presentations at the Barcelona summit were denied and we did not get an
opportunity to share our plan with the community and get feedback.  If you
have concerns I encourage you to reach out to us via our weekly IRC
meetings, our channel on IRC #openstack-lbaas, or via the mailing list with
the [octavia] tag.  As you know, I have been responding to your emails with
load balancing questions.

To answer Zhi's e-mail:

This is correct, if you are using the legacy haproxy namespace driver, and
not the octavia driver, there is currently no easy method to migrate the
ownership of a load balancer from one agent to another.
The legacy haproxy namespace driver is/was not intended for high
availability.  If you want a highly available open source load balancing
option, I highly recommend you use the octavia driver instead of the haproxy
namespace driver.  It was designed to provide scale and availability.  You
would not have the issue you are describing with the octavia driver.

That said, if you want to continue to develop new features for the haproxy
namespace driver, we should start planning to do so in the octavia code
base.
We will be starting work on a port of the haproxy namespace driver into
octavia soon.  We are however discussing what the future should be for this
driver given its limitations.  I think the best plan will be to port it over
into a standalone driver that folks can contribute to if they have a need
for it and we can deprecate it if there is no longer support for it.

Michael


-Original Message-
From: Saverio Proto [mailto:saverio.pr...@switch.ch] 
Sent: Friday, March 17, 2017 4:55 AM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [neutron][lbaasv2] Migrate LBaaS instance

Hello there,

I am just back from the Ops Midcycle where Heidi Joy Tretheway reported some
data from the user survey.

So if we look at deployments with more than 100 servers NO ONE IS USING
NEWTON yet. And I scream this loud. Everyone is still in Liberty or Mitaka.

I am just struggling to upgrade to LBaaSv2 to hear that is already going
into deprecation. The feature Zhi is proposing is important also for me once
I go to production.

I would encourage devs to listen more to operators feedback. Also you devs
cant just ignore that users are running still Liberty/Mitaka so you need to
change something in this way of working or all the users will run away.

thank you

Saverio


On 16/03/17 16:26, Kosnik, Lubosz wrote:
> Hello Zhi,
> Just one small information. Yesterday on Octavia weekly meeting we 
> decided that we're gonna add new features to LBaaSv2 till Pike-1 so 
> the windows is very small.
> This decision was made as LBaaSv2 is currently Octavia delivery, not 
> Neutron anymore and this project is going into deprecations stage.
> 
> Cheers,
> Lubosz
> 
>> On Mar 16, 2017, at 5:39 AM, zhi 

Re: [openstack-dev] [lbaas][neutron] Is possible the lbaas commands are missing completely from openstack cli ?

[Michael Johnson]

Yes, as previously announced, we deferred development of the OpenStack
Client (OSC) until Pike.
Work has started on the OSC plugin for Octavia and we expect it to be
available in Pike.

Neutron CLI is deprecated which means it will go away in the future, but is
still available for use and is still available on the stable branches for
previous releases.

Michael


-Original Message-
From: Saverio Proto [mailto:saverio.pr...@switch.ch] 
Sent: Friday, March 17, 2017 6:21 AM
To: OpenStack Development Mailing List (not for usage questions)

Subject: [openstack-dev] [lbaas][neutron] Is possible the lbaas commands are
missing completely from openstack cli ?

Client version: openstack 3.9.0

I cant find any lbaas commands. I have to use the 'neutron' client.

Everycommand I get:
neutron CLI is deprecated and will be removed in the future. Use openstack
CLI instead.

Is LBaaS even going to be implemented in the unified openstack client ?

thank you

Saverio

--
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15,
direct +41 44 268 1573 saverio.pr...@switch.ch, http://www.switch.ch

http://www.switch.ch/stories

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


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

Re: [openstack-dev] [Neutron][LBaaS] - Best release to upgrade from LBaaS v1 to v2

[Michael Johnson]

I can confirm that the 1.0.0 release of neutron-lbaas-dashboard is working
on stable/newton.
I included my installation steps in the below linked bug.

As mentioned in the first e-mail.  The instructions say to only install one
of the two files in the enabled directory.  I suspect that is the issue you
are seeing.

Michael


-Original Message-
From: Saverio Proto [mailto:saverio.pr...@switch.ch] 
Sent: Monday, March 13, 2017 5:47 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] - Best release to upgrade from
LBaaS v1 to v2

On 10/03/17 17:49, Michael Johnson wrote:
> Yes, folks have recently deployed the dashboard with success.  I think 
> you had that discussion on the IRC channel, so I won't repeat it here.
> 
> Please note, the neutron-lbaas-dashboard does not support LBaaS v1, 
> you must have LBaaS v2 deployed for the neutron-lbaas-dashboard to 
> work.  If you are trying to use LBaaS v1, you can use the legacy 
> panels included in the older versions of horizon.
> 
[..CUT..]
> If you think there is an open bug for the dashboard, please report it 
> in https://bugs.launchpad.net/neutron-lbaas-dashboard



Hello,
I updated the bug
https://bugs.launchpad.net/neutron-lbaas-dashboard/+bug/1621403

Can anyone clarify the version matrix to use between the horizon version and
the neutron-lbaas-dashboard panels versions ?

can anyone confirm that both files
_1481_project_ng_loadbalancersv2_panel.py and file
_1480_project_loadbalancersv2_panel.py need to be installed ?

Is it okay to use branch master of neutron-lbaas-dashboard with horizon
stable/newton ?

thank you

Saverio
















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


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

Re: [openstack-dev] [Neutron][LBaaS] - Best release to upgrade from LBaaS v1 to v2

[Michael Johnson]

Hi Saverio,

I did a fresh install today with master versions of both OpenStack and the
neutron-lbaas-dashboard just to make sure the panels are working as
expected.  It went fine.

https://usercontent.irccloud-cdn.com/file/4Zgl9SB3/

To answer your version question:
Stable/mitaka neutron-lbaas-dashboard should work with stable/mitaka and
stable/newton OpenStack
Stable/ocata neutron-lbaas-dashboard works with stable/ocata OpenStack

Per the instructions in the README.rst and on PyPi, ONLY install the
_1481_project_ng_loadbalancersv2_panel.py file.  Do not install both, it
will fail.

I am not sure if you can use the master branch of neutron-lbaas-dashboard
with a newton version of horizon.  This is not a combination we test and/or
support.  It may work.
Someone from the horizon team may have more insights on that, but I think
the best answer is to get it going with the known good combinations and then
to test mixed releases.

I will now start over on stable/newton and test it out.  I will let you know
if I find a problem.

Michael


-Original Message-
From: Saverio Proto [mailto:saverio.pr...@switch.ch] 
Sent: Monday, March 13, 2017 5:47 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] - Best release to upgrade from
LBaaS v1 to v2

On 10/03/17 17:49, Michael Johnson wrote:
> Yes, folks have recently deployed the dashboard with success.  I think 
> you had that discussion on the IRC channel, so I won't repeat it here.
> 
> Please note, the neutron-lbaas-dashboard does not support LBaaS v1, 
> you must have LBaaS v2 deployed for the neutron-lbaas-dashboard to 
> work.  If you are trying to use LBaaS v1, you can use the legacy 
> panels included in the older versions of horizon.
> 
[..CUT..]
> If you think there is an open bug for the dashboard, please report it 
> in https://bugs.launchpad.net/neutron-lbaas-dashboard



Hello,
I updated the bug
https://bugs.launchpad.net/neutron-lbaas-dashboard/+bug/1621403

Can anyone clarify the version matrix to use between the horizon version and
the neutron-lbaas-dashboard panels versions ?

can anyone confirm that both files
_1481_project_ng_loadbalancersv2_panel.py and file
_1480_project_loadbalancersv2_panel.py need to be installed ?

Is it okay to use branch master of neutron-lbaas-dashboard with horizon
stable/newton ?

thank you

Saverio
















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


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

Re: [openstack-dev] [Neutron][LBaaS][heat] Removing LBaaS v1 - are weready?

[Michael Johnson]

Hi Syed,

 

To my knowledge the LBaaS team did not create any upgrade plan or tools to move 
load balancers from V1 to V2.  The data model is significantly different (and 
better) with V2 and I suspect that caused some challenges.

I know there was a, as-is, database conversion script contributed by an 
operator/packager that might help someone develop a migration path if their 
deployment wasn’t using one of the incompatible configurations, but that would 
only be one piece to the puzzle.

 

Since development beyond security fixes for v1 halted over two releases ago and 
the last of the v1 code will be removed from OpenStack in about 32 days (mitaka 
goes EOL 4/10/17) I think it is going to be left to the last few folks still 
running LBaaS v1 to plan their migrations.  Most of the LBaaS team from the 
time of v1 deprecation are no longer on the team so we don’t really have folks 
experienced with v1 available any longer.

 

I cannot speak to how hard or easy it would be to create a heat migration 
template to recreate the v1 load balancers under v2.

 

Beyond that, I can assure you that the migration from neutron-lbaas to octavia 
will have migration procedures and tools to automate the process.

 

Michael

 

From: Syed Armani [mailto:dce3...@gmail.com] 
Sent: Friday, March 10, 2017 1:58 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Neutron][LBaaS][heat] Removing LBaaS v1 - are 
weready?

 

Folks,

 

I am going to ask the question raised by Zane one more time:

 

Is there a migration plan for Heat users who have existing stacks containing 
the v1 resources?

 

Cheers,

Syed

 

On Thu, Aug 25, 2016 at 7:10 PM, Assaf Muller  > wrote:

On Thu, Aug 25, 2016 at 7:35 AM, Gary Kotton  > wrote:
> Hi,
> At the moment it is still not clear to me the upgrade process from V1 to V2. 
> The migration script https://review.openstack.org/#/c/289595/ has yet to be 
> approved. Does this support all drivers or is this just the default reference 
> implementation driver?

The migration script doesn't have a test, so we really have no idea if
it's going to work.


> Are there people still using V1?
> Thanks
> Gary
>
> On 8/25/16, 4:25 AM, "Doug Wiegley"   > wrote:
>
>
> > On Mar 23, 2016, at 4:17 PM, Doug Wiegley   > wrote:
> >
> > Migration script has been submitted, v1 is not going anywhere from 
> stable/liberty or stable/mitaka, so it’s about to disappear from master.
> >
> > I’m thinking in this order:
> >
> > - remove jenkins jobs
> > - wait for heat to remove their jenkins jobs ([heat] added to this 
> thread, so they see this coming before the job breaks)
> > - remove q-lbaas from devstack, and any references to lbaas v1 in 
> devstack-gate or infra defaults.
> > - remove v1 code from neutron-lbaas
>
> FYI, all of the above have completed, and the final removal is in the 
> merge queue: https://review.openstack.org/#/c/286381/
>
> Mitaka will be the last stable branch with lbaas v1.
>
> Thanks,
> doug
>
> >
> > Since newton is now open for commits, this process is going to get 
> started.
> >
> > Thanks,
> > doug
> >
> >
> >
> >> On Mar 8, 2016, at 11:36 AM, Eichberger, German 
>  > wrote:
> >>
> >> Yes, it’s Database only — though we changed the agent driver in the DB 
> from V1 to V2 — so if you bring up a V2 with that database it should 
> reschedule all your load balancers on the V2 agent driver.
> >>
> >> German
> >>
> >>
> >>
> >>
> >> On 3/8/16, 3:13 AM, "Samuel Bercovici"   > wrote:
> >>
> >>> So this looks like only a database migration, right?
> >>>
> >>> -Original Message-
> >>> From: Eichberger, German [mailto:german.eichber...@hpe.com 
>  ]
> >>> Sent: Tuesday, March 08, 2016 12:28 AM
> >>> To: OpenStack Development Mailing List (not for usage questions)
> >>> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are 
> weready?
> >>>
> >>> Ok, for what it’s worth we have contributed our migration script: 
> https://review.openstack.org/#/c/289595/ — please look at this as a starting 
> point and feel free to fix potential problems…
> >>>
> >>> Thanks,
> >>> German
> >>>
> >>>
> >>>
> >>>
> >>> On 3/7/16, 11:00 AM, "Samuel Bercovici"   > wrote:
> >>>
>  As far as I recall, you can specify the VIP in creating the LB so 
> you will end up with same IPs.
>