Jump to: navigation, search

Difference between revisions of "Oslo/GraduationStatus"

Line 641: Line 641:
== oslo.vmware ==
== oslo.vmware ==
TODO : Need to fill this in
== To Be Deleted ==
== To Be Deleted ==

Revision as of 21:16, 3 February 2014

Oslo Library Graduation Status


bp: https://blueprints.launchpad.net/oslo/+spec/graduate-oslo-cache


M: Flavio Percoco <flavio@redhat.com> M: Morgan Fainberg <m@metacloud.com> S: Maintained F: cache/

Depends on: py3kcompat, lockutils, timeutils


S: Orphan
F: memorycache.py
Depends on: timeutils


bp: https://blueprints.launchpad.net/oslo/+spec/graduate-oslo-client


M: Alessio Ababilov <aababilov@griddynamics.com>
S: Maintained
F: apiclient/
Depends on: py3kcompat, strutils, importutils


bp: https://blueprints.launchpad.net/oslo/+spec/graduate-oslo-concurrency


M: Michael Still <mikal@stillhq.com>
S: Maintained
F: lockutils.py
Depends on: oslo.config, fileutils, gettextutils, log

This seems pretty stable now. I see no reason it couldn't be released as a library.

Comments from bnemec via ML:

 It would be nice to get lockutils graduated to solve some of the issues mentioned in the oslo.db section, but I believe we do have an outstanding question regarding its behavior without lock_path being set.  I think Clint was on board with Sean's proposed solution after quite a bit of discussion (http://lists.openstack.org/pipermail/openstack-dev/2013-December/021620.html), so it's possible we could just restore that patch and call it done, but it should probably be addressed somehow before graduation.

TODO: Remove the dependency of fixture on lockutils by moving fixture/lockutils.py into oslo.concurrency


M: Michael Still <mikal@stillhq.com>
S: Maintained
F: processutils.py
Depends on: gettextutils, log

change status from maintained?

needs some code cleanup (greenthreads and random sleeps)



M: Mark McLoughlin <markmc@redhat.com>
S: Maintained
F: cfgfilter.py
Depends on: oslo.config

bp: https://blueprints.launchpad.net/oslo/+spec/graduate-cfgfilter

Moved to oslo.config, remove from this list? - dhellmann

keep for filter


M: Julien Danjou <julien@danjou.info>
M: Zhongyue Luo <zhongyue.nah@intel.com>
S: Maintained
F: config/
Depends on: oslo.config, gettextutils, importutils

bp: https://blueprints.launchpad.net/oslo/+spec/graduate-config-generator

This is far from being optimal, but it's the best we can do. There's a lot of problem with some stuff like dynamically registered option, but I'm not sure we can really do anything about it.

We will be talking about this issue at the summit

  1. http://summit.openstack.org/cfp/details/258
  2. http://summit.openstack.org/cfp/details/125



M: Simo Sorce <simo@redhat.com>
S: Maintained
F: crypto/
Depends on: gettextutils, importutils

bp: https://blueprints.launchpad.net/oslo/+spec/graduate-oslo-crypto

KDS's REST API is being slightly changed after review by the Keystone developers. This will require some minor changes to the SecureMessage internal code used to fetch and tickets from the KDS.

This code will be used in oslo.messaging and keystone (markmc)

Should it eventually live in oslo.crypto or should it be part of a library that the keystone devs maintain? - dhellmann

It is mostly used in KDS to encrypt keys before storage and in this capacity it should be reusable for swift/cinder or projects looking to do encrypted storage. It's fairly low level at the moment but a simpler interface to this can be added when there is reuse of the module. --jamielennox


bp: https://blueprints.launchpad.net/oslo/+spec/oslo-db-lib


M: Boris Pavlovic <boris@pavlovic.me>
M: Roman Podolyaka <rpodolyaka@mirantis.com>
M: Victor Sergeyev <vsergeyev@mirantis.com>
S: Maintained
F: db/
Depends on: importutils, timeutils, gettextutils, log, py3kcompat

On the API side we've been pretty stable so far.

