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

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

[Michael Johnson]

FYI, I took some time out this afternoon and wrote a detailed
certificate configuration guide. Hopefully this will help.

https://review.openstack.org/613454

Reviews would be welcome!

Michael
On Thu, Oct 25, 2018 at 7:00 AM Tobias Urdin  wrote:
>
> Might as well throw it out here.
>
> After a lot of troubleshooting we were able to narrow our issue down to
> our test environment running qemu virtualization, we moved our compute
> node to hardware and
> used kvm full virtualization instead.
>
> We could properly reproduce the issue where generating a CSR from a
> private key and then trying to verify the CSR would fail complaining about
> "Signature did not match the certificate request"
>
> We suspect qemu floating point emulation caused this, the same OpenSSL
> function that validates a CSR is the one used when validating the SSL
> handshake which caused our issue.
> After going through the whole stack, we have Octavia working flawlessly
> without any issues at all.
>
> Best regards
> Tobias
>
> On 10/23/2018 04:31 PM, Tobias Urdin wrote:
> > Hello Erik,
> >
> > Could you specify the DNs you used for all certificates just so that I
> > can rule it out on my side.
> > You can redact anything sensitive with some to just get the feel on how
> > it's configured.
> >
> > Best regards
> > Tobias
> >
> > On 10/22/2018 04:47 PM, Erik McCormick wrote:
> >> On Mon, Oct 22, 2018 at 4:23 AM Tobias Urdin  
> >> wrote:
> >>> Hello,
> >>>
> >>> I've been having a lot of issues with SSL certificates myself, on my
> >>> second trip now trying to get it working.
> >>>
> >>> Before I spent a lot of time walking through every line in the DevStack
> >>> plugin and fixing my config options, used the generate
> >>> script [1] and still it didn't work.
> >>>
> >>> When I got the "invalid padding" issue it was because of the DN I used
> >>> for the CA and the certificate IIRC.
> >>>
> >>>> 19:34 < tobias-urdin> 2018-09-10 19:43:15.312 15032 WARNING
> >>> octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect
> >>> to instance. Retrying.: SSLError: ("bad handshake: Error([('rsa
> >>> routines', 'RSA_padding_check_PKCS1_type_1', 'block type is not 01'),
> >>> ('rsa routines', 'RSA_EAY_PUBLIC_DECRYPT', 'padding check failed'),
> >>> ('SSL routines', 'ssl3_get_key_exchange', 'bad signature')],)",)
> >>>> 19:47 < tobias-urdin> after a quick google "The problem was that my
> >>> CA DN was the same as the certificate DN."
> >>>
> >>> IIRC I think that solved it, but then again I wouldn't remember fully
> >>> since I've been at so many different angles by now.
> >>>
> >>> Here is my IRC logs history from the #openstack-lbaas channel, perhaps
> >>> it can help you out
> >>> http://paste.openstack.org/show/732575/
> >>>
> >> Tobias, I owe you a beer. This was precisely the issue. I'm deploying
> >> Octavia with kolla-ansible. It only deploys a single CA. After hacking
> >> the templates and playbook to incorporate a separate server CA, the
> >> amphorae now load and provision the required namespace. I'm adding a
> >> kolla tag to the subject of this in hopes that someone might want to
> >> take on changing this behavior in the project. Hopefully after I get
> >> through Upstream Institute in Berlin I'll be able to do it myself if
> >> nobody else wants to do it.
> >>
> >> For certificate generation, I extracted the contents of
> >> octavia_certs_install.yml (which sets up the directory structure,
> >> openssl.cnf, and the client CA), and octavia_certs.yml (which creates
> >> the server CA and the client certificate) and mashed them into a
> >> separate playbook just for this purpose. At the end I get:
> >>
> >> ca_01.pem - Client CA Certificate
> >> ca_01.key - Client CA Key
> >> ca_server_01.pem - Server CA Certificate
> >> cakey.pem - Server CA Key
> >> client.pem - Concatenated Client Key and Certificate
> >>
> >> If it would help to have the playbook, I can stick it up on github
> >> with a huge "This is a hack" disclaimer on it.
> >>
> >>> -
> >>>
> >>> Sorry for hijacking the thread but I'm stuck as well.
> >>>
> >>> I've in the past tried to generate the certificates

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

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

[openstack-dev] [all][api] POST /api-sig/news

[Michael McCune]

Greetings OpenStack community,

This week's meeting was mostly ceremonial, with the main topic of
discussion being the office hours for the SIG. If you have not heard
the news about the API-SIG, we are converting from a regular weekly
meeting time to a set of scheduled office hours. This change was
discussed over the course of meeting leading up to the PTG and was
finalized last week. The reasoning behind this decision was summarized
nicely by edleafe in the last newsletter:

We, as a SIG, have recognized that we have moved into a new phase.
With most of the API guidelines that we needed to write having been
written, there is not "new stuff" to make demands on our time. In
recognition of this, we are changing how we will work.


How can you find the API-SIG?

We have 2 office hours that we will hold in the #openstack-sdks
channel on freenode:
* Thursdays 0900-1000 UTC
* Thursdays 1600-1700 UTC

Additionally, there is usually someone from the API-SIG hanging out in
the #openstack-sdks channel. Please feel free to ping dtanstur,
edleafe, or elmiko as direct contacts.

Although this marks the end of our weekly meetings, the API-SIG will
continue to be active in the community and we would like to extend a
hearty "huzzah!" to all the OpenStack contributors, operators, and
users who have helped to create the guidelines and guidance that we
all share.

Huzzah!

If you're interested in helping out, here are some things to get you started:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for
changes over time. If you find something that's not quite right,
submit a patch [6] to fix it.
* Have you done something for which you think guidance would have made
things easier but couldn't find any? Submit a patch and help others
[6].

# Newly Published Guidelines

* None

# API Guidelines Proposed for Freeze

* None

# Guidelines that are ready for wider review by the whole community.

* None

# Guidelines Currently Under Review [3]

* Add an api-design doc with design advice
  https://review.openstack.org/592003

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* Version and service discovery series
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet
ready for review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs
that you are developing or changing, please address your concerns in
an email to the OpenStack developer mailing list[1] with the tag
"[api]" in the subject. In your email, you should include any relevant
reviews, links, and comments to help guide the discussion of the
specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our
wiki page [4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-sig,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://storyboard.openstack.org/#!/project/1039
[6] https://git.openstack.org/cgit/openstack/api-sig


Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

__
OpenStack Development Mailing 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 
> contribution

[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

Re: [openstack-dev] [ironic] Next bug day is Tuesday August 28th! Vote for timeslot!

[Michael Turek]

Hello all,

Tomorrow's bug day will be at 15:00 UTC. Hope to see you there!

Thanks,
Mike Turek 


On 8/21/18 11:56 AM, Michael Turek wrote:

Hello,

With the next bug day coming in a week from today, I wanted to bring 
up the timeslot poll we have going again.

https://doodle.com/poll/ef4m9zmacm2ey7ce

I'd like to finalize a time slot for this on Thursday so if you want 
to cast your vote, please do it soon! Hope to see you there!


Thanks,
Mike Turek

On 8/2/18 11:24 AM, Michael Turek wrote:

Hey all!

Bug day was pretty productive today and we decided to schedule 
another one for the end of this month, on Tuesday the 28th. For 
details see the etherpad for the event [0]


Also since we're changing things up, we decided to also put up a vote 
for the timeslot [1]


If you have any questions or suggestions on how to improve bug day, I 
am all ears! Hope to see you there!


Thanks,
Mike Turek 

[0] https://etherpad.openstack.org/p/ironic-bug-day-august-28-2018
[1] https://doodle.com/poll/ef4m9zmacm2ey7ce


__ 


OpenStack Development Mailing 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] [all][api] POST /api-sig/news

[Michael McCune]

Greetings OpenStack community,

This week's meeting brings the return of the full SIG core-quartet as
all core members were in attendance. The main topics were the agenda
[7] for the upcoming Denver PTG [8], and the API-SIG still being
listed as TC working group in the governance repository reference
files. We also pushed a minor technical change related to the
reorganization of the project-config for the upcoming Python 3
transition [9]

On the topic of the PTG, there were no new items added or comments
about the current list [7]. There was brief talk about who will be
attending the gathering, but the details have not been finalized yet.

As always if you're interested in helping out, in addition to coming
to the meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for
changes over time. If you find something that's not quite right,
submit a patch [6] to fix it.
* Have you done something for which you think guidance would have made
things easier but couldn't find any? Submit a patch and help others
[6].

# Newly Published Guidelines

* None

# API Guidelines Proposed for Freeze

* None

# Guidelines that are ready for wider review by the whole community.

* None

# Guidelines Currently Under Review [3]

* Add an api-design doc with design advice
  https://review.openstack.org/592003

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* A (shrinking) suite of several documents about doing version and
service discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet
ready for review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs
that you are developing or changing, please address your concerns in
an email to the OpenStack developer mailing list[1] with the tag
"[api]" in the subject. In your email, you should include any relevant
reviews, links, and comments to help guide the discussion of the
specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our
wiki page [4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] https://etherpad.openstack.org/p/api-sig-stein-ptg
[8] https://www.openstack.org/ptg/
[9] https://review.openstack.org/#/c/593943/

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

__
OpenStack Development Mailing 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] Next bug day is Tuesday August 28th! Vote for timeslot!

[Michael Turek]

Hello,

With the next bug day coming in a week from today, I wanted to bring up 
the timeslot poll we have going again.

https://doodle.com/poll/ef4m9zmacm2ey7ce

I'd like to finalize a time slot for this on Thursday so if you want to 
cast your vote, please do it soon! Hope to see you there!


Thanks,
Mike Turek

On 8/2/18 11:24 AM, Michael Turek wrote:

Hey all!

Bug day was pretty productive today and we decided to schedule another 
one for the end of this month, on Tuesday the 28th. For details see 
the etherpad for the event [0]


Also since we're changing things up, we decided to also put up a vote 
for the timeslot [1]


If you have any questions or suggestions on how to improve bug day, I 
am all ears! Hope to see you there!


Thanks,
Mike Turek 

[0] https://etherpad.openstack.org/p/ironic-bug-day-august-28-2018
[1] https://doodle.com/poll/ef4m9zmacm2ey7ce


__ 


OpenStack Development Mailing 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] How to debug no valid host failures with placement

[Michael Glasgow]

On 8/2/2018 7:27 PM, Jay Pipes wrote:
It's not an exception. It's normal course of events. NoValidHosts means 
there were no compute nodes that met the requested resource amounts.


To clarify, I didn't mean a python exception.  I concede that I 
should've chosen a better word for the type of object I have in mind.


If a SELECT statement against an Oracle DB returns 0 rows, is that an 
exception? No. Would an operator need to re-send the SELECT statement 
with an EXPLAIN SELECT in order to get information about what indexes 
were used to winnow the result set (to zero)? Yes. Either that, or the 
operator would need to gradually re-execute smaller SELECT statements 
containing fewer filters in order to determine which join or predicate 
caused a result set to contain zero rows.


I'm not sure if this analogy fully appreciates the perspective of the 
operator.  You're correct of course that if you select on a db and the 
correct answer is zero rows, then zero rows is the right answer, 100% of 
the time.


Whereas what I thought we meant when we talk about "debugging no valid 
host failures" is that zero rows is *not* the right answer, and yet 
you're getting zero rows anyway.  So yes, absolutely with an Oracle DB 
you would get an ORA-X exception in that case, along with a trace 
file that told you where things went off the rails.  Which is exactly 
what we don't have here.


If I understand your perspective correctly, it's basically that 
placement is working as designed, so there's nothing more to do except 
pore over debug output.  Can we consider:


 (1) that might not always be true if there are bugs

 (2) even when it is technically true, from the user's perspective, I'd 
posit that it's rare that a user requests an instance with the express 
intent of not launching an instance. (?)  If they're "debugging" this 
issue, it means there's a misconfiguration or some unexpected state that 
they have to go find.  So it is exceptional in that sense, and either 
the operator or the user is going to need to know why the request failed 
in a large majority of these cases.


I would love to hear from any large operators on the list whether they 
feel that "turn on debug and try again" is really acceptable here.  I'm 
not trying to be critical; I'm just convinced that once the cluster is 
of a certain size, that approach can start to become very expensive.


--
Michael Glasgow

__
OpenStack Development Mailing 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] How to debug no valid host failures with placement

