Re: [openstack-dev] [nova] gate "gate-nova-python27-db" is broken due to oslo.context 2.6.0

Hi All, For Oslo libraries we ensure that API's are backward compatible for 1+ releases. When an Oslo API adds a new class attribute (as in this example of is_admin_project and 4 other attributes) added to Oslo Context in 2.6.0, these are added to ensure this API is also forward compatible with

Re: [Openstack-operators] Next Ops Midcycle NYC August 25-26

NYC is obviously expensive for hotels generally. I have stayed at various locations and also organized accommodations for people before. Just last week a colleague shared a great price for a centrally located and reasonable quality hotel he stayed at. I thought I would pass on the info. -- I

Re: [Openstack-operators] User Survey usage of QEMU (as opposed to KVM) ?

king) QEMU: Checking for device /dev/net/tun : PASS LXC: Checking for Linux >= 2.6.26 : PASS Ronald Bradford Web Site: http://ronaldbradford.com LinkedIn: http://www.linkedin.com/in/ronaldbradford Twitter:@RonaldBradford <http://twitter.com/ronaldbradford> Skype: RonaldB

Re: [Openstack-operators] Debug logging

As Matt discussed, there is a push to better identify debug messages (and the packages) that are important to operators. In a subsequent session it was discussed about creating etherpads to make it easier to identify DEBUG messages that are in use and important for analysis, and for ease of

Re: [openstack-dev] [oslo] Backwards compatibility policy

This was a good session lead by Robert to fully understand the repercussions of not ensuring backward compatibility guidelines. In layman's terms, an Oslo API change made in Mitaka (the last release) must remain fully backward compatible throughout the entire Newton release (the current release).

Re: [openstack-dev] [oslo] Removing Nova specifics from oslo.log

regarding our work with Nova to enhance usage of resource uuids that will enable some subsequent deprecated usage of instance specific context and kwargs, but this requires some pre-requisite work. Regards Ronald Ronald Bradford Web Site: http://ronaldbradford.com LinkedIn: http

Re: [openstack-dev] [oslo] oslo.context and name fields

Sean, I've taken your WIP https://review.openstack.org/#/c/302744/ a step forward and its in review now. I'd value Jamie's input on your proposed from_environ signature change to see if that does meet his indented goal. Regards Ronald Ronald Bradford Web Site: http://ronaldbradford.com

Re: [openstack-dev] [oslo] oslo.context and name fields

I have created a version that use constructor arguments. [5] I will review in more detail across projects the use of keystone middleware to see if we can utilize a constructor environment attribute to simply constructor usage. [5] https://review.openstack.org/301918 Ronald Bradford Web Site

Re: [openstack-dev] [oslo] oslo.context and name fields

Sean, I cannot speak to historically why there were not there, but I am working through the app-agnostic-logging-parameters blueprint [1] right now and it's very related to this. As part of this work I would be reviewing attributes that are more commonly used in subclassed context objects for

Re: [openstack-dev] [docs] Our Install Guides Only Cover Defcore - What about big tent?

The only downside I see of these examples are there is no way in the documentation to determine the release version or cycle. (i.e. you have to read the contents in conjunction with the URL). Ronald Bradford Web Site: http://ronaldbradford.com LinkedIn: http://www.linkedin.com

Re: [openstack-dev] [kite] Seeking core reviewers

Thanks Doug. I've shortened your workload a bit -- http://lists.openstack.org/pipermail/openstack-dev/2016-March/090491.html Ronald Bradford Web Site: http://ronaldbradford.com LinkedIn: http://www.linkedin.com/in/ronaldbradford Twitter:@RonaldBradford <http://twitter.com/ronaldbradf

[openstack-dev] [kite][barbican] Notice to retire kite and python-kiteclient projects

>From the initial ML discussion [1], the following are instructions to retire a project [2]. The kite and python_kiteclient projects are moving to a non maintained status. First is the removal of project gates. [3] Second is updating code repos, [4],[5]. See README for how code can still be