The big code changes worth mentioning are:

   - using of [database] group for DB options instead of [DEFAULT] (must be handled gracefully by oslo.config deprecated_name|group options)
   - new convention for naming of unique constraints (it's needed for providing developers with informative exceptions on integrity errors)
   - support of slave engines (the ability to distribute SELECT queries among slave DBs -- this only extends the existing API a bit)
   - moving of useful sqlalchemy and migrations utils developed in Nova to common code

It would be nice to complete these tasks before making common db code a separate library, but they aren't blockers in any way:


openstack.common.db should become a separate library - oslo.db We did a PoC a few months ago - (https://review.openstack.org/#/c/42159/) Ironic test suite passed when oslo.db was installed as a separate library (https://github.com/malor/oslo.db)

The challenge with making oslo.db a separate library is that common modules we use (e.g. lockutils) might possibly conflict with the ones in OpenStack projects due to defining the same oslo.config options, but having different definitions for those (e.g. oslo.config raised an exception, because lockutils version in Ironic had a config option, that didn't provide a help string, but the newer version of lockutils, we used in oslo.db, did)

Move lockutils out of incubation first? - dhellmann

db api must be cleaned up to remove the eventlet dependency before graduating

needs to be synced with nova's version



M: Andrey Kurilin <akurilin@mirantis.com>
S: Maintained
F: hooks.py
Depends on: gettextutils, log


bp: https://blueprints.launchpad.net/oslo/+spec/graduate-oslo-i18n


M: Mark McLoughlin <markmc@redhat.com>
S: Maintained
F: gettextutils.py
Depends on: (none)

I think this is mostly being maintained by the various folks working on delayed-message-translation now (markmc)

Set a goal to have this ready to move out of the incubator during J? - dhellmann


bp: https://blueprints.launchpad.net/oslo/+spec/graduate-oslo-image


M: Zhongyue Luo <zhongyue.nah@intel.com>
S: Maintained
F: imageutils.py
Depends on: gettextutils, strutils

This module has just been added. Next steps are to add common image manipulation helper functions used in Nova and Cinder.


bp: https://blueprints.launchpad.net/oslo/+spec/graduate-oslo-io


M: Zhongyue Luo <zhongyue.nah@intel.com>
S: Maintained
F: fileutils.py
Depends on: excutils, gettextutils, log

There are still changes being made to function signatures to meet the needs of mocking when writing test scripts. Needs a cycle or two.


bp: https://blueprints.launchpad.net/oslo/+spec/graduate-oslo-language


S: Orphan
F: importutils.py
Depends on: (none)

Deprecate the functions replaced by stevedore & pkg_resources? the try_import() function looks trivial, do we need it? - dhellmann


M: Chuck Short <chuck.short@canonical.com>
S: Maintained
F: py3kcompat
Depends on: (none)

I'm going to move all that code into six -- Julien Danjou


M: S: Orphan F: excutils.py

Depends on: gettextutils

Other than its use of our gettextutils, this could be pulled out into a separate library without needing the oslo name. - dhellmann

can we use the stdlib? should we remove the translations? (2 messages)

look for similar code elsewhere

contribute to stdlib?

  1. How do we handle translations for the log messages if this goes into its own lib?


M: Joshua Harlow <harlowja@yahoo-inc.com>
S: Maintained
F: funcutils.py
Depends on: (none)


bp: https://blueprints.launchpad.net/oslo/+spec/graduate-oslo-local


S: Orphan
F: local.py
Depends on: (none)


bp: https://blueprints.launchpad.net/oslo/+spec/graduate-oslo-log


S: Orphan
F: log.py
Depends on: oslo.config, gettextutils, importutils, jsonutils, local

flaper87: Agreed!

TODO: Change handling of publish_errors configuration option so the log_handler module isn't imported with importutils, since that module is moving to oslo.messaging and we do not want a circular dependency.

TODO: Install the formatter to do translation, but don't require everyone to use the ContextAdapter, so we can remove dependencies on this lib from other libs.



S: Orphan
F: log.py
Depends on: oslo.config, notifier

bp: https://blueprints.launchpad.net/oslo/+spec/graduate-notifier-log-handler


M: Julien Danjou <julien@danjou.info>
S: Maintained
F: notifier/
F: middleware/notifier.py
Depends on: context, gettextutils, importutils, jsonutils, log, timeutils, rpc

bp: https://blueprints.launchpad.net/oslo/+spec/graduate-notifier-middleware

Will be in oslo.messaging and removed from incubator in icehouse (markmc) http://docs.openstack.org/developer/oslo.messaging/notifier.html


M: Mark McLoughlin <markmc@redhat.com>
M: Russell Bryant <rbryant@redhat.com>
S: Maintained
F: rpc/
Depends on: gettextutils, excutils, importutils, jsonutils, local, log, network_utils, rpc, service, sslutils, versionutils

bp: https://blueprints.launchpad.net/oslo/+spec/remove-rpc-from-incubator

Will be moving projects from this to oslo.messaging in Icehouse so that this can be removed (markmc)


M: Mike Wilson <geekinutah@gmail.com>
M: Paul Mathews <pmathews@bluehost.com>
S: Maintained
F: rpc/impl_zmq.py
F: rpc/matchmaker*.py
F: rpc/zmq_receiver.py

bp: https://blueprints.launchpad.net/oslo/+spec/graduate-zmq-driver

Moving to oslo.messaging (markmc)


bp: https://blueprints.launchpad.net/oslo/+spec/graduate-oslo-middleware


M: Gordon Chung <chungg@ca.ibm.com>
S: Maintained
F: middleware/audit.py
Depends on: (none)

this middleware is relatively lightweight as it utilises notifier middleware to handle most of the actions... outside of that it uses only pycadf library to append audit info. currently making improvements to pycadf library... we have plans to extend its functionality but the overall model is relatively stable. (ref: https://launchpad.net/pycadf)


S: Orphan
F: middleware/
Depends on: gettextutils, log, context, notifier


bp: https://blueprints.launchpad.net/oslo/+spec/graduate-oslo-policy


M: Flavio Percoco <flavio@redhat.com>
M: Adam Young <ayoung@redhat.com>
S: Maintained
F: policy.py

Depends on: fileutils, gettextutils, jsonutils, log, oslo.config

We could get rid of the oslo.config dependency.

(Agreed on the stability of policy.py)


bp: https://blueprints.launchpad.net/oslo/+spec/graduate-oslo-quota


M: Sergey Skripnick <sskripnick@mirantis.com>
S: Maintained
F: quota.py
Depends on: gettextutils, importutils, log, timeutils
This file is merged from nova and cinder, but not used in any project yet.


bp: https://blueprints.launchpad.net/oslo/+spec/graduate-oslo-reports


M: Solly Ross <sross@redhat.com>
S: Maintained
F: report/
Depends on: jsonutils

Where is this being used? - dhellmann

We are planning to use the pattern and some of the code here for Ceilometer reporting. Most of the existing stuff is pretty specific to the Guru Mediation Report, it looks like. Link: https://wiki.openstack.org/wiki/OutreachProgramForWomen/Ideas#Reporting_Framework_for_Ceilometer_based_on_Oslo_Reporting - thomasem


bp: https://blueprints.launchpad.net/oslo/+spec/standalone-rootwrap


M: Thierry Carrez <thierry@openstack.org>
S: Maintained
F: rootwrap/
Depends on: (none)

Move to separate bin/lib was blocked on the question of supporting running python snippets as root (in addition to shelling out) which would break the ability to use plain "sudo" rather than rootwrap. That said with the performance issues of using rootwrap, the ability to run under direct "sudo" is seen as a feature rather than legacy. So we could go and push rootwrap as standalone during Icehouse. I'd like to have a last discussion (at the rootwrap session in HK) on perf issues and alternate solutions -- I don't want a move to standalone rootwrap to make any alternative solution more difficult.

will become oslo.rootwrap (see Thierry's other session notes)


bp: https://blueprints.launchpad.net/oslo/+spec/graduate-oslo-serialization


S: Orphan
F: jsonutils.py
Depends on: gettextutils, importutils, timeutils


S: Orphan
F: xmlutils.py
Depends on: (none)

This was a security fix. Can we rely on our dependencies having this fix now? - dhellmann


bp: https://blueprints.launchpad.net/oslo/+spec/graduate-oslo-server


S: Orphan
F: eventlet_backdoor.py
Depends on: gettextutils, log

should eventually go into the service library (move in the incubator to the service stuff)


S: Orphan
F: loopingcall.py
Depends on: gettextutils, log, timeutils


M: Michael Still <mikal@stillhq.com>
S: Maintained
F: periodic_task.py
Depends on: gettextutils, log, timeutils

This one seems stable too.


M: Sandy Walsh <sandy.walsh@rackspace.com> S: Maintained F: request_utils.py

Depends on: gettextutils


M: Michael Still <mikal@stillhq.com>
S: Maintained
F: service.py
Depends on: eventlet_backdoor, gettextutils, importutils, log, threadgroup


S: Orphan
F: sslutils.py
Depends on: gettextutils


S: Orphan
F: threadgroup.py
Depends on: log, loopingcall


bp: https://blueprints.launchpad.net/oslo/+spec/graduate-oslo-test


M: Monty Taylor <mordred@inaugust.com>
S: Maintained
F: fixture/
Depends on: (none)

TODO: Remove the dependency on lockutils by moving fixture/lockutils.py into oslo.concurrency

TODO: Remove the dependency on oslo.config by moving fixture/config.py into oslo.config


S: Orphan
F: test.py
Depends on: (none)


bp: https://blueprints.launchpad.net/oslo/+spec/graduate-oslo-text


M: Flavio Percoco <flavio@redhat.com>
S: Maintained
F: strutils.py
Depends on: gettextutils

I think strutils is stable enough, however, I'd like to:

   1) Find a common place for this and other modules. I don't think it is worth having oslo.strutils. We once talk about having oslo.text and group strutils and other modules there.
   2) Make sure it's PY3K support. Even though python 3 support is not an OS requirement, this module should be fairly simple to port and we could have a voting PY3K gate for it. 

It may make sense to keep the encoding/decoding functions. to_slug() is used in the clients, maybe that can move to the new client section of the incubator? I would like to replace the units parsing code with another library if we can find one suitable. Pint does not have python 2.6 support, but would work other than that. - dhellmann



S: Orphan
F: units.py
Depends on: (none)


bp: https://blueprints.launchpad.net/oslo/+spec/graduate-oslo-utils


S: Orphan
F: network_utils.py
Depends on: py3kcompat

I'm trying to put these things in stdlib see http://bugs.python.org/issue18191 -- jd

won't graduate?


M: Zhongyue Luo <zhongyue.nah@intel.com>
S: Maintained
F: timeutils.py
Depends on: (none)

The problem with timeutils is that code for testing coexist. For example, IMO set_time_override should be removed and use mock or fixture to replace its functionality.

Do most of the functions here only apply for testing? The parsing and formatting functions may be useful, to ensure consistent timestamp formats.


M: Zhongyue Luo <zhongyue.nah@intel.com>
S: Maintained
F: uuidutils.py
Depends on: (none)

This module is stable.

Generating the UUID string seems trivial enough to not need a function. There is some work going into WSME to validate UUID strings at the API layer. Is the validation code used anywhere else? - dhellmann

nova uses this all over the place to check if a string is a uuid; can we move that function into nova and deprecate/delete this module?

neutron also uses the same function



S: Orphan
F: versionutils.py
Depends on: gettextutils, log

TODO: Break circular dependency between versionutils and log by moving deprecation logging function out of log and into versionutils.


TODO : Need to fill this in

To Be Deleted


S: Orphan
F: authutils.py

I found no users of this module outside of its tests under openstack/* It was apparently brought in from keystone by russelb - dhellmann

fixes a vulnerability using constant time string comparison

Added by https://review.openstack.org/6221

See https://bugs.launchpad.net/keystone/+bug/942644

Was strcmp_const_time() in Nova when Nova had its own auth code removed by https://review.openstack.org/9579

Swift uses it too (https://review.openstack.org/4643) but swift hates Oslo, so ....

 swift/common/utils.py:1866:def streq_const_time(s1, s2)

Conclusion: only keystone needs this, so we can remove it from oslo-incubator


S: Orphan
F: cliutils.py
Ignoring Depends on: apiclient, gettextutils, importutils, strutils, uuidutils

These functions should move into the python-openstackclient project, if they are still needed. - dhellmann


S: Obsolete
F: context.py
F: middleware/context.py

Deprecate? Delete?

delete, but look at the notifier code and logging -- also reviews in nova that were trying to rebase on top of this?

used in context middleware (markmc says delete) and rpc (obsoleted by oslo.messaging)


S: Orphan
F: scheduler/

boris-42: We should get rid of this. There is a way to build scalable one scheduler as a service. And solve a lot of current issues.