[Michael Glasgow]

On 08/02/18 15:04, Chris Friesen wrote:

On 08/02/2018 01:04 PM, melanie witt wrote:


The problem is an infamous one, which is, your users are trying to boot
instances and they get "No Valid Host" and an instance in ERROR state. 
They contact support, and now support is trying to determine why 
NoValidHost happened. In the past, they would turn on DEBUG log level 
on the nova-scheduler, try another request, and take a look at the 
scheduler logs.


At a previous Summit[1] there were some operators that said they just 
always ran nova-scheduler with debug logging enabled in order to deal 
with this issue, but that it was a pain [...]


I would go a bit further and say it's likely to be unacceptable on a 
large cluster.  It's expensive to deal with all those logs and to 
manually comb through them for troubleshooting this issue type, which 
can happen frequently with some setups.  Secondarily there are 
performance and security concerns with leaving debug on all the time.


As to "defining the problem", I think it's what Melanie said.  It's 
about asking for X and the system saying, "sorry, can't give you X" with 
no further detail or even means of discovering it.


More generally, any time a service fails to deliver a resource which it 
is primarily designed to deliver, it seems to me at this stage that 
should probably be taken a bit more seriously than just "check the log 
file, maybe there's something in there?"  From the user's perspective, 
if nova fails to produce an instance, or cinder fails to produce a 
volume, or neutron fails to build a subnet, that's kind of a big deal, 
right?


In such cases, would it be possible to generate a detailed exception 
object which contains all the necessary info to ascertain why that 
specific failure occurred?  Ideally the operator should be able to 
correlate those exceptions with associated objects, e.g. the instance in 
ERROR state in this case, so that given that failed instance ID they can 
quickly remedy the user's problem without reading megabytes of log 
files.  If there's a way to make this error handling generic across 
services to some extent, that seems like it would be great for operators.


Such a framework might eventually hook into internal ticketing systems, 
maintenance reporting, or provide a starting point for self healing 
mechanisms, but initially the aim would just be to provide the operator 
with the bare minimum info necessary for more efficient break-fix.


It could be a big investment, but it also doesn't seem like "optional" 
functionality from a large operator's perspective.  "Enable debug and 
try again" is just not good enough IMHO.


--
Michael Glasgow

__
OpenStack Development Mailing 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][api] POST /api-sig/news

[Michael McCune]

Greetings OpenStack community,

Today's meeting was primarily focused around two topics: the IETF[7]
draft proposal for Best Practices when building HTTP protocols[8], and
the upcoming OpenStack Project Teams Gathering (PTG)[9].

The group had taken a collective action to read the aforementioned
draft[8], and as such we were well prepared to discuss its nuances.
For the most part, we agreed that the draft is a good prepartory text
when approaching HTTP APIs and that we should provide a link to it
from the guidelines. Although there are a few areas that we identified
as points of discussion regarding the text of the draft, on balance it
was seen as helpful to the OpenStack community and consistent with our
established guidelines.

On the topic of the PTG, the group has started planning for the event
and is in the early stages gathering content. We will soon have an
etherpad available for topic collection and as an added bonus mordred
himself made a pronouncement about the API-SIG meeting being a
priority in his schedule for this PTG. We hope to see you all there!

The OpenStack infra team will be doing the final rename from API-WG to
API-SIG this Friday. Although there are not expected to be any issues
from this rename, we will be updating documentation references, and
appreciate any help in chasing down bugs.

There were no new guidelines to discuss, nor bugs that have arisen
since last week.

As always if you're interested in helping out, in addition to coming
to the meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for
changes over time. If you find something that's not quite right,
submit a patch [6] to fix it.
* Have you done something for which you think guidance would have made
things easier but couldn't find any? Submit a patch and help others
[6].

# Newly Published Guidelines

* None

# API Guidelines Proposed for Freeze

* None

# Guidelines that are ready for wider review by the whole community.

* None

# Guidelines Currently Under Review [3]

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* A (shrinking) suite of several documents about doing version and
service discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet
ready for review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs
that you are developing or changing, please address your concerns in
an email to the OpenStack developer mailing list[1] with the tag
"[api]" in the subject. In your email, you should include any relevant
reviews, links, and comments to help guide the discussion of the
specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our
wiki page [4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] https://ietf.org/
[8] https://tools.ietf.org/html/draft-ietf-httpbis-bcp56bis-06
[9] https://www.openstack.org/ptg/

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

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

[openstack-dev] [ironic] Next bug day is Tuesday August 28th! Vote for timeslot!

[Michael Turek]

Hey all!

Bug day was pretty productive today and we decided to schedule another 
one for the end of this month, on Tuesday the 28th. For details see the 
etherpad for the event [0]


Also since we're changing things up, we decided to also put up a vote 
for the timeslot [1]


If you have any questions or suggestions on how to improve bug day, I am 
all ears! Hope to see you there!


Thanks,
Mike Turek 

[0] https://etherpad.openstack.org/p/ironic-bug-day-august-28-2018
[1] https://doodle.com/poll/ef4m9zmacm2ey7ce


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

[openstack-dev] [ironic] August bug day tomorrow! (August 2nd 13:00 UTC to 14:00 UTC)

[Michael Turek]

Hey all,

Welcome to August! Tomorrow is the first Thursday of the month so bug 
day is once again upon us. For details please see the etherpad [0].


If you have ideas for how we can improve Bug Day, or how the agenda 
should be structured, let me know! I hope to see you there tomorrow


Thanks,
Mike Turek 

[0] https://etherpad.openstack.org/p/ironic-bug-day-august-2018


__
OpenStack Development Mailing 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

[openstack-dev] [ironic] [FFE] Teach ironic about ppc64le boot requirements

[Michael Turek]

I would like to request a FFE for this RFE 
https://storyboard.openstack.org/#!/story/1749057


The implementation should be complete and is currently passing CI, but 
does need more reviews. I'd also like to test this locally ideally.


pros
---
- Improves ppc64le support

cons
---
- Bumps ironic-lib version for both IPA and Ironic

risk
---
- There are other deployment methods for ppc64le, including wholedisk 
and netboot. However, this feature is desired to improve parity between 
x86 and ppc64le for tripleo. The feature should not affect any current 
working deployment methods, but please review closely.


Please let me know if you'd like more detail on this or have any 
questions! Thanks!


-Mike  Turek


__
OpenStack Development Mailing 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

[openstack-dev] [all][api] POST /api-sig/news

[Michael McCune]

Greetings OpenStack community,

Today's meeting was very brief as both cdent and dtantsur were out.
There were no major items of discussion, but we did acknowledge the
efforts of the GraphQL proof of concept work[7] being led by Gilles
Dubreuil. This work continues to make progress and should provide an
interesting data point for the possibiity of future GraphQL usages.

In addition to the light discussion there was also one guideline
update that was merged this week, and a small infrastructure-related
patch that was merged.

As always if you're interested in helping out, in addition to coming
to the meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for
changes over time. If you find something that's not quite right,
submit a patch [6] to fix it.
* Have you done something for which you think guidance would have made
things easier but couldn't find any? Submit a patch and help others
[6].

# Newly Published Guidelines

* Expand error code document to expect clarity
  https://review.openstack.org/#/c/577118/

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None

# Guidelines Currently Under Review [3]

* Add links to errors-example.json
  https://review.openstack.org/#/c/578369/

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* A (shrinking) suite of several documents about doing version and
service discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet
ready for review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs
that you are developing or changing, please address your concerns in
an email to the OpenStack developer mailing list[1] with the tag
"[api]" in the subject. In your email, you should include any relevant
reviews, links, and comments to help guide the discussion of the
specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our
wiki page [4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] https://storyboard.openstack.org/#!/story/2002782


Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

__
OpenStack Development Mailing 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] Ironic Bug Day July 12 2018 1:00 - 2:00 PM UTC

[Michael Turek]

Hey all,

This month's bug day went pretty well! We discussed about 20 bugs (half 
old, half new). Many were triaged, some got marked invalid. For meeting 
minutes and details, see the etherpad [0].


The attendance was a bit low (Thank you for attending Julia and Adam!), 
but could be due to vacations that started last week ending. Either way, 
we decided to confirm the bug day for next month to give ample notice 
and hopefully improve attendance. I'd also like to encourage people to 
bring a bug with them that they consider interesting, overlooked, or 
important next time.


Next bug day will be August 2nd @ 13:00 - 14:00 UTC. Etherpad can be 
found here https://etherpad.openstack.org/p/ironic-bug-day-august-2018


If you have any questions or have any ideas to improve bug day, please 
don't hesitate to reach out to me! Hope to see you there!


Thanks!
Mike Turek 

[0] https://etherpad.openstack.org/p/ironic-bug-day-july-2018


On 7/10/18 4:31 PM, Michael Turek wrote:

Hey all,

This month's bug day was delayed a week and will take place on 
Thursday the 12th from 1:00 UTC to 2:00 UTC


For location, time, and agenda details please see 
https://etherpad.openstack.org/p/ironic-bug-day-july-2018


If you would like to propose topics, feel free to do it in the etherpad!

Thanks,
Mike Turek 




__
OpenStack Development Mailing 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

[openstack-dev] [ironic] Ironic Bug Day July 12 2018 1:00 - 2:00 PM UTC

[Michael Turek]

Hey all,

This month's bug day was delayed a week and will take place on Thursday 
the 12th from 1:00 UTC to 2:00 UTC


For location, time, and agenda details please see 
https://etherpad.openstack.org/p/ironic-bug-day-july-2018


If you would like to propose topics, feel free to do it in the etherpad!

Thanks,
Mike Turek 


__
OpenStack Development Mailing 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

[openstack-dev] [all][api] POST /api-sig/news

[Michael McCune]

Greetings OpenStack community,

Today's meeting covered a few topics, but was mainly focused on a few
updates to the errors guideline.

We began with a review of last week's actions. Ed Leafe has sent an
email[7] to mailing list to let the folks working on the GraphQL
experiments know that the API-SIG StoryBoard was available for them to
use to track their progress.

We mentioned the proposed time slot[7] for the API-SIG at the upcoming
PTG, but as we are still a few months out from that event no other
actions were proposed.

Next we moved into a discussion of two guideline updates[8][9] that
Chris Dent is proposing. The first review adds concrete examples for
the error responses described in the guideline, and the second adds
some clarifying language and background on the intent of error codes.
During discussion among the group, a few minor areas of improvement
were identified and recorded on the reviews with updates to be made by
Chris.

We discussed the transition to StoryBoard[10] during our bug
discussion, noting the places where the workflow differs from
Launchpad. Chris also showed us a Board[11] that he created to help
figure out how to best use this new tool.

As always if you're interested in helping out, in addition to coming
to the meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for
changes over time. If you find something that's not quite right,
submit a patch [6] to fix it.
* Have you done something for which you think guidance would have made
things easier but couldn't find any? Submit a patch and help others
[6].

# Newly Published Guidelines

None

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None

# Guidelines Currently Under Review [3]

* Add links to errors-example.json
  https://review.openstack.org/#/c/578369/

* Expand error code document to expect clarity
  https://review.openstack.org/#/c/577118/

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* A (shrinking) suite of several documents about doing version and
service discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet
ready for review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs
that you are developing or changing, please address your concerns in
an email to the OpenStack developer mailing list[1] with the tag
"[api]" in the subject. In your email, you should include any relevant
reviews, links, and comments to help guide the discussion of the
specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our
wiki page [4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131881.html
[8] https://review.openstack.org/#/c/578369/
[9] https://review.openstack.org/#/c/577118/
[10] https://storyboard.openstack.org/#!/project/1039
[11] https://storyboard.openstack.org/#!/board/91

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

__
OpenStack Development Mailing 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] Adding hostId to metadata

[Michael Glasgow]

On 06/27/18 11:20, Matt Riedemann wrote:
To be clear, this is exposing the exact same hashed host+project_id 
value via the metadata API that you can already get, as a non-admin 
user, from the compute REST API:


https://github.com/openstack/nova/blob/c8b93fa2493dce82ef4c0b1e7a503ba9b81c2e86/nova/api/openstack/compute/views/servers.py#L135 


So I don't think it's a security issue at all.


I'm not sure I understand this rationale.  Strictly speaking, I would 
think that in order for this to be true, the set of authenticated 
control plane users would have to always include the set of users who 
can read the metadata from a guest.  Which I'm pretty sure is not true 
in the general case.


