Loading…
Please note: This schedule is for OpenStack Active Technical Contributors participating in the Icehouse Design Summit sessions in Hong Kong. These are working sessions to determine the roadmap of the Icehouse release and make decisions across the project. To see the full OpenStack Summit schedule, including presentations, panels and workshops, go to http://openstacksummitnovember2013.sched.org.

Sign up or log in to bookmark your favorites and sync them to your phone or calendar.

Oslo [clear filter]
Tuesday, November 5
 

2:00pm

Creating REST services with Pecan/WSME
Now that we have a few projects using Pecan/WSME, let's talk about some best practices and pain points.

Outcomes for this session should include a list of patterns to use, ideas for common code to be added to an oslo library, and ideas for fixes or enhancements in Pecan and WSME.

https://etherpad.openstack.org/icehouse-oslo-pecan-wsme-tips

(Session proposed by Doug Hellmann)


Tuesday November 5, 2013 2:00pm - 2:40pm
AWE Level 2, Room 201B

2:50pm

OpenStack Client Update
Review the current status and plan the next steps for OpenStack Client (aka python-openstackclient).

* 0.2 release completed

* testing templates in place, now need to be replicated for each command
* Swift support
* API version detection


(Session proposed by Dean Troyer)


Tuesday November 5, 2013 2:50pm - 3:30pm
AWE Level 2, Room 201B

3:40pm

Updates to hacking, our code style enforcement tool
This session will include the following subject(s):

Unittests for openstack-dev/hacking:

The tests coverage of openstack-dev/hacking is very poor since docstring tests cannot cover all cases of violation. Lets have a chat about how we could write unittests for it.

(Session proposed by Zhongyue Luo)

Review and prune hacking rules:

We've had a full cycle of enforcement of the hacking guidelines now. While that's wonderful, it has become evident that some of them, like "use except Exception: not just except:" are either nonsensicle OR - do make sense but we do not have good verbage describing why.

I think we probably want to drop some of them from the guide and from enforcement, and additionally we should potentially think about adding MAY and MUST wording to hacking, so that we can include some informational best practices that we never attempt to enforce.

(Session proposed by Monty Taylor)


Tuesday November 5, 2013 3:40pm - 4:20pm
AWE Level 2, Room 201B
 
Wednesday, November 6
 

11:15am

I18n policies of messages
There are several kinds of messages in OpenStack, all in same domain, for example, log messages, API response messages, command line response messages, and so on.

This session will discuss the I18n policies to these messages. Following questions will be addressed in this session:

1. What kinds of messages are user facing messages? What messages are not user facing messages? What kinds of messages should be translated?
2. Does it need to separate messages into different domains? How to separate them into different domains?


(Session proposed by Ying Chun Guo)


Wednesday November 6, 2013 11:15am - 11:55am
AWE Level 2, Room 201B

12:05pm

oslo.messaging - API design, plans for Icehouse
The oslo.messaging API was designed and developed during the Havana cycle. The plan is to adopt it early in the Icehouse cycle.

This session will first review some of the key API design decisions to make sure we have a consensus on the design: http://docs.openstack.org/developer/oslo.messaging/

Then we will discuss our plans for Icehouse - adoption by all projects, removal of rpc from oslo-incubator, driver refactoring, completing the message security, a notifications client, a qpid/proton client, python3 support, etc.

(Some of the above may warrant a separate session if anyone cares to propose them)

See also: https://etherpad.openstack.org/HavanaOsloMessaging

(Session proposed by Mark McLoughlin)


Wednesday November 6, 2013 12:05pm - 12:45pm
AWE Level 2, Room 201B

2:00pm

oslo.config enhancements
This session will include the following subject(s):

Local conf objects and sample conf file generation:

As more projects started to interoperate in OpenStack, services are refraining use of global configuration objects and switching to local objects.

However this has an impact on generating sample config files, since the generator script relies on the global object. We have consensus that sample config files are needed but the overall coverage is regressing as more config objects are going local.

http://lists.openstack.org/pipermail/openstack-dev/2013-June/010315.html

Let discuss how we can manage to use local config objects and still identify all options.

(Session proposed by Zhongyue Luo)

Removing import-time side-effects from oslo.config:

Most apps use oslo.config by relying on options to be registered as code is loaded. Many modules throughout the OpenStack code base have blocks that import the global config object from oslo.config and then register options on the object. This means importing a module changes global state shared by the application, in a way that cannot be undone or reproduced by unit tests. This proposal describes a way to avoid having import-time side-effects while maintaining our current level of discoverability.

(Session proposed by Doug Hellmann)


Wednesday November 6, 2013 2:00pm - 2:40pm
AWE Level 2, Room 201B

2:50pm

Rootwrap: Icehouse plans
During the Havana cycle we focused on getting all consuming projects (Nova, Cinder, Neutron) to use the oslo-incubator version of rootwrap.