Re: [openstack-dev] [kite] Seeking core reviewers

Thanks all for feedback. I have proposed a non maintained patch [1] based on comments here. I will speak with the Barbican team. Ronald [1] https://review.openstack.org/#/c/297719/ Ronald Bradford Web Site: http://ronaldbradford.com LinkedIn: http://www.linkedin.com/in/ronaldbradford

[openstack-dev] [kite] Seeking core reviewers

As part of the initiative to replace all legacy Oslo Incubator code in OpenStack with graduate libraries we are working through all projects. I have been unable to find any IRC contact information on the wiki or kite-core group in order to help with several reviews [1] for the project. Any

Re: [openstack-dev] [chef] ec2-api cookbook

Samuel, Could you detail when your IRC meeting is, [1] indicates it's on Tuesdays. [1] https://wiki.openstack.org/wiki/Meetings/EC2API Regards Ronald On Thu, Mar 24, 2016 at 1:36 PM, Samuel Cassiba wrote: > On Thu, Mar 24, 2016 at 3:33 AM, Anastasia Kravets

Re: [openstack-dev] [glance] Glance Mitaka: Passing the torch

I am not involved in Glance, however this was well worth reading for the experiences during the cycle, not just as a PTL but as a team and the communication of improving the software development process. On Wed, Mar 9, 2016 at 11:47 PM, Bhandaru, Malini K < malini.k.bhand...@intel.com> wrote:

Re: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka

at any location. My 2 cents to making this type of event even better next time. Ronald Bradford Web Site: http://ronaldbradford.com LinkedIn: http://www.linkedin.com/in/ronaldbradford Twitter:@RonaldBradford <http://twitter.com/ronaldbradford> Skype: RonaldBradford

Re: [openstack-dev] [Openstack-operators] [glance] Remove `run_tests.sh` and `tools/*`

+1 from me. I am all for standardizing this. Personally when I started looking at OpenStack code as new contributor this was very confusing with the online docs that listed run_tests.sh but the first project I looked at, this didn't exist and it was all tox based. I went on to blog about my

Re: [openstack-dev] [oslo] PTL for Newton and beyond

Dims, As my first project and cycle in OpenStack I have really appreciated your input and direction as I was starting out and during Mitaka cycle. It has been great to learn just a bit of what PTL of Oslo is and does, so thanks for all your hard work. I hope I can work with the team to help turn

Re: [openstack-dev] [docs] Can we get the "configuration reference" of master more often?

On Thu, Mar 3, 2016 at 9:51 AM, Andreas Jaeger wrote: > On 2016-03-03 15:37, Markus Zoeller wrote: > > The "configuration reference" manual at [1] is really helpful to get > > an overview of the options and we (Nova folks) were wondering if we > > could have that updated more

Re: [openstack-dev] [oslo][all] Documenting configuration options lifespan

> > * When an option is changed, or marked as deprecated, during normal > reviews > > it should then be identified accordingly with these new attributes. > > * The "changed" attribute would only be applicable moving forward with a > > developer change in default value, ranges etc (changing help

[openstack-dev] [oslo][all] Documenting configuration options lifespan

After evaluation of oslo-config-generator and one of it's common uses by operators in configuration option evaluation with upgrades, I am proposing adding some meta data for all configuration options to provide better applicable documentation as projects continue to evolve. I can see an easier

Re: [openstack-dev] [oslo] documentation on using the oslo.db opportunistic test feature

> > > > 1) Being able to do a grant with a prefix like > > GRANT all on 'openstack_ci%'.* to openstack_citest > > Then using that prefix in the random db generation. That would at least > limit scope. That seems the easiest to do with the existing infrastructure. > To use this syntax correctly in

[openstack-dev] [oslo][doc][all] Removal of deprecate oslo.og log_format configuration option