Am I missing something?

--
Michael Glasgow

__
OpenStack Development Mailing 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] Adding hostId to metadata

[Michael Still]

We only bump the version if something has changed IIRC. I think bumping
when nothing has changed would create a burden for implementers of client
software. So its not like you get a chance to sneak this in "for free".

Does this information really need to be available in the host OS? Its
trivial to look it up via our existing APIs outside the host, although
possibly less trivial if the instance has already been deleted.

Michael

On Tue, Jun 26, 2018 at 7:30 AM Mohammed Naser  wrote:

> Hi everyone:
>
> While working with the OpenStack infrastructure team, we noticed that
> we were having some intermittent issues where we wanted to identify a
> theory if all VMs with this issue were landing on the same hypervisor.
>
> However, there seems to be no way of directly accessing `hostId` from
> inside the virtual machine (such as using the metadata API).  This is
> a very useful thing to expose over the metadata API as not only would
> it help for troubleshooting these types of scenarios however it would
> also help software that can manage anti-affinity simply by checking
> the API and taking scheduling decisions.
>
> I've proposed the following patch to add this[1], however, this is
> technically an API change, and the blueprints document specifies that
> "API changes always require a design discussion."
>
> Also, I believe that we're in a state where getting a spec would
> require an exception.  However, this is a very trivial change.  Also,
> according to the notes in the metadata file, it looks like there is
> one "bump" per OpenStack release[3] which means that this change can
> just be part of that release-wide version bump of the OpenStack API.
>
> Can we include this trivial patch in the upcoming Rocky release?
>
> Thanks,
> Mohammed
>
> [1]: https://review.openstack.org/577933
> [2]: https://docs.openstack.org/nova/latest/contributor/blueprints.html
> [3]:
> http://git.openstack.org/cgit/openstack/nova/tree/nova/api/metadata/base.py#n60
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
Did this email leave you hoping to cause me pain? Good news!
Sponsor me in city2surf 2018 and I promise to suffer greatly.
http://www.madebymikal.com/city2surf-2018/
__
OpenStack Development Mailing 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][api] POST /api-sig/news

[Michael McCune]

Greetings OpenStack community,

Today's meeting was on the shorter side but covered several topics. We
discussed the migration to StoryBoard, and noted that we need to send
word to Gilles and the GraphQL experimentors that the board is in
place and ready for their usage. The GraphQL work was also highlighted
as there has been a review[7] posted along with an update[8] to the
mailing list. This work is in its early stages, but significant
progress has already been made. Kudos to Gilles and the neutron team!

We talked briefly about the upcoming PTG and which days might be
available for the SIG, but it is too early for such speculation and
the group has tabled the idea for now.

The API-SIG StoryBoard is now live[9], although it still has the old
"api-wg" name. That will be updated when the infra team does the
project rename for us. We encourage all new activity to take place
here and we are in the process of cleaning up the older links; stay
tuned for more information.

There is one new guideline change that is just starting its life in
the review process[10]. This is an addition to the guideline on errors
and although this review is still in the early stages of development
any comments are greatly appreciated.

As always if you're interested in helping out, in addition to coming
to the meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for
changes over time. If you find something that's not quite right,
submit a patch [6] to fix it.
* Have you done something for which you think guidance would have made
things easier but couldn't find any? Submit a patch and help others
[6].

# Newly Published Guidelines

None

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None

# Guidelines Currently Under Review [3]

* Expand error code document to expect clarity
  https://review.openstack.org/#/c/577118/

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* A (shrinking) suite of several documents about doing version and
service discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet
ready for review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs
that you are developing or changing, please address your concerns in
an email to the OpenStack developer mailing list[1] with the tag
"[api]" in the subject. In your email, you should include any relevant
reviews, links, and comments to help guide the discussion of the
specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our
wiki page [4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] https://review.openstack.org/575120
[8] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131557.html
[9] https://storyboard.openstack.org/#!/project/1039
[10] https://review.openstack.org/#/c/577118/

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

__
OpenStack Development Mailing 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 

[openstack-dev] [all][api] POST /api-sig/news

[Michael McCune]

Greetings OpenStack community,

Today's meeting was brief, covering only 1 major topic.

The main topic for the SIG today was the migration of bug tracking
from Launchpad to StoryBoard[7]. No firm plans were made to migrate
yet, but the group agreed that this migration would be positive from a
community alignment perspective and that the number of bugs in
conjunction with a low rate of bug addition would make the migration
less risky. There was no opposition to the migration, but it was noted
that the shift from Launchpad to StoryBoard does represent a paradigm
shift and that there is not a 1:1 equivalency between the two. Expect
the SIG to continue researching the migration and put forth a plan to
shift at some point in the future.

Although not a full discussion topic, Chris Dent reinforced the SIG's
commitment to attending the forthcoming writeup about micrversion bump
plans by mordred.

There being no recent changes to pending guidelines nor to bugs, we
ended the meeting early.

As always if you're interested in helping out, in addition to coming
to the meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for
changes over time. If you find something that's not quite right,
submit a patch [6] to fix it.
* Have you done something for which you think guidance would have made
things easier but couldn't find any? Submit a patch and help others
[6].

# Newly Published Guidelines

None

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None

# Guidelines Currently Under Review [3]

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* A (shrinking) suite of several documents about doing version and
service discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet
ready for review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs
that you are developing or changing, please address your concerns in
an email to the OpenStack developer mailing list[1] with the tag
"[api]" in the subject. In your email, you should include any relevant
reviews, links, and comments to help guide the discussion of the
specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our
wiki page [4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] https://storyboard.openstack.org/#!/page/about

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

__
OpenStack Development Mailing 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] 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

[openstack-dev] [ironic] Bug Day June 7th @ 1:00 PM to 2:00 PM UTC

[Michael Turek]

Hey all,

The first Thursday of the month is approaching which means it's time for 
a bug day yet again!


As we discussed last time, we will shorten the call to an hour. Below is 
a proposed agenda, location, and time [0]. If you'd like to adjust or 
propose topics, please let me know.


Thanks!
Mike Turek 

[0] https://etherpad.openstack.org/p/ironic-bug-day-june-2018


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

[openstack-dev] [keystone] [tripleo] multi-region Keystone via stretched Galera cluster

[Michael Bayer]

Hey list -

as mentioned in the May 11 Keystone meeting, I am working on one of
the canonical approaches to producing a multi-region Keystone service,
which is by having overcloud-specific keystone services interact with
a Galera database that is running masters across multiple overclouds.
  The work here is to be integrated into tripleo and at [1] we discuss
the production of a multi-region Keystone service, deployable across
multiple tripleo overclouds.

As the spec is being discussed I continue to work on the proof of
concept [2] which in its master branch is being developed to deploy
the second galera DB as well as haproxy/vip/keystone completely from
tripleo heat templates; the changes being patched here are to be
proposed as changes to tripleo itself once this version of the POC is
working.

The "standard_tripleo_version" branch is the previous iteration, which
provides a fully working proof of concept that adds a second Galera
instance to a pair of already deployed overclouds.

Comments on the review welcome.

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

[2] https://github.com/zzzeek/stretch_cluster

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

[openstack-dev] [api] notes from api-sig forum meeting on graphql experiment

[Michael McCune]

hi everybody,

i have added my notes to the etherpad[1] from summit.

briefly, we had a great meeting about creating a graphql experiment in
openstack and i tried to capture some of the questions and comments
that flew back and forth.

there seems to be a good consensus that a proof of concept will be
created on the neutron server, most likely in an experimental feature
branch. Gilles Dubreuil has volunteered to lead this effort (thank you
Gilles!), hopefully with some help from a few neutron savy folks ;)

it is still very early in this experiment, but i think there was a
good feeling that if this works it could create some great
opportunities for improvement across the openstack ecosystem. i really
hope it does!

peace o/


[1]: https://etherpad.openstack.org/p/YVR18-API-SIG-forum

__
OpenStack Development Mailing 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] [StarlingX] StarlingX code followup discussions

[Michael Still]

I think a good start would be a concrete list of the places you felt you
needed to change upstream and the specific reasons for each that it wasn't
done as part of the community.

For example, I look at your nova fork and it has a "don't allow this call
during an upgrade" decorator on many API calls. Why wasn't that done
upstream? It doesn't seem overly controversial, so it would be useful to
understand the reasoning for that change.

To be blunt I had a quick scan of the Nova fork and I don't see much of
interest there, but its hard to tell given how things are laid out now.
Hence the request for a list.

Michael




On Thu, May 24, 2018 at 6:36 AM, Dean Troyer <dtro...@gmail.com> wrote:

> On Wed, May 23, 2018 at 2:20 PM, Brian Haley <haleyb@gmail.com> wrote:
> > Even doing that is work - going through changes, finding nuggets,
> proposing
> > new specs I don't think we can expect a project to even go there, it
> has
> > to be driven by someone already involved in StarlingX, IMHO.
>
> In the beginning at least it will be.  We have prioritized lists for
> where we want to start.  Once I get the list and commits cleaned up
> everyone can look at them and weigh in on our starting point.
>
> dt
>
> --
>
> Dean Troyer
> dtro...@gmail.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Did this email leave you hoping to cause me pain? Good news!
Sponsor me in city2surf 2018 and I promise to suffer greatly.
http://www.madebymikal.com/city2surf-2018/
__
OpenStack Development Mailing 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 <openst...@roodsari.us> 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_RELEA

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 <openst...@roodsari.us> 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

[openstack-dev] [all][api] POST /api-sig/news

[Michael McCune]

Greetings OpenStack community,

Today's meeting was brief, primarily focused on planning for the
summit sessions[7][8] that the SIG will host and facilitate.

The first session[7], will be a Birds of a Feather (BoF) gathering
where the topics will be determined by the attendees. One topic that
will surely make that list is the GraphQL proof of concept for Neutron
that has been discussed on the mailing list[9].

The second session[8], will be a directed discussion addressing
technical debt in the REST APIs of OpenStack.  We're now at the point
where people would like to start removing old code. This session will
give interested parties details about how they can leverage
microversions and the guidelines of the SIG to reduce their debt, drop
old functionality, and improve the consistency of their APIs. It will
also clarify what it means when we bump the minimum microversion for a
service in the future and discuss plans for creating an OpenStack
community goal.

For both sessions, the SIG has aligned itself towards helping
coordinate discussions, clear up misunderstandings, and generally be
helpful in ensuring that all voices are heard and cross-cutting
concerns are addressed. If you are heading to summit, we hope to see
you there!

There being no recent changes to pending guidelines nor to bugs, we
ended the meeting early.

As always if you're interested in helping out, in addition to coming
to the meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for
changes over time. If you find something that's not quite right,
submit a patch [6] to fix it.
* Have you done something for which you think guidance would have made
things easier but couldn't find any? Submit a patch and help others
[6].

# Newly Published Guidelines

None

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None

# Guidelines Currently Under Review [3]

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* A (shrinking) suite of several documents about doing version and
service discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet
ready for review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs
that you are developing or changing, please address your concerns in
an email to the OpenStack developer mailing list[1] with the tag
"[api]" in the subject. In your email, you should include any relevant
reviews, links, and comments to help guide the discussion of the
specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our
wiki page [4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21798/api-special-interest-group-session
[8] 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21881/api-debt-cleanup
[9] http://lists.openstack.org/pipermail/openstack-dev/2018-May/130219.html

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

__
OpenStack Development Mailing 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
<prometheanf...@gentoo.org> 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

[openstack-dev] [All] A worked example of adding privsep to an OpenStack project

[Michael Still]

Hi,

further to last week's example of how to add a new privsep'ed call in Nova,
I thought I'd write up how to add privsep to a new OpenStack project. I've
used Cinder in this worked example, but it really applies to any project
which wants to do things with escalated permissions.

The write up is here --
http://www.madebymikal.com/adding-oslo-privsep-to-a-new-project-a-worked-example/

Michael

-- 
Did this email leave you hoping to cause me pain? Good news!
Sponsor me in city2surf 2018 and I promise to suffer greatly.
http://www.madebymikal.com/city2surf-2018/
__
OpenStack Development Mailing 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

[openstack-dev] [nova] A short guide to adding privsep'ed methods in Nova

[Michael Still]

I was asked yesterday for a guide on how to write new escalated methods
with oslo privsep, so I wrote up a blog post about it this morning. It
might be useful to others here.

http://www.madebymikal.com/how-to-make-a-privileged-call-with-oslo-privsep/

I intend to write up how to add privsep to a new project as well, but I'll
do that separately later.

Michael

-- 
Did this email leave you hoping to cause me pain? Good news!
Sponsor me in city2surf 2018 and I promise to suffer greatly.
http://www.madebymikal.com/city2surf-2018/
__
OpenStack Development Mailing 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] Monthly bug day?