The next step now is to look into how those projects actually use rootwrap, and make improvements to that (on both sides). The current state is a bit sad with old configuration options still being used (I'm looking at you, Neutron and processutils), unrestrictive filters (the basic "CommandFilter" is used way too often), missing granularity (all volume drivers in Cinder share the same filter file) and commands being allowed as root while not strictly necessary (can achieve the same results without running as root so much). We'll discuss where to focus our efforts (nodes that could actually avoid all escalation mechanisms) and identify who would be interested to handle which area.

We'll also use this session to discuss potential replacements to rootwrap, or how we could solve the performance bottlenecks due to executing a new python process for each command being shelled out as root.

Finally, we'll discuss how far we are from making rootwrap a standalone library, and if that's a good idea to begin with.

(Session proposed by Thierry Carrez)


Wednesday November 6, 2013 2:50pm - 3:30pm
AWE Level 2, Room 201B

3:40pm

State of affairs in DB schema migrations
Topics to discuss:

1. sqlalchemy-migrate needs a new stable release

Distros use the patched versions of sqlalchemy-migrate to make it compatible with SQLAlchemy 0.8.x releases. The fix is really simple and is already merged to master branch of sqlalchemy-migrate repo on stackforge. We should make a new stable release of sqlalchemy-migrate as a first step to having SQLAlchemy>=0.8.1 in global requirements list.

2. sqlalchemy-migrate is rather old and we'd better switch to alembic as soon as possible (new features, bug fixes, compatibility with new SQLAlchemy versions/etc)

sqlalchemy-migrate had not been maintained for some time, so we start to catch more and more bugs in its compatibility with newer versions of SQLAlchemy (e. g. https://bugs.launchpad.net/nova/+bug/1241038). We could continue to fix it ourselves, but a simpler (and, I believe, the right one) approach would be to switch to Alembic.

3. Problems with switching to Alembic

1) our tests are run on SQLite in-memory DB and we use migrations to obtain the initial DB schema, but Alembic doesn't support ALTER in SQLite on purpose (sqlalchemy-migrate implements it by using a couple of hacks)

so we should use models definitions to generate the initial DB schema for running tests, but

2) we can't use models definitions to generate the initial DB schema right now, because models are out of sync with migrations (so the schema obtained by applying of migration scripts and the one generated from models definitions MAY be different, please see the blueprint below for more information)

and

3) switch to Alembic would mean dropping migrations support on SQLite (and Debian/Ubuntu OpenStack packages maintainers) would not be glad

Blueprints below provide more information on how sqlalchemy-migrate and alembic can live together in Ceilometer + explain out-of-sync problem in details.

(Session proposed by Roman Podolyaka)


Wednesday November 6, 2013 3:40pm - 4:20pm
AWE Level 2, Room 201B
 
Thursday, November 7
 

11:00am

Towards more structured & qualified notifications
Notifications API in Oslo is currently very generic and doesn't many structuring fields on the payload sent.
That doesn't help engine that would like to store, index and analyzes the event notifications.

Adding more documented fields that should/mut be present in notifiations could help a lot in this regard.

(Session proposed by Julien Danjou)


Thursday November 7, 2013 11:00am - 11:40am
AWE Level 2, Room 201B

11:50am

Merge logging and notifications
The current usage of notification and events logging are totally dissociated. It seems that it would be a good goal to slowly merge the two API to only keep one.

For example, the logging system would log to either a file (like currently) or to a RPC notification based event.
In the end, the notification system as it is today could be deprecated in favor of the generic logging mechanism.

(Session proposed by Julien Danjou)


Thursday November 7, 2013 11:50am - 12:30pm
AWE Level 2, Room 201B
 
Friday, November 8
 

9:50am

Writing a service synchronisation library
In Ceilometer, we have a few services that needs their daemons/agents to be synchronized and to have work split among them. That includes the alarm evaluator, or the evolution we'd like to have on the central agent.

Some services like Nova uses part of this mechanism in the "servicegroup" implementation.

We think that a lot of services in OpenStack could use such a functionality, so having a common solution into Oslo would be a nice solution.

(Session proposed by Julien Danjou)


Friday November 8, 2013 9:50am - 10:30am
AWE Level 2, Room 201B

11:00am

Oslo incubated libraries status
This session will include the following subject(s):

Oslo incubated libraries status:

What state are the various incubated libraries in, and which are close to being ready to move out of the incubator?

(Session proposed by Doug Hellmann)

Taskflow & oslo:

I would like to talk with the oslo focus to discuss the work done in taskflow, its goals, its current progress & integration and to see how we can align to fit into taskflow+oslo (if such a thing is possible) so that taskflow and oslo can be happily married and live happily ever after (it's a metaphor).

Taskflow wiki (with mission, examples)...

- https://wiki.openstack.org/wiki/TaskFlow

Code:

- https://github.com/stackforge/taskflow

(Session proposed by Joshua Harlow)


Friday November 8, 2013 11:00am - 11:40am
AWE Level 2, Room 201B

11:50am

Aggressively split oslo-incubator
We should think about splitting all of the modules in oslo-incubator into different repos from the start. This doesn't mean an end to incubation copying, but rather a different approach. The update.py tooling would have to change - but as a benefit, it would let us better model the oslo-core+%(module)s-core structure early on.

(Session proposed by Monty Taylor)


Friday November 8, 2013 11:50am - 12:30pm
AWE Level 2, Room 201B