The deprecated log_format option is being removed [1] This option can be found across many projects generally in sample configuration files [2]. These should be automatically removed if these files are auto generated via oslo-config-generator or in sphinx generated documentation. In other

Re: [openstack-dev] [oslo][all] Announcing our new Olso Project

For the #OpenStack Mitaka M3 freeze and final release we have made it even easier to play and win Oslo Bingo. Simply pick the next release word. Free entry at http://j.mp/Oslo-bingo-Mitaka Follow the results on Twitter - https://twitter.com/OsloBingo Ronald Bradford Web Site: http

Re: [openstack-dev] [all] tenant vs. project

mixture of terms. [1] http://docs.openstack.org/developer/oslo.log/opts.html Ronald Bradford Web Site: http://ronaldbradford.com LinkedIn: http://www.linkedin.com/in/ronaldbradford Twitter:@RonaldBradford <http://twitter.com/ronaldbradford> Skype: RonaldBradford

Re: [openstack-dev] [all] the trouble with names

that the translation is internal with us developers. We should be able to live with that. #2 IMO opinion serves best what OpenStack software is used for, and who it is designed for. Ronald Bradford Web Site: http://ronaldbradford.com LinkedIn: http://www.linkedin.com/in/ronaldbradford Twitter

[openstack-dev] [oslo][doc][fuel] Removal of logging use_syslog_rfc_format configuration option

In Mitaka we are planning on removing the deprecated logging configuration option use_syslog_rfc_format [1] Matches in openstack-manuals [2] and fuel-library puppet modules [3] should be removed to avoid any dated documentation or errors in operation respectively. This option can also be found

[openstack-dev] [oslo][all] Announcing our new Olso Project