[Michael Turek]

Thanks Dmitry!

We'll be meeting on Dmitry's bluejeans line very soon. Hope to see 
everyone there!


-Mike 


On 4/30/18 12:00 PM, Dmitry Tantsur wrote:
I've created a bluejeans channel for this meeting: 
https://bluejeans.com/309964257. I may be late for it, but I've set it 
up to be usable even without me.


On 04/30/2018 02:39 PM, Michael Turek wrote:
Just tried this and seems like Firefox does still require a browser 
plugin.


Julia, could we use your bluejeans line again?

Thanks!
Mike Turek 


On 4/30/18 7:33 AM, Dmitry Tantsur wrote:

Hi,

On 04/29/2018 10:17 PM, Michael Turek wrote:
Awesome! If everyone doesn't mind the short notice, we'll have it 
again this Thursday @ 1:00 PM to 3:00 PM UTC.


++



I can provide video conferencing through hangouts here 
https://goo.gl/xSKBS4

Let's give that a shot this time!


Note that the last time I checked Hangouts video messaging required 
a proprietary browser plugin (and hence did not work in Firefox). 
Using it may exclude people not accepting proprietary software 
and/or avoiding using Chromium.




We can adjust times, tooling, and regular agenda over the next 
couple meetings and see where we settle. If anyone has any 
questions or suggestions, don't hesitate to reach out to me!


Thanks,
Mike Turek 


On 4/25/18 12:11 PM, Julia Kreger wrote:

On Mon, Apr 23, 2018 at 12:04 PM, Michael Turek
<mjtu...@linux.vnet.ibm.com> wrote:

What does everyone think about having Bug Day the first Thursday 
of every

month?

All for it!

__ 


OpenStack Development Mailing 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] [ironic] Monthly bug day?

[Michael Turek]

Just tried this and seems like Firefox does still require a browser plugin.

Julia, could we use your bluejeans line again?

Thanks!
Mike Turek 


On 4/30/18 7:33 AM, Dmitry Tantsur wrote:

Hi,

On 04/29/2018 10:17 PM, Michael Turek wrote:
Awesome! If everyone doesn't mind the short notice, we'll have it 
again this Thursday @ 1:00 PM to 3:00 PM UTC.


++



I can provide video conferencing through hangouts here 
https://goo.gl/xSKBS4

Let's give that a shot this time!


Note that the last time I checked Hangouts video messaging required a 
proprietary browser plugin (and hence did not work in Firefox). Using 
it may exclude people not accepting proprietary software and/or 
avoiding using Chromium.




We can adjust times, tooling, and regular agenda over the next couple 
meetings and see where we settle. If anyone has any questions or 
suggestions, don't hesitate to reach out to me!


Thanks,
Mike Turek 


On 4/25/18 12:11 PM, Julia Kreger wrote:

On Mon, Apr 23, 2018 at 12:04 PM, Michael Turek
<mjtu...@linux.vnet.ibm.com> wrote:

What does everyone think about having Bug Day the first Thursday of 
every

month?

All for it!

__ 


OpenStack Development Mailing 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] [ironic] Monthly bug day?

[Michael Turek]

Awesome! If everyone doesn't mind the short notice, we'll have it again 
this Thursday @ 1:00 PM to 3:00 PM UTC.


I can provide video conferencing through hangouts here https://goo.gl/xSKBS4
Let's give that a shot this time!

We can adjust times, tooling, and regular agenda over the next couple 
meetings and see where we settle. If anyone has any questions or 
suggestions, don't hesitate to reach out to me!


Thanks,
Mike Turek 


On 4/25/18 12:11 PM, Julia Kreger wrote:

On Mon, Apr 23, 2018 at 12:04 PM, Michael Turek
<mjtu...@linux.vnet.ibm.com> wrote:


What does everyone think about having Bug Day the first Thursday of every
month?

All for it!

__
OpenStack Development Mailing 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] [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
<artem.goncha...@gmail.com> 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,  <mihaela.ba...@orange.com> 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 

[openstack-dev] [all][api] POST /api-sig/news

[Michael McCune]

Greetings OpenStack community,

Today's meeting was quite short and saw a review of everyone's status
and the merging of one guideline.

We began by sharing our current work and plans for the near future.
Although everyone is on tight schedules currently, we discussed the
next steps for the work on the OpenAPI proposal [7] and elmiko has
mentioned that he will return to updating the microversion patch [8]
in the near future.

Next was our standard business of reviewing the frozen and open
guidelines. The guideline on cache-control headers, which had been
frozen last week, received no negative responses from the community,
so it was merged. You can find the link to the merged guideline in the
section below.

As we reviewed our bug status, the group agreed that at some point in
the near future we should take another pass at triaging our bugs. This
work will take place after the upcoming Vancouver forum.

As always if you're interested in helping out, in addition to coming
to the meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for
changes over time. If you find something that's not quite right,
submit a patch [6] to fix it.
* Have you done something for which you think guidance would have made
things easier but couldn't find any? Submit a patch and help others
[6].

# Newly Published Guidelines

* Add guidance on needing cache-control headers
  https://review.openstack.org/550468

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None

# Guidelines Currently Under Review [3]

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* A (shrinking) suite of several documents about doing version and
service discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet
ready for review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs
that you are developing or changing, please address your concerns in
an email to the OpenStack developer mailing list[1] with the tag
"[api]" in the subject. In your email, you should include any relevant
reviews, links, and comments to help guide the discussion of the
specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our
wiki page [4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] https://gist.github.com/elmiko/7d97fef591887aa0c594c3dafad83442
[8] https://review.openstack.org/#/c/444892/

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

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

[openstack-dev] [ironic] Monthly bug day?

[Michael Turek]

Hey everyone!

We had a bug day about two weeks ago and it went pretty well! At last 
week's IRC meeting the idea of having one every month was thrown around.


What does everyone think about having Bug Day the first Thursday of 
every month?


Thanks,
Mike Turek


__
OpenStack Development Mailing 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] z/VM introducing a new config driveformat

[Michael Still]

I'm confused about the design of AE to be honest. Is there a good reason
that this functionality couldn't be provided by cloud-init? I think there's
a lot of cost in deviating from the industry standard, so the reasons to do
so have to be really solid.

I'm also a bit confused by what seems to be support for streaming
configuration. Is there any documentation on the design of AE anywhere?

Thanks,
Michael

On Tue, Apr 17, 2018 at 6:58 PM, Chen CH Ji <jiche...@cn.ibm.com> wrote:

> For the question on AE documentation, it's open source in [1] and the
> documentation for how to build and use is [2]
> once our code is upstream, there are a set of documentation change which
> will cover this image build process by
> adding some links to there [3]
>
> You are right, we need image to have our Active Engine, I think different
> arch and platform might have their unique
> requirements and our solution our Active Engine is very like to cloud-init
> so no harm to add it from user's perspective
> I think later we can upload image to some place so anyone is able to
> consume it as test image if they like
> because different arch's image (e.g x86 and s390x) can't be shared anyway.
>
> For the config drive format you mentioned, actually, as previous
> explanation and discussion witho Michael and Dan,
> We found the iso9660 can be used (previously we made a bad assumption) and
> we already changed the patch in [4],
> so it's exactly same to other virt drivers you mentioned , we don't need
> special format and iso9660 works perfect for our driver
>
> It make sense to me we are temply moved out from runway, I suppose we can
> adjust the CI to enable the run_ssh = true
> with config drive functionalities very soon and we will apply for review
> after that with the test result requested in our CI log.
>
> Thanks
>
> [1] https://github.com/mfcloud/python-zvm-sdk/blob/master/
> tools/share/zvmguestconfigure
> [2] http://cloudlib4zvm.readthedocs.io/en/latest/
> makeimage.html#configuration-of-activation-engine-ae-in-zlinux
> [3] https://review.openstack.org/#/q/status:open+project:
> openstack/nova+branch:master+topic:bp/add-zvm-driver-rocky
> [4] https://review.openstack.org/#/c/527658/33/nova/virt/zvm/utils.py
> line 104
>
> Best Regards!
>
> Kevin (Chen) Ji 纪 晨
>
> Engineer, zVM Development, CSTL
> Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
> Phone: +86-10-82451493
> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
> Beijing 100193, PRC
>
> [image: Inactive hide details for melanie witt ---04/17/2018 09:21:03
> AM---On Mon, 16 Apr 2018 14:56:06 +0800, Chen Ch Ji wrote: > >>>]melanie
> witt ---04/17/2018 09:21:03 AM---On Mon, 16 Apr 2018 14:56:06 +0800, Chen
> Ch Ji wrote: > >>>The "iso file" will not be inside the gu
>
> From: melanie witt <melwi...@gmail.com>
> To: openstack-dev@lists.openstack.org
> Date: 04/17/2018 09:21 AM
> Subject: Re: [openstack-dev] [Nova] z/VM introducing a new config
> driveformat
> --
>
>
>
> On Mon, 16 Apr 2018 14:56:06 +0800, Chen Ch Ji wrote:
> >  >>>The "iso file" will not be inside the guest, but rather passed to
> > the guest as a block device, right?
> > Cloud init expects to find a config drive with following requirements
> > [1], in order to make cloud init able to consume config drive , we
> > should be able to prepare it,
> > in some hypervisor, you can define something like following to the VM
> > then VM startup is able to consume it
> > 
> > but for z/VM case it allows disk to be created during VM create (define
> > )stage but no disk format set, it's the operating system's
> > responsibility to define the purpose of the
> > disk, so what we do is
> > 1) first when we build image ,we create a small AE like cloud-init but
> > only purpose is to get files from z/VM internal pipe and handle config
> > drive case
>
> What does AE stand for? So, this means in order to use the z/VM driver,
> users must have special images that will ensure the config drive will be
> readable by cloud-init. They can't use standard cloud images.
>
> > 2) During spawn we create config drive in nova-compute side then send
> > the file to z/VM through z/VM internal pipe (omit detail here)
> > 3) During startup of the virtual machine, the small AE is able to mount
> > the file as loop device and then in turn cloud-init is able to handle it
> >
> > because this is our special case, we don't want to upload to cloud-init
> > community because of uniqueness and as far as we can tell, no hook in
> > cloud-init mechanism allowed as well
> > 

Re: [openstack-dev] [Nova][Deployers] Optional, platform specific, dependancies in requirements.txt

[Michael Still]

I don't understand why you think the alternative is so hard. Here's how
ironic does it:

global ironic

if ironic is None:

ironic = importutils.import_module('ironicclient')

Is avoiding three lines of code really worth making future cleanup harder?
Is a three line change really blocking "an approved blueprint with ready
code"?

Michael



On Thu, Apr 12, 2018 at 10:42 PM, Eric Fried <openst...@fried.cc> wrote:

> +1
>
> This sounds reasonable to me.  I'm glad the issue was raised, but IMO it
> shouldn't derail progress on an approved blueprint with ready code.
>
> Jichen, would you please go ahead and file that blueprint template (no
> need to write a spec yet) and link it in a review comment on the bottom
> zvm patch so we have a paper trail?  I'm thinking something like
> "Consistent platform-specific and optional requirements" -- that leaves
> us open to decide *how* we're going to "handle" them.
>
> Thanks,
> efried
>
> On 04/12/2018 04:13 AM, Chen CH Ji wrote:
> > Thanks for Michael for raising this question and detailed information
> > from Clark
> >
> > As indicated in the mail, xen, vmware etc might already have this kind
> > of requirements (and I guess might be more than that) ,
> > can we accept z/VM requirements first by following other existing ones
> > then next I can create a BP later to indicate this kind
> > of change request by referring to Clark's comments and submit patches to
> > handle it ? Thanks
> >
> > Best Regards!
> >
> > Kevin (Chen) Ji 纪 晨
> >
> > Engineer, zVM Development, CSTL
> > Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
> > Phone: +86-10-82451493
> > Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
> > District, Beijing 100193, PRC
> >
> > Inactive hide details for Matt Riedemann ---04/12/2018 08:46:25 AM---On
> > 4/11/2018 5:09 PM, Michael Still wrote: >Matt Riedemann ---04/12/2018
> > 08:46:25 AM---On 4/11/2018 5:09 PM, Michael Still wrote: >
> >
> > From: Matt Riedemann <mriede...@gmail.com>
> > To: openstack-dev@lists.openstack.org
> > Date: 04/12/2018 08:46 AM
> > Subject: Re: [openstack-dev] [Nova][Deployers] Optional, platform
> > specific, dependancies in requirements.txt
> >
> > 
> >
> >
> >
> > On 4/11/2018 5:09 PM, Michael Still wrote:
> >>
> >>
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__review.
> openstack.org_-23_c_523387=DwIGaQ=jf_iaSHvJObTbx-
> siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=
> 212PUwLYOBlJZ3BiZNuJIFkRfqXoBPJDcWYCDk7vCHg=
> CNosrTHnAR21zOI52fnDRfTqu2zPiAn2oW9f67Qijo4= proposes
> > adding a z/VM specific
> >> dependancy to nova's requirements.txt. When I objected the counter
> >> argument is that we have examples of windows specific dependancies
> >> (os-win) and powervm specific dependancies in that file already.
> >>
> >> I think perhaps all three are a mistake and should be removed.
> >>
> >> My recollection is that for drivers like ironic which may not be
> >> deployed by everyone, we have the dependancy documented, and then loaded
> >> at runtime by the driver itself instead of adding it to
> >> requirements.txt. This is to stop pip for auto-installing the dependancy
> >> for anyone who wants to run nova. I had assumed this was at the request
> >> of the deployer community.
> >>
> >> So what do we do with z/VM? Do we clean this up? Or do we now allow
> >> dependancies that are only useful to a very small number of deployments
> >> into requirements.txt?
> >
> > As Eric pointed out in the review, this came up when pypowervm was added:
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__review.
> openstack.org_-23_c_438119_5_requirements.txt=DwIGaQ=
> jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=
> 212PUwLYOBlJZ3BiZNuJIFkRfqXoBPJDcWYCDk7vCHg=iyKxF-
> CcGAFmnQs8B7d5u2zwEiJqq8ivETmrgB77PEg=
> >
> > And you're asking the same questions I did in there, which was, should
> > it go into test-requirements.txt like oslo.vmware and
> > python-ironicclient, or should it go under [extras], or go into
> > requirements.txt like os-win (we also have the xenapi library now too).
> >
> > I don't really think all of these optional packages should be in
> > requirements.txt, but we should just be consistent with whatever we do,
> > be that test-requirements.txt or [extras]. I remember caring more about

Re: [openstack-dev] [Nova] z/VM introducing a new config drive format

[Michael Still]

The more I think about it, the more I dislike how the proposed driver also
"lies" about it using iso9660. That's definitely wrong:

if CONF.config_drive_format in ['iso9660']:
# cloud-init only support iso9660 and vfat, but in z/VM
# implementation, can't link a disk to VM as iso9660 before it's
# boot ,so create a tgz file then send to the VM deployed, and
# during startup process, the tgz file will be extracted and
# mounted as iso9660 format then cloud-init is able to consume
it
self._make_tgz(path)
else:
raise exception.ConfigDriveUnknownFormat(
format=CONF.config_drive_format)

Michael

On Thu, Apr 12, 2018 at 9:28 AM, Dan Smith <d...@danplanet.com> wrote:

> > https://review.openstack.org/#/c/527658 is a z/VM patch which
> > introduces their support for config drive. They do this by attaching a
> > tarball to the instance, having pretended in the nova code that it is
> > an iso9660. This worries me.
> >
> > In the past we've been concerned about adding new filesystem formats
> > for config drives, and the long term support implications of that --
> > the filesystem formats for config drive that we use today were
> > carefully selected as being universally supported by our guest
> > operating systems.
> >
> > The previous example we've had of these issues is the parallels
> > driver, which had similar "my hypervisor doesn't support these
> > filesystem format" concerns. We worked around those concerns IIRC, and
> > certainly virt.configdrive still only supports iso9660 and vfat.
>
> Yeah, IIRC, the difference with the parallels driver was that it ends up
> mounted in the container automagically for the guest by the..uh..man
> behind the curtain. However, z/VM being much more VM-y I imagine that
> the guest is just expected to grab that blob and do something with it to
> extract it on local disk at runtime or something. That concerns me too.
>
> In the past I've likened adding filesystem (or format, in this case)
> options to configdrive as a guest ABI change. I think the stability of
> what we present to guests is second only to our external API in terms of
> importance. I know z/VM is "weird" or "different", but I wouldn't want a
> more conventional hypervisor exposing the configdrive as a tarball, so I
> don't really think it's a precedent we should set. Both vfat and iso9660
> are easily supportable by most everything on the planet so I don't think
> it's an unreasonable bar.
>
> --Dan
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Nova] z/VM introducing a new config drive format

[Michael Still]

Heya,

https://review.openstack.org/#/c/527658 is a z/VM patch which introduces
their support for config drive. They do this by attaching a tarball to the
instance, having pretended in the nova code that it is an iso9660. This
worries me.

In the past we've been concerned about adding new filesystem formats for
config drives, and the long term support implications of that -- the
filesystem formats for config drive that we use today were carefully
selected as being universally supported by our guest operating systems.

The previous example we've had of these issues is the parallels driver,
which had similar "my hypervisor doesn't support these filesystem format"
concerns. We worked around those concerns IIRC, and certainly
virt.configdrive still only supports iso9660 and vfat.

Discuss.

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

[openstack-dev] [Nova][Deployers] Optional, platform specific, dependancies in requirements.txt

[Michael Still]

Hi,

https://review.openstack.org/#/c/523387 proposes adding a z/VM specific
dependancy to nova's requirements.txt. When I objected the counter argument
is that we have examples of windows specific dependancies (os-win) and
powervm specific dependancies in that file already.

I think perhaps all three are a mistake and should be removed.

My recollection is that for drivers like ironic which may not be deployed
by everyone, we have the dependancy documented, and then loaded at runtime
by the driver itself instead of adding it to requirements.txt. This is to
stop pip for auto-installing the dependancy for anyone who wants to run
nova. I had assumed this was at the request of the deployer community.

So what do we do with z/VM? Do we clean this up? Or do we now allow
dependancies that are only useful to a very small number of deployments
into requirements.txt?

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] [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 <cdent...@anticdent.org> 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] [ironic] Ironic Bug Day on Thursday April 12th @ 1:00 PM - 3:00 PM (UTC)

[Michael Turek]

Sorry this is so late but as for the format of the event I think we 
should do something like this:


1) Go through new bugs
    -This is doable in storyboard. Sort by creation date
    -Should be a nice warm up activity!
2) Go through oldest bugs
    -Again, doable in storyboard. Sort by last updated.
    -Older bugs are usually candidates for some clean up. We'll decide 
if bugs are still valid

 or if we need to reassign/poke owners.
3) Open Floor
    -If you have a bug that you'd like to discuss, bring it up here!
4) Storyboard discussion
    -One of the reasons we are doing this is to get our feet wet in 
storyboard. Let's spend
 10 to 20 minutes discussing what we need out of the tool after 
playing with it.


Originally I was hoping that we could sort by task priority but that 
currently seems to be
unavailable, or well hidden, in storyboard . If someone knows how to do 
this, please reply.


Does anyone else have any ideas on how to structure bug day?

Thanks!
Mike 


On 4/11/18 9:47 AM, Michael Turek wrote:

Hey all,

Ironic Bug Day is happening tomorrow, April 12th at 1:00 PM - 3:00 PM 
(UTC)


We will be meeting on Julia's bluejeans line: 
https://bluejeans.com/5548595878


Hope to see everyone there!

Thanks,
Mike Turek 


__ 


OpenStack Development Mailing 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] [ironic] Ironic Bug Day on Thursday April 12th @ 1:00 PM - 3:00 PM (UTC)

[Michael Turek]

Hey all,

Ironic Bug Day is happening tomorrow, April 12th at 1:00 PM - 3:00 PM (UTC)

We will be meeting on Julia's bluejeans line: 
https://bluejeans.com/5548595878


Hope to see everyone there!

Thanks,
Mike Turek 


__
OpenStack Development Mailing 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 <openst...@nemebean.com> 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] [oslo.db] innodb OPTIMIZE TABLE ?

[Michael Bayer]