The Olso team is proud to announce the release of Oslo Bingo. In Oslo we like to spice up our release notes using meaningful random adjectives [1]. Each month the Oslo team will select an adjective to be the Oslo Bingo word of the month. For February 2016 we have selected "jazzed" (from

Re: [openstack-dev] [Oslo] Improving deprecated options identification and documentation

Markus, > > Yes, in what release it is to be removed, e.g. Mitaka. So when is > > that release cycle, i.e. now once removed there is no record. > > The information at which point in time a removal will happen can be > derived from a combination of: > * the "Deprecation Notes" (e.g. Nova's at

Re: [openstack-dev] [Oslo] Improving deprecated options identification and documentation

On Thu, Jan 14, 2016 at 11:58 AM, Jay Pipes <jaypi...@gmail.com> wrote: > On 01/14/2016 11:45 AM, Ronald Bradford wrote: >> >> Presently the oslo.config Opt class has the attributes >> deprecated_for_removal and deprecated_reason [1] >> >> I would like t

[openstack-dev] [Oslo] Improving deprecated options identification and documentation

Presently the oslo.config Opt class has the attributes deprecated_for_removal and deprecated_reason [1] I would like to propose that we use deprecated_reason (at a minimum) to detail in what release an option was deprecated in, and what release it is then removed in. I see examples of

Re: [openstack-dev] [devstack][QA] Changing logging format to match documented defaults

Ian, On Tue, Dec 22, 2015 at 3:22 PM, Ian Wienand <iwien...@redhat.com> wrote: > > On 12/23/2015 05:55 AM, Ronald Bradford wrote: > > I have observed that devstack uses custom logging formatting that > > differs from the documented defaults. An example is for nova. wh

[openstack-dev] [devstack][QA] Changing logging format to match documented defaults

Hi All, I have observed that devstack uses custom logging formatting that differs from the documented defaults. An example is for nova. logging_context_format_string = %(asctime)s.%(msecs)03d %(levelname)s %(name)s [%(request_id)s *%(user_name)s %(project_name)s*] %(instance)s%(message)s which

[openstack-dev] [all] Reviewing code coverage syntax/use across projects

As part of reviewing the code coverage on various projects I have found that a number had failing coverage jobs when not configured correctly (many also work just fine). Starting initially in various Oslo projects my goal has been to just ensure coverage is defined, runs without errors and is

[openstack-dev] [Infra][Cross Project] Proposing a centralized location for code coverage reports

Hi All, In last week's Cross Project IRC meeting [1] I sought to determine the merits and feasibility of having a central web location for code coverage of various/all OpenStack projects. Presently a few projects add code coverage as a non-voting gate and that provides a per-commit viewing

Re: [openstack-dev] [openstackclient] Use and practices of --format shell for defining individual variables

Thanks Doug, I knew there would be a more definitive and simple use. eval is that way! Ronald Ronald Bradford Web Site: http://ronaldbradford.com LinkedIn: http://www.linkedin.com/in/ronaldbradford Twitter:@RonaldBradford http://twitter.com/ronaldbradford Skype: RonaldBradford GTalk

[openstack-dev] [openstackclient] Use and practices of --format shell for defining individual variables

Hi list, I came across the following neutron client specific syntax and decided to see if I could reproduce using the openstack client and it's flexible formatting capabilities $ NIC_ID1=$(neutron net-show public | awk '/ id /{print $4}') $ echo $NIC_ID1 210d976e-16a3-42dc-ac31-f01810dbd297

Re: [openstack-dev] [openstackclient] [magnum] Review of object and actions for magnumclient implementation

unusable as more clients which it integrate. Regards Ronald Ronald Bradford Web Site: http://ronaldbradford.com LinkedIn: http://www.linkedin.com/in/ronaldbradford Twitter:@RonaldBradford http://twitter.com/ronaldbradford Skype: RonaldBradford GTalk: Ronald.Bradford IRC

[openstack-dev] [openstackclient] [magnum] Review of object and actions for magnumclient implementation

I have outlined in the blueprint ( https://blueprints.launchpad.net/python-openstackclient/+spec/magnum-support) the object and actions mappings that are currently available in the magnumclient. I have separated the list of actions that are presently used and actions that are not for review and

Re: [openstack-dev] [all] Replace mysql-python with mysqlclient

: 4bca3815f5856ddf4a629b418ec76c8f Homepage: http://dev.mysql.com/doc/connector-python/en/index.html Bugs: https://bugs.launchpad.net/ubuntu/+filebug Origin: Ubuntu Ronald Bradford Web Site: http://ronaldbradford.com LinkedIn: http://www.linkedin.com/in/ronaldbradford Twitter: @RonaldBradford http://twitter.com

Re: [openstack-dev] [all] Replace mysql-python with mysqlclient

contacts in the MySQL engineering and Oracle Corporation product development teams I will endeavor to seek a more current and definitive response and statement. Regards Ronald On Fri, May 8, 2015 at 10:33 AM, Ronald Bradford m...@ronaldbradford.com wrote: Has anybody considered the native

Re: [openstack-dev] Navigating the ever changing OpenStack codebase

Thanks again for the clarification. Your initial --notests was an option I was unaware of and I didn't take the time to try variations. I was familiar with invoking test names by regex I just thought it was more a convention. Regards Ronald On Tue, Apr 28, 2015 at 2:48 PM, Doug Hellmann

Re: [openstack-dev] Navigating the ever changing OpenStack codebase

-with-tox-2015-04-28/ 01010010 0110 01101110 0111 01101100 01100100 0010 0110 01110010 0111 01100100 01100110 0110 01110010 01100100 *Ronald Bradford* MySQL Expert specializing in Performance Tuning, Scalability and High Availability Lead Author - Effective MySQL: Replication

[openstack-dev] Navigating the ever changing OpenStack codebase

Hi All, I have recently become involved in OpenStack development. After installing a few devstacks (and buying some H/W for my own physical cloud) I settled into learning, reviewing and debugging the Python OpenStack Client (seemed an easy access point). I even published a blog post just 7 days