On Mon, Apr 9, 2018 at 5:53 AM, Gorka Eguileor <gegui...@redhat.com> wrote:
> On 06/04, Michael Bayer wrote:
>> On Wed, Apr 4, 2018 at 5:00 AM, Gorka Eguileor <gegui...@redhat.com> wrote:
>> > On 03/04, Jay Pipes wrote:
>> >> On 04/03/2018 11:07 AM, Michael Bayer wrote:
>> >> > The MySQL / MariaDB variants we use nowadays default to
>> >> > innodb_file_per_table=ON and we also set this flag to ON in installer
>> >> > tools like TripleO. The reason we like file per table is so that
>> >> > we don't grow an enormous ibdata file that can't be shrunk without
>> >> > rebuilding the database.  Instead, we have lots of little .ibd
>> >> > datafiles for each table throughout each openstack database.
>> >> >
>> >> > But now we have the issue that these files also can benefit from
>> >> > periodic optimization which can shrink them and also have a beneficial
>> >> > effect on performance.   The OPTIMIZE TABLE statement achieves this,
>> >> > but as would be expected it itself can lock tables for potentially a
>> >> > long time.   Googling around reveals a lot of controversy, as various
>> >> > users and publications suggest that OPTIMIZE is never needed and would
>> >> > have only a negligible effect on performance.   However here we seek
>> >> > to use OPTIMIZE so that we can reclaim disk space on tables that have
>> >> > lots of DELETE activity, such as keystone "token" and ceilometer
>> >> > "sample".
>> >> >
>> >> > Questions for the group:
>> >> >
>> >> > 1. is OPTIMIZE table worthwhile to be run for tables where the
>> >> > datafile has grown much larger than the number of rows we have in the
>> >> > table?
>> >>
>> >> Possibly, though it's questionable to use MySQL/InnoDB for storing 
>> >> transient
>> >> data that is deleted often like ceilometer samples and keystone tokens. A
>> >> much better solution is to use RDBMS partitioning so you can simply ALTER
>> >> TABLE .. DROP PARTITION those partitions that are no longer relevant (and
>> >> don't even bother DELETEing individual rows) or, in the case of Ceilometer
>> >> samples, don't use a traditional RDBMS for timeseries data at all...
>> >>
>> >> But since that is unfortunately already the case, yes it is probably a 
>> >> good
>> >> idea to OPTIMIZE TABLE on those tables.
>> >>
>> >> > 2. from people's production experience how safe is it to run OPTIMIZE,
>> >> > e.g. how long is it locking tables, etc.
>> >>
>> >> Is it safe? Yes.
>> >>
>> >> Does it lock the entire table for the duration of the operation? No. It 
>> >> uses
>> >> online DDL operations:
>> >>
>> >> https://dev.mysql.com/doc/refman/5.7/en/innodb-file-defragmenting.html
>> >>
>> >> Note that OPTIMIZE TABLE is mapped to ALTER TABLE tbl_name FORCE for 
>> >> InnoDB
>> >> tables.
>> >>
>> >> > 3. is there a heuristic we can use to measure when we might run this
>> >> > -.e.g my plan is we measure the size in bytes of each row in a table
>> >> > and then compare that in some ratio to the size of the corresponding
>> >> > .ibd file, if the .ibd file is N times larger than the logical data
>> >> > size we run OPTIMIZE ?
>> >>
>> >> I don't believe so, no. Most things I see recommended is to simply run
>> >> OPTIMIZE TABLE in a cron job on each table periodically.
>> >>
>> >> > 4. I'd like to propose this job of scanning table datafile sizes in
>> >> > ratio to logical data sizes, then running OPTIMIZE, be a utility
>> >> > script that is delivered via oslo.db, and would run for all innodb
>> >> > tables within a target MySQL/ MariaDB server generically.  That is, I
>> >> > really *dont* want this to be a script that Keystone, Nova, Ceilometer
>> >> > etc. are all maintaining delivering themselves.   this should be done
>> >> > as a generic pass on a whole database (noting, again, we are only
>> >> > running it for very specific InnoDB tables that we observe have a poor
>> >> > logical/physical size ratio).
>> >>
>> >> I don't believe this should be in oslo.db. This is stric

Re: [openstack-dev] [oslo.db] innodb OPTIMIZE TABLE ?

[Michael Bayer]

On Wed, Apr 4, 2018 at 5:00 AM, Gorka Eguileor <gegui...@redhat.com> wrote:
> On 03/04, Jay Pipes wrote:
>> On 04/03/2018 11:07 AM, Michael Bayer wrote:
>> > The MySQL / MariaDB variants we use nowadays default to
>> > innodb_file_per_table=ON and we also set this flag to ON in installer
>> > tools like TripleO. The reason we like file per table is so that
>> > we don't grow an enormous ibdata file that can't be shrunk without
>> > rebuilding the database.  Instead, we have lots of little .ibd
>> > datafiles for each table throughout each openstack database.
>> >
>> > But now we have the issue that these files also can benefit from
>> > periodic optimization which can shrink them and also have a beneficial
>> > effect on performance.   The OPTIMIZE TABLE statement achieves this,
>> > but as would be expected it itself can lock tables for potentially a
>> > long time.   Googling around reveals a lot of controversy, as various
>> > users and publications suggest that OPTIMIZE is never needed and would
>> > have only a negligible effect on performance.   However here we seek
>> > to use OPTIMIZE so that we can reclaim disk space on tables that have
>> > lots of DELETE activity, such as keystone "token" and ceilometer
>> > "sample".
>> >
>> > Questions for the group:
>> >
>> > 1. is OPTIMIZE table worthwhile to be run for tables where the
>> > datafile has grown much larger than the number of rows we have in the
>> > table?
>>
>> Possibly, though it's questionable to use MySQL/InnoDB for storing transient
>> data that is deleted often like ceilometer samples and keystone tokens. A
>> much better solution is to use RDBMS partitioning so you can simply ALTER
>> TABLE .. DROP PARTITION those partitions that are no longer relevant (and
>> don't even bother DELETEing individual rows) or, in the case of Ceilometer
>> samples, don't use a traditional RDBMS for timeseries data at all...
>>
>> But since that is unfortunately already the case, yes it is probably a good
>> idea to OPTIMIZE TABLE on those tables.
>>
>> > 2. from people's production experience how safe is it to run OPTIMIZE,
>> > e.g. how long is it locking tables, etc.
>>
>> Is it safe? Yes.
>>
>> Does it lock the entire table for the duration of the operation? No. It uses
>> online DDL operations:
>>
>> https://dev.mysql.com/doc/refman/5.7/en/innodb-file-defragmenting.html
>>
>> Note that OPTIMIZE TABLE is mapped to ALTER TABLE tbl_name FORCE for InnoDB
>> tables.
>>
>> > 3. is there a heuristic we can use to measure when we might run this
>> > -.e.g my plan is we measure the size in bytes of each row in a table
>> > and then compare that in some ratio to the size of the corresponding
>> > .ibd file, if the .ibd file is N times larger than the logical data
>> > size we run OPTIMIZE ?
>>
>> I don't believe so, no. Most things I see recommended is to simply run
>> OPTIMIZE TABLE in a cron job on each table periodically.
>>
>> > 4. I'd like to propose this job of scanning table datafile sizes in
>> > ratio to logical data sizes, then running OPTIMIZE, be a utility
>> > script that is delivered via oslo.db, and would run for all innodb
>> > tables within a target MySQL/ MariaDB server generically.  That is, I
>> > really *dont* want this to be a script that Keystone, Nova, Ceilometer
>> > etc. are all maintaining delivering themselves.   this should be done
>> > as a generic pass on a whole database (noting, again, we are only
>> > running it for very specific InnoDB tables that we observe have a poor
>> > logical/physical size ratio).
>>
>> I don't believe this should be in oslo.db. This is strictly the purview of
>> deployment tools and should stay there, IMHO.
>>
>
> Hi,
>
> As far as I know most projects do "soft deletes" where we just flag the
> rows as deleted and don't remove them from the DB, so it's only when we
> use a management tool and run the "purge" command that we actually
> remove these rows.
>
> Since running the optimize without purging would be meaningless, I'm
> wondering if we should trigger the OPTIMIZE also within the purging
> code.  This way we could avoid innefective runs of the optimize command
> when no purge has happened and even when we do the optimization we could
> skip the ratio calculation altogether for tables where no rows have been
> deleted (the ratio hasn't changed).
>

the issue is that this 

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 <sla...@kaplonski.pl> 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 <amot...@gmail.com> w dniu 
>> 06.04.2018, o godz. 11:34:
>>
>>
>> Hi Slawek,
>>
>> 2018-04-06 17:38 GMT+09:00 Sławek Kapłoński <sla...@kaplonski.pl>:
>> 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 <glongw...@gmail.com> w dniu 
>> > 26.03.2018, o godz. 14:15:
>> >
>> >
>> > 2018-03-22 16:12 GMT+08:00 Sławomir Kapłoński <sla...@kaplonski.pl>:
>> > 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 D

[openstack-dev] [all][api] POST /api-sig/news

[Michael McCune]

Greetings OpenStack community,

Today's meeting was quite lively with a good discussion about versions
and microversions across OpenStack and their usage within the API
schema world. We began with a review of outstanding work: elmiko is
continuing to work on an update to the microversion history doc[7],
and edleafe has reached out[8] to the SDK community to gauge interest
in a session for the upcoming Vancouver forum. dtanstur has also also
made an update[9] to the HTTP guideline layout that is currently under
review. The change was already largely approved; this just improves
the appearance of the refactored guidelines.

The API-SIG has not confirmed any sessions for the Vancouver forum
yet, but we continue to reach out[8] and would ideally like to host a
session including the API, SDK and user community groups. The topics
and schedule for this session will be highly influenced by input from
the larger OpenStack community. If you are interested in seeing this
event happen, please add your thoughts to the mailing sent out by
edleafe[8].

The next chunk of the meeting was spent discussing the OpenAPI
proposal[10] that elmiko has created. The discussion went well and
several new ideas were exposed. Additionally, a deep dive into
version/microversion usage across the OpenStack ecosystem was exposed
with several points being raised about how microversions are used and
how they are perceived by end users. There is no firm output from this
discussion yet, but elmiko is going to contact interested parties and
continue to update the proposal.

mordred informed the SIG that he has started working on
discover/version things in keystoneauth and should be returning to the
related specs within the next few days. and there was much rejoicing.
\o/

On the topic of reviews, the SIG has identified one[11] that is ready
for freeze this week.

Lastly, the SIG reviewed a newly opened bug[12] asking to add a
"severity" field to the error structure. After a short discussion, the
group agreed that this was not something that should be accepted and
have marked it as "won't fix". For more details please see the
comments on the bug review.

As always if you're interested in helping out, in addition to coming
to the meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for
changes over time. If you find something that's not quite right,
submit a patch [6] to fix it.
* Have you done something for which you think guidance would have made
things easier but couldn't find any? Submit a patch and help others
[6].

# Newly Published Guidelines

* Add guideline on exposing microversions in SDKs
  https://review.openstack.org/#/c/532814

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

* Update the errors guidance to use service-type for code
  https://review.openstack.org/#/c/554921/

# Guidelines Currently Under Review [3]

* Break up the HTTP guideline into smaller documents
  https://review.openstack.org/#/c/554234/

* Add guidance on needing cache-control headers
  https://review.openstack.org/550468

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* A (shrinking) suite of several documents about doing version and
service discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet
ready for review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs
that you are developing or changing, please address your concerns in
an email to the OpenStack developer mailing list[1] with the tag
"[api]" in the subject. In your email, you should include any relevant
reviews, links, and comments to help guide the discussion of the
specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our
wiki page [4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] https://review.openstack.org/444892
[8] http://lists.openstack.org/pipermail/openstack-sigs/2018-March/000353.html
[9] https://review.openstack.org/#/c/554234/
[10] https://gist.github.com/elmiko/7d97fef591887aa0c594c3dafad83442
[11] https://review.openstack.org/#/c/554921/
[12] https://bugs.launchpad.net/openstack-api-wg/+bug/1761475

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records

[openstack-dev] [ironic] Bug Day April 12th poll (was originally April 6th)

[Michael Turek]

Hey everyone,

At this week's ironic IRC meeting we decided to push the bug day to 
April 12th. I updated the poll name to indicate this and it 
unfortunately wiped the results of the poll.


If you can recast your vote here it would be appreciated 
https://doodle.com/poll/xa999rx653pb58t6


It's looking like a 2 hour window would be the right length, but if you 
have any opinions on that please respond here.


Thanks!
Mike Turek 


__
OpenStack Development Mailing 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] pep8 failures on master

[Michael Still]

I think the bit I am lost on is the concept of running pep8 "under" a
version of python. Is this an artifact of what version of pep8 I have
installed somehow?

If the py3 pep8 is stricter, couldn't we just move to only that one?

Michael

On Wed., 4 Apr. 2018, 8:19 am Kevin L. Mitchell, <klmi...@mit.edu> wrote:

> On Wed, 2018-04-04 at 07:54 +1000, Michael Still wrote:
> > Thanks to jichenjc for fixing the pep8 failures I was seeing on
> > master. I'd decided they were specific to my local dev environment
> > given no one else was seeing them.
> >
> > As I said in the patch that fixed the issue [1], I think its worth
> > exploring how these got through the gate in the first place. There is
> > nothing in the patch which stops us from ending up here again, and no
> > real explanation for what caused the issue in the first place.
>
> While there was no discussion in the patch, the topic of the patch
> hints at the cause: "fix_pep8_py3".  These were probably pep8 errors
> that would only occur if pep8 was running under Python 3 and not Python
> 2.  The first error was fixed by removing a debugging print that was
> formatted as "print (…)", which would satisfy pep8 under Python 2—since
> 'print' is a statement—but not under Python 3, where it's a function.
> The second error was in a clause protected by six.PY2, and was caused
> by "unicode" being missing in Python 3; the solution jichenjc chose
> there was to disable the pep8 check for that line.
>
> The only way I can imagine stopping these errors in the future would be
> to double-up on the pep8 check: have the gate run pep8 under both
> Python 2 and Python 3.
> --
> Kevin L. Mitchell <klmi...@mit.edu
> >__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] pep8 failures on master

[Michael Still]

Thanks to jichenjc for fixing the pep8 failures I was seeing on master. I'd
decided they were specific to my local dev environment given no one else
was seeing them.

As I said in the patch that fixed the issue [1], I think its worth
exploring how these got through the gate in the first place. There is
nothing in the patch which stops us from ending up here again, and no real
explanation for what caused the issue in the first place.

Discuss.

Michael


1: https://review.openstack.org/#/c/557633
__
OpenStack Development Mailing 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] [oslo.db] innodb OPTIMIZE TABLE ?

[Michael Bayer]

On Tue, Apr 3, 2018 at 11:41 AM, Jay Pipes <jaypi...@gmail.com> wrote:
> On 04/03/2018 11:07 AM, Michael Bayer wrote:
>>
>
> Yes.
>
>> b. oslo.db script to run generically, yes or no?
>
>
> No. Just have Triple-O install galera_innoptimizer and run it in a cron job.

OK, here are the issues I have with galera_innoptimizer:

1. only runs on Galera.This should work on a non-galera db as well

2. hardcoded to MySQLdb / mysqlclient.   We don't install that driver anymore.

3. is just running OPTIMIZE on every table across the board, and at
best you can give it a list of tables.  I was hoping to not add more
hardcoded cross-dependencies to tripleo, as this means individual
projects would need to affect how the script is run which means we
have to again start shipping individual per-app crons that require
eternal babysitting.

What failures do you foresee if I tried to make it compare the logical
data size to the physical file size?  since I'm going here for file
size optimization only.   or just too complicated / brittle ?

>
> Best,
> -jay
>
>> thanks for your thoughts!
>>
>>
>>
>> [1] https://github.com/deimosfr/galera_innoptimizer
>>
>> __
>> OpenStack Development Mailing 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] [oslo.db] innodb OPTIMIZE TABLE ?

[Michael Bayer]

The MySQL / MariaDB variants we use nowadays default to
innodb_file_per_table=ON and we also set this flag to ON in installer
tools like TripleO. The reason we like file per table is so that
we don't grow an enormous ibdata file that can't be shrunk without
rebuilding the database.  Instead, we have lots of little .ibd
datafiles for each table throughout each openstack database.

But now we have the issue that these files also can benefit from
periodic optimization which can shrink them and also have a beneficial
effect on performance.   The OPTIMIZE TABLE statement achieves this,
but as would be expected it itself can lock tables for potentially a
long time.   Googling around reveals a lot of controversy, as various
users and publications suggest that OPTIMIZE is never needed and would
have only a negligible effect on performance.   However here we seek
to use OPTIMIZE so that we can reclaim disk space on tables that have
lots of DELETE activity, such as keystone "token" and ceilometer
"sample".

Questions for the group:

1. is OPTIMIZE table worthwhile to be run for tables where the
datafile has grown much larger than the number of rows we have in the
table?

2. from people's production experience how safe is it to run OPTIMIZE,
e.g. how long is it locking tables, etc.

3. is there a heuristic we can use to measure when we might run this
-.e.g my plan is we measure the size in bytes of each row in a table
and then compare that in some ratio to the size of the corresponding
.ibd file, if the .ibd file is N times larger than the logical data
size we run OPTIMIZE ?

4. I'd like to propose this job of scanning table datafile sizes in
ratio to logical data sizes, then running OPTIMIZE, be a utility
script that is delivered via oslo.db, and would run for all innodb
tables within a target MySQL/ MariaDB server generically.  That is, I
really *dont* want this to be a script that Keystone, Nova, Ceilometer
etc. are all maintaining delivering themselves.   this should be done
as a generic pass on a whole database (noting, again, we are only
running it for very specific InnoDB tables that we observe have a poor
logical/physical size ratio).

5. for Galera this gets more tricky, as we might want to run OPTIMIZE
on individual nodes directly.  The script at [1] illustrates how to
run this on individual nodes one at a time.

More succinctly, the Q is:

a. OPTIMIZE, yes or no?
b. oslo.db script to run generically, yes or no?

thanks for your thoughts!



[1] https://github.com/deimosfr/galera_innoptimizer

__
OpenStack Development Mailing 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 <sla...@kaplonski.pl> wrote:
> Hi,
>
>
>> Wiadomość napisana przez ChangBo Guo <glongw...@gmail.com> w dniu 
>> 26.03.2018, o godz. 14:15:
>>
>>
>> 2018-03-22 16:12 GMT+08:00 Sławomir Kapłoński <sla...@kaplonski.pl>:
>> 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

[openstack-dev] [ironic] Bug Day April 6th poll

[Michael Turek]

Hey everyone,

I set up a doodle to vote on when we should hold the bug day on April 
6th https://doodle.com/poll/xa999rx653pb58t6


I'm not sure how long we want the session to be so I provided 24 1 hour 
windows. Please vote with what blocks of time would work best for you.


Thanks!
Mike Turek 


__
OpenStack Development Mailing 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][api] POST /api-sig/news

[Michael McCune]

Greetings OpenStack community,

Another jovial meeting of the API-SIG was convened today. We began with a
few housekeeping notes and then moved into a discussion of the api-ref work
and how we might continue to assist Graham Hayes with the os-api-ref
changes[7] that will output a machine-readable format for the API schemas.
The group generally agrees that the SIG should continue to assist in moving
these changes forward, there are concerns about the inclusion of
microversions and how best to capture these, but for the time being the SIG
will engage with the review and the parties interested in seeing this work
through to completion.

We then talked about the new reviews which have been added recently to the
queue. The SIG has decided to freeze the proposed guidance[8] on exposing
microversions in SDKs created by Dmitry Tantsur. There is also a review[9]
from Ed Leafe to split up the current HTTP guidance document into separate
documents to help improve the readability and presence of this material,
this should be ready for freeze soon.

Lastly, we discussed a new bug[10] concerning how services should be
referenced in error messages. The current guidance specifies that a service
name should be used and the proposed bug by Chris Dent is that the service
type should be used instead. Chris has also created a review[11] to address
this but the SIG would like more opinions on this change and how it might
impact consuming the error messages.

As always if you're interested in helping out, in addition to coming to the
meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for changes
over time. If you find something that's not quite right, submit a patch [6]
to fix it.
* Have you done something for which you think guidance would have made
things easier but couldn't find any? Submit a patch and help others [6].

# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

* Add guideline on exposing microversions in SDKs
  https://review.openstack.org/#/c/532814

# Guidelines Currently Under Review [3]

* Break up the HTTP guideline into smaller documents
  https://review.openstack.org/#/c/554234/

* Add guidance on needing cache-control headers
  https://review.openstack.org/550468

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* A (shrinking) suite of several documents about doing version and service
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready
for review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that you
are developing or changing, please address your concerns in an email to the
OpenStack developer mailing list[1] with the tag "[api]" in the subject. In
your email, you should include any relevant reviews, links, and comments to
help guide the discussion of the specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our wiki
page [4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3]
https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] https://review.openstack.org/#/c/528801/
[8] https://review.openstack.org/#/c/532814/
[9] https://review.openstack.org/#/c/554234/
[10] https://bugs.launchpad.net/openstack-api-wg/+bug/1756464
[11] https://review.openstack.org/#/c/554921/

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg
__
OpenStack Development Mailing 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-sigs] [all][api] POST /api-sig/news

[Michael McCune]

On Fri, Mar 16, 2018 at 4:55 AM, Chris Dent  wrote:

> 
>
>> So summarize and clarify, we are talking about SDK being able to build
>> their interface to Openstack APIs in an automated way but statically from
>> API Schema generated by every project. Such API Schema is already built in
>> memory during API reference documentation generation and could be saved in
>> JSON format (for instance) (see [5]).
>>
>
> What do you see as the current roadblocks preventing this work from
> continuing to make progress?
>
>
>
Gilles, i'm very curious about how we can help as well.

i am keenly interested in the api-schema work that is happening and i am
coming up to speed with the work that Graham has done, and which previously
existed, on os-api-ref. although i don't have a *ton* of spare free time, i
would like to help as much as i can.

thanks for bringing this up again,

peace o/
__
OpenStack Development Mailing 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] [Tatu][Nova] Handling instance destruction

[Michael Still]

I think it would simplify deployment a fair bit too -- a single API to
provide instead of also having to setup a notification listener. I shall
ponder and perhaps implement once I've finished the privsep stuff.

Michael

On Fri, Mar 16, 2018 at 5:49 PM, Juan Antonio Osorio <jaosor...@gmail.com>
wrote:

> Having an interface for vendordata that gets deletes would be quite nice.
> Right now for novajoin we listen to the nova notifications for updates and
> deletes; if this could be handled natively by vendordata, it would simplify
> our codebase.
>
> BR
>
> On Fri, Mar 16, 2018 at 7:34 AM, Michael Still <mi...@stillhq.com> wrote:
>
>> Thanks for this. I read the README for the project after this and I do
>> now realise you're using notifications for some of these events.
>>
>> I guess I'm still pondering if its reasonable to have everyone listen to
>> notifications to build systems like these, or if we should messages to
>> vendordata to handle these actions. Vendordata is intended at deployers, so
>> having a simple and complete interface seems important.
>>
>> There were also comments in the README about wanting to change the data
>> that appears in the metadata server over time. I'm wondering how that maps
>> into the configdrive universe. Could you explain those comments a bit more
>> please?
>>
>> Thanks for your quick reply,
>> Michael
>>
>>
>>
>>
>> On Fri, Mar 16, 2018 at 2:18 PM, Pino de Candia <
>> giuseppe.decan...@gmail.com> wrote:
>>
>>> Hi Michael,
>>>
>>> Thanks for your message... and thanks for your vendordata work!
>>>
>>> About your question, Tatu listens to events on the oslo message bus.
>>> Specifically, it reacts to compute.instance.delete.end by cleaning up
>>> per-instance resources. It also listens to project creation and user role
>>> assignment changes. The code is at:
>>> https://github.com/openstack/tatu/blob/master/tatu/notifications.py
>>>
>>> best,
>>> Pino
>>>
>>>
>>> On Thu, Mar 15, 2018 at 3:42 PM, Michael Still <mi...@stillhq.com>
>>> wrote:
>>>
>>>> Heya,
>>>>
>>>> I've just stumbled across Tatu and the design presentation [1], and I
>>>> am wondering how you handle cleaning up instances when they are deleted
>>>> given that nova vendordata doesn't expose a "delete event".
>>>>
>>>> Specifically I'm wondering if we should add support for such an event
>>>> to vendordata somehow, given I can now think of a couple of use cases for
>>>> it.
>>>>
>>>> Thanks,
>>>> Michael
>>>>
>>>> 1: https://docs.google.com/presentation/d/1HI5RR3SNUu1If-A5Z
>>>> i4EMvjl-3TKsBW20xEUyYHapfM/edit#slide=id.p
>>>>
>>>> 
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: openstack-dev-requ...@lists.op
>>>> enstack.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.op
>>> enstack.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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Juan Antonio Osorio R.
> e-mail: jaosor...@gmail.com
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] [Tatu][Nova] Handling instance destruction

[Michael Still]

Thanks for this. I read the README for the project after this and I do now
realise you're using notifications for some of these events.

I guess I'm still pondering if its reasonable to have everyone listen to
notifications to build systems like these, or if we should messages to
vendordata to handle these actions. Vendordata is intended at deployers, so
having a simple and complete interface seems important.

There were also comments in the README about wanting to change the data
that appears in the metadata server over time. I'm wondering how that maps
into the configdrive universe. Could you explain those comments a bit more
please?

Thanks for your quick reply,
Michael




On Fri, Mar 16, 2018 at 2:18 PM, Pino de Candia <giuseppe.decan...@gmail.com
> wrote:

> Hi Michael,
>
> Thanks for your message... and thanks for your vendordata work!
>
> About your question, Tatu listens to events on the oslo message bus.
> Specifically, it reacts to compute.instance.delete.end by cleaning up
> per-instance resources. It also listens to project creation and user role
> assignment changes. The code is at:
> https://github.com/openstack/tatu/blob/master/tatu/notifications.py
>
> best,
> Pino
>
>
> On Thu, Mar 15, 2018 at 3:42 PM, Michael Still <mi...@stillhq.com> wrote:
>
>> Heya,
>>
>> I've just stumbled across Tatu and the design presentation [1], and I am
>> wondering how you handle cleaning up instances when they are deleted given
>> that nova vendordata doesn't expose a "delete event".
>>
>> Specifically I'm wondering if we should add support for such an event to
>> vendordata somehow, given I can now think of a couple of use cases for it.
>>
>> Thanks,
>> Michael
>>
>> 1: https://docs.google.com/presentation/d/1HI5RR3SNUu1If-A5Z
>> i4EMvjl-3TKsBW20xEUyYHapfM/edit#slide=id.p
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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] [Tatu][Nova] Handling instance destruction

[Michael Still]

Heya,

I've just stumbled across Tatu and the design presentation [1], and I am
wondering how you handle cleaning up instances when they are deleted given
that nova vendordata doesn't expose a "delete event".

Specifically I'm wondering if we should add support for such an event to
vendordata somehow, given I can now think of a couple of use cases for it.

Thanks,
Michael

1:
https://docs.google.com/presentation/d/1HI5RR3SNUu1If-A5Zi4EMvjl-3TKsBW20xEUyYHapfM/edit#slide=id.p
__
OpenStack Development Mailing 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, Вадим Пономарев <ponoma...@selectel.ru> 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] [oslo.db] upcoming warnings in MySQL 5.6, 5.7 for BLOB columns

[Michael Bayer]

Forgot the links:

[1] https://bugs.mysql.com/bug.php?id=79317
[2] https://github.com/PyMySQL/PyMySQL/issues/644

On Wed, Mar 14, 2018 at 11:53 AM, Michael Bayer <mba...@redhat.com> wrote:
> hey all -
>
> Just looking to see if we think this will impact openstack.  MySQL 5.6
> and 5.7, but not yet MariaDB, now emits an erroneous warning when you
> try to send a binary value to the database, because it sees the client
> connection is supposed to use the utf8 or utf8mb4 charsets, assumes
> all data must be in that charset, then warns because the binary data
> does not necessarily conform to utf8 (which it has no need to, it's
> binary).
>
> Sounds weird, right, to make it easier the demo looks just like this:
>
> import pymysql
> import uuid
>
> conn = pymysql.connect(
> user="scott", passwd="tiger", host="mysql56",
> db="test", charset="utf8mb4")
> cursor = conn.cursor()
> cursor.execute("""
> CREATE TABLE IF NOT EXISTS `profiles` (
>   `id` varchar(32) COLLATE utf8mb4_unicode_ci NOT NULL,
>   `city` blob NOT NULL
> ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
> """)
> cursor.execute(
> "INSERT INTO profiles (id, city) VALUES (%(id)s, %(city)s)",
> {
> 'id': uuid.uuid4().hex,
> 'city': pymysql.Binary(
> 
> b'z\xf9\x87jS?\xd4i\xa5\xa3\r\xa7\x1e\xed\x16\xe0\xb5\x05R\xa4\xec\x16\x8f\x06\xb5\xea+\xaf<\x00\\\x94I9A\xe0\x82\xa7\x13\x0c\x8c'
> )
> }
> )
>
> when using PyMySQL 0.8.0 (not 0.7.1) you then get a warning
>
> Warning: (1300, "Invalid utf8mb4 character string: 'F9876A'").
>
>
> So, Oracle upstream clearly is never going to fix this if you look at
> the typically dismal discussion at [1].   I poked the PyMySQL project
> at [2] to see what we can do.   Long term is that SQLAlchemy will add
> the special "_binary" prefix to binary-bound parameter tokens to avoid
> the warning, however right now PyMySQL supports a flag "binary_prefix"
> that will do it for us on the driver side.
>
> For Openstack, i need to know if we are in fact passing binary data to
> databases in some project or another.   What we can do is add the
> supply of this flag to oslo.db so that it is present automatically for
> the PyMySQL driver, as well as checking the PyMySQL version for
> compatibility.
>
> If folks are seeing this warning already or are using BLOB / binary
> columns in their project please ping me and we will get this added to
> oslo.db.

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

[openstack-dev] [oslo.db] upcoming warnings in MySQL 5.6, 5.7 for BLOB columns

[Michael Bayer]

hey all -

Just looking to see if we think this will impact openstack.  MySQL 5.6
and 5.7, but not yet MariaDB, now emits an erroneous warning when you
try to send a binary value to the database, because it sees the client
connection is supposed to use the utf8 or utf8mb4 charsets, assumes
all data must be in that charset, then warns because the binary data
does not necessarily conform to utf8 (which it has no need to, it's
binary).

Sounds weird, right, to make it easier the demo looks just like this:

import pymysql
import uuid

conn = pymysql.connect(
user="scott", passwd="tiger", host="mysql56",
db="test", charset="utf8mb4")
cursor = conn.cursor()
cursor.execute("""
CREATE TABLE IF NOT EXISTS `profiles` (
  `id` varchar(32) COLLATE utf8mb4_unicode_ci NOT NULL,
  `city` blob NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
""")
cursor.execute(
"INSERT INTO profiles (id, city) VALUES (%(id)s, %(city)s)",
{
'id': uuid.uuid4().hex,
'city': pymysql.Binary(

b'z\xf9\x87jS?\xd4i\xa5\xa3\r\xa7\x1e\xed\x16\xe0\xb5\x05R\xa4\xec\x16\x8f\x06\xb5\xea+\xaf<\x00\\\x94I9A\xe0\x82\xa7\x13\x0c\x8c'
)
}
)

when using PyMySQL 0.8.0 (not 0.7.1) you then get a warning

Warning: (1300, "Invalid utf8mb4 character string: 'F9876A'").


So, Oracle upstream clearly is never going to fix this if you look at
the typically dismal discussion at [1].   I poked the PyMySQL project
at [2] to see what we can do.   Long term is that SQLAlchemy will add
the special "_binary" prefix to binary-bound parameter tokens to avoid
the warning, however right now PyMySQL supports a flag "binary_prefix"
that will do it for us on the driver side.

For Openstack, i need to know if we are in fact passing binary data to
databases in some project or another.   What we can do is add the
supply of this flag to oslo.db so that it is present automatically for
the PyMySQL driver, as well as checking the PyMySQL version for
compatibility.

If folks are seeing this warning already or are using BLOB / binary
columns in their project please ping me and we will get this added to
oslo.db.

__
OpenStack Development Mailing 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][Bifrost] Manually enrolling a node

[Michael Still]

I think one might be a bug in the deploy guide then. It states:

"In order for nodes to be available for deploying workloads on them, nodes
must be in the available provision state. To do this, nodes created with
API version 1.11 and above must be moved from the enroll state to the
manageable state and then to the available state. This section can be
safely skipped, if API version 1.10 or earlier is used (which is the case
by default)."

Whereas I definitely had to move the node to the manage provision state
manually to get the node to be managed. For reference, this is the set of
command lines I ended up using to manually enroll a node (in case its of
use to someone else):

ironic node-create -d agent_ipmitool \
  -i ipmi_username=root \
  -i ipmi_password=superuser \
  -i ipmi_address=192.168.50.31 \
  -i deploy_kernel=http://192.168.50.209:8080/ipa.vmlinuz \
  -i deploy_ramdisk=http://192.168.50.209:8080/ipa.initramfs \
  -p cpus=16 \
  -p memory_mb=12288 \
  -p local_gb=750 \
  -p cpu_arch=x86_64 \
  -p capabilities=boot_option:local \
  -n lab8
ironic port-create -n ${UUID}  -a ${DHCP_MAC}
ironic node-validate lab8
ironic --ironic-api-version 1.11 node-set-provision-state lab8 manage

Michael

On Mon, Mar 5, 2018 at 9:05 AM, Mark Goddard <m...@stackhpc.com> wrote:

> On the enroll state, you can move it to available via manageable by
> setting the provision state to manage, then provide.
>
> Try an ironic node-validate to diagnose the issue, and make sure the ipmi
> credentials given can be used to query the nodes power state using ipmitool.
>
> Mark
>
> On 4 Mar 2018 9:42 p.m., "Mark Goddard" <m...@stackhpc.com> wrote:
>
>> Try setting the ironic_log_dir variable to /var/log/ironic, or setting
>> [default] log_dir to the same in ironic.conf.
>>
>> I'm surprised it's not logging to a file by default.
>>
>> Mark
>>
>> On 4 Mar 2018 8:33 p.m., "Michael Still" <mi...@stillhq.com> wrote:
>>
>>> Ok, so I applied your patch and redeployed. I now get a list of drivers
>>> in "ironic driver-list", and I can now enroll a node.
>>>
>>> Interestingly, the node sits in the "enroll" provisioning state for ages
>>> and doesn't appear to ever get a meaningful power state (ever being after a
>>> five minute wait). There are still no logs in /var/log/ironic, and grepping
>>> for the node's uuid in /var/log/syslog returns zero log items.
>>>
>>> Your thoughts?
>>>
>>> Michael
>>>
>>>
>>>
>>> On Mon, Mar 5, 2018 at 7:04 AM, Mark Goddard <m...@stackhpc.com> wrote:
>>>
>>>> The ILO hardware type was also not loading because the required
>>>> management and power interfaces were not enabled. The patch should address
>>>> that but please let us know if there are further issues.
>>>> Mark
>>>>
>>>>
>>>> On 4 Mar 2018 7:59 p.m., "Michael Still" <mi...@stillhq.com> wrote:
>>>>
>>>> Replying to a single email because I am lazier than you.
>>>>
>>>> I would have included logs, except /var/log/ironic on the bifrost
>>>> machine is empty. There are entries in syslog, but nothing that seems
>>>> related (its all periodic task kind of stuff).
>>>>
>>>> However, Mark is right. I had an /etc/ironic/ironic.conf with "ucs" as
>>>> a hardware type. I've removed ucs entirely from that list and restarted
>>>> conductor, but that didn't help. I suspect https://review.opensta
>>>> ck.org/#/c/549318/3 is more subtle than that. I will patch in that
>>>> change and see if I can get things to work after a redeploy.
>>>>
>>>> Michael
>>>>
>>>>
>>>>
>>>> On Mon, Mar 5, 2018 at 5:45 AM, Mark Goddard <m...@stackhpc.com> wrote:
>>>>
>>>>> Hi Michael,
>>>>>
>>>>> If you're using the latest release of biifrost I suspect you're
>>>>> hitting https://bugs.launchpad.net/bifrost/+bug/1752975. I've
>>>>> submitted anfox for review.
>>>>>
>>>>> For a workaround, modify /etc/ironic/ironic.conf, and set
>>>>> enabled_hardware_types=ipmi.
>>>>>
>>>>> Cheers,
>>>>> Mark
>>>>>
>>>>> On 4 Mar 2018 5:50 p.m., "Julia Kreger" <juliaashleykre...@gmail.com>

Re: [openstack-dev] [Ironic][Bifrost] Manually enrolling a node

[Michael Still]

Ahhh yes. The default (null) value of ironic_log_dir doesn't do quite what
the author thought it did. https://review.openstack.org/549650 is a patch
to correct that.

Michael

On Mon, Mar 5, 2018 at 8:42 AM, Mark Goddard <m...@stackhpc.com> wrote:

> Try setting the ironic_log_dir variable to /var/log/ironic, or setting
> [default] log_dir to the same in ironic.conf.
>
> I'm surprised it's not logging to a file by default.
>
> Mark
>
> On 4 Mar 2018 8:33 p.m., "Michael Still" <mi...@stillhq.com> wrote:
>
>> Ok, so I applied your patch and redeployed. I now get a list of drivers
>> in "ironic driver-list", and I can now enroll a node.
>>
>> Interestingly, the node sits in the "enroll" provisioning state for ages
>> and doesn't appear to ever get a meaningful power state (ever being after a
>> five minute wait). There are still no logs in /var/log/ironic, and grepping
>> for the node's uuid in /var/log/syslog returns zero log items.
>>
>> Your thoughts?
>>
>> Michael
>>
>>
>>
>> On Mon, Mar 5, 2018 at 7:04 AM, Mark Goddard <m...@stackhpc.com> wrote:
>>
>>> The ILO hardware type was also not loading because the required
>>> management and power interfaces were not enabled. The patch should address
>>> that but please let us know if there are further issues.
>>> Mark
>>>
>>>
>>> On 4 Mar 2018 7:59 p.m., "Michael Still" <mi...@stillhq.com> wrote:
>>>
>>> Replying to a single email because I am lazier than you.
>>>
>>> I would have included logs, except /var/log/ironic on the bifrost
>>> machine is empty. There are entries in syslog, but nothing that seems
>>> related (its all periodic task kind of stuff).
>>>
>>> However, Mark is right. I had an /etc/ironic/ironic.conf with "ucs" as a
>>> hardware type. I've removed ucs entirely from that list and restarted
>>> conductor, but that didn't help. I suspect https://review.opensta
>>> ck.org/#/c/549318/3 is more subtle than that. I will patch in that
>>> change and see if I can get things to work after a redeploy.
>>>
>>> Michael
>>>
>>>
>>>
>>> On Mon, Mar 5, 2018 at 5:45 AM, Mark Goddard <m...@stackhpc.com> wrote:
>>>
>>>> Hi Michael,
>>>>
>>>> If you're using the latest release of biifrost I suspect you're hitting
>>>> https://bugs.launchpad.net/bifrost/+bug/1752975. I've submitted anfox
>>>> for review.
>>>>
>>>> For a workaround, modify /etc/ironic/ironic.conf, and set
>>>> enabled_hardware_types=ipmi.
>>>>
>>>> Cheers,
>>>> Mark
>>>>
>>>> On 4 Mar 2018 5:50 p.m., "Julia Kreger" <juliaashleykre...@gmail.com>
>>>> wrote:
>>>>
>>>>> > No valid host was found. Reason: No conductor service registered
>>>>> which
>>>>> > supports driver agent_ipmitool. (HTTP 400)
>>>>> >
>>>>> > I can't see anything helpful in the logs. What driver should I be
>>>>> using for
>>>>> > bifrost? agent_ipmitool seems to be enabled in ironic.conf.
>>>>>
>>>>> Weird, I'm wondering what the error is in the conductor log. You can
>>>>> try using "ipmi" for the hardware type that replaces
>>>>> agent_ipmitool/pxe_ipmitool.
>>>>>
>>>>> -Julia
>>>>>
>>>>> 
>>>>> __
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe: openstack-dev-requ...@lists.op
>>>>> enstack.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.op
>>>> enstack.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.op
>>