da Agency

OpenStack Developer Mailing List Digest March 18-24

SuccessBot Says

Yolanda [1]: Wiki problems have been fixed, it’s up and running
johnthetubaguy [2]: First few patches adding real docs for policy have now merged in Nova. A much improved sample file [3].
Tell us yours via OpenStack IRC channels with message “#success <message>”
All: [4]

Release Naming for R

It&8217;s time to pick a name for our “R” release.
The assoicated summit will be in Vancouver, so the geographic location has been chosen as “British Colombia”.
Rules:

Each release name must start with the letter of the ISO basic Latin alphabet following the initial letter of the previous release, starting with the initial release of &#8220;Austin&#8221;. After &8220;Z&8221;, the next name should start with &8220;A&8221; again.
The name must be composed only of the 26 characters of the ISO basic Latin alphabet. Names which can be transliterated into this character set are also acceptable.
The name must refer to the physical or human geography of the region encompassing the location of the OpenStack design summit for the corresponding release. The exact boundaries of the geographic region under consideration must be declared before the opening of nominations, as part of the initiation of the selection process.
The name must be a single word with a maximum of 10 characters. Words that describe the feature should not be included, so &8220;Foo City&8221; or &8220;Foo Peak&8221; would both be eligible as &8220;Foo&8221;.

Full thread [5]

Moving Gnocchi out

The project Gnocchi which has been tagged independent since it&8217;s inception has potential outside of OpenStack.
Being part of the big tent helped the project be built, but there is a belief that it restrains its adoption outside of OpenStack.
The team has decided to move it out of OpenStack [6].

In addition out of the OpenStack infrastructure.

Gnocchi will continue thrive and be used by OpenStack such as Ceilometer.
Full thread [7]

POST /api-wg/news

Guides under review:

Define pagination guidelines (recently rebooted) [8]
Create a new set of api stability guidelines [9]
Microversions: add next_min_version field in version body [10]
Mention max length limit information for tags [11]
Add API capabilities discovery guideline [12]
WIP: microversion architecture archival doc (very early; not yet ready for review) [13]

Full thread [14]

 
Quelle: openstack.org

da Agency

OpenStack Developer Mailing List Digest March 11-17

SuccessBot Says

Dims [1]: Nova now has a python35 based CI job in check queue running Tempest tests (everything running on py35)
jaypipes [2]: Finally got a good functional test created that stresses the Ironic and Nova integration and migration from Newton to Ocata.
Lbragstad [3]: the #OpenStack-Ansible project has a test environment that automates rolling upgrade performance testing
annegentle [4]: Craig Sterrett and the App Dev Enablement WG: New links to more content for the appdev docs [5]
jlvillal [6]: Ironic team completed the multi-node grenade CI job
Tell us yours via OpenStack IRC channels with message “#success <message>”

All: [7]

Pike Release Management Communication

The release liaison is responsible for:

Coordinating with the release management team.
Validating your team release team requests.
Ensure release cycle deadlines are met.
It&#8217;s encouraged to nominate a release liaison. Otherwise this tasks falls back to the PTL.

Ensure the releaase liaison has time and ability to handle the communication necessary.

Failing to follow through on a needed process step may block you from meeting deadlines or releasing as our milestones are date-based, not feature-based.

Three primary communication tools:

Email for announcements and asynchronous communication

“[release]” topic tag on the openstack-dev mailing list.
This includes the weekly release countdown emails with details on focus, tasks, and upcoming dates.

IRC for time sensitive interactions

With more than 50 teams, the release team relies on your presence in the freenode openstack-release channel.

Written documentation for relatively stable information

The release team has published the schedule for the Pike cycle [8]
You can add the schedule to your own calendar [9]

Things to do right now:

Update your release liaisons [10].
Make sure your IRC and email address listed in projects.yaml [11].

Update your mail filters to look for “[release]” in the subject line.
Full thread [12]

OpenStack Summit Boston Schedule Now Live!

Main conference schedule [13]
Register now [14]
Hotel discount rates for attendees [15]
Stackcity party [16]
Take the certified OpenStack Administrator exam [17]
City guide of restaurants and must see sites [18]
Full thread [19]

Some Information About the Forum at the Summit in Boston

“Forum” proper

3 medium sized fishbowl rooms for cross-community discussions.
Selected and scheduled by a committee formed of TC and UC members, facilitated by the Foundation staff members.
Brainstorming for topics [20]

“On-boarding” rooms

Two rooms setup classroom style for projects teams and workgroups who want to on-board new team members.
Examples include providing introduction to your codebase for prospective new contributors.
These should not be tradiitonal “project intro” talks.

Free hacking/meetup spaces

Four to five rooms populated with roundtables for ad-hoc discussions and hacking.

Full thread [21]

 
The Future of the App Catalog

Created early 2015 as a market place of pre-packaged applications [22] that you can deploy using Murano.
This has grown to 45 Glance images, 13 Heat templates and 6 Tosca templates. Otherwise did not pick up a lot of steam.
~30% are just thin wrappers around Docker containers.
Traffic stats show 100 visits per week, 75% of which only read the index page.
In parallel, Docker developed a pretty successful containerized application marketplace (Docker Hub) with hundreds or thousands regularly updated apps.

Keeping the catalog around makes us look like we are unsuccessfully trying to compete with that ecosystem, while OpenStack is in fact complimentary.

In the past, we have retired projects that were dead upstream.

The app catalog is however has an active maintenance team.
If we retire the app catalog, it would not be a reflection on that team performance, but that the beta was arguably not successful in build an active market place and a great fit from a strategy perspective.

Two approaches for users today to deploy docker apps in OpenStack:

Container-native approach using “docker run” after using Nova or K8s cluster using Magnum.
OpenStack Native approach “zun create nginx”.

Full thread [23][24]

ZooKeeper vs etcd for Tooz/DLM

Devstack defaults to ZooKeeper and is opinionated about it.
Lots of container related projects are using etcd [25], so do we need to avoid both ZooKeeper and etcd?
For things like databases and message queues, it&8217;s more than time for us to contract on one solution.

For DLMs ZooKeepers gives us mature/ featureful angle. Etcd covers the Kubernetes cooperation / non-java angle.

OpenStack interacts with DLM&8217;s via the library Tooz. Tooz today only supports etcd v2, but v3 is planned which would support GRPC.
The OpenStack gate will begin to default to etcd with Tooz.
Full thread [26]

Small Steps for Go

An etherpad [27] has been started to begin tackling the new language requirements [28] for Go.
An golang-commons repository exists [29]
Gopher cloud versus having a golang-client project is being discussed in the etherpad. Regardless we need support for os-client-config.
Full thread [30]

POST /api-wg/news

Guidelines under review:

Add API capabilities discovery guideline [31]
Refactor and re-validate API change guidelines [32]
Microversions: add next_min_version field in version body [33]
WIP: microversion architecture archival doc [34]

Full thread [35]

Proposal to Rename Castellan to oslo.keymanager

Castellan is a python abstraction to different keymanager solutions such as Barbican. Implementations like Vault could be supported, but currently is not.
The rename would emphasize the Castellan is an abstraction layer.

Similar to oslo.db supporting MySQL and PostgreSQL.

Instead of oslo.keymanager, it can be rolled into the oslo umbrella without a rename. Tooz sets the precedent of this.
Full thread [36]

Release Countdown for week R-23 and R-22

Focus:

Specification approval and implementation for priority features for this cycle.

Actions:

Teams should research how they can meet the Pike release goals [37][38].
Teams that want to change their release model should do so before end of Pike-1 [39].

Upcoming Deadlines and Dates

Boston Forum topic formal submission period: March 20 &#8211; April 2
Pike-1 milestone: April 13 (R-20 week)
Forum at OpenStack Summit in Boston: May 8-11

Full thread [40]

Deployment Working Group

Mission: To collaborate on best practices for deploying and configuring OpenStack in production environments.
Examples:

OpenStack Ansible and Puppet OpenStack have been collaborating on Continuous Integration scenarios but also on Nova upgrades orchestration
TripleO and Kolla share the same tool for container builds.
TripleO and Fuel share the same Puppet OpenStack modules.
OpenStack and Kubernetes are interested in collaborating on configuration management.
Most of tools want to collect OpenStack parameters for configuration management in a common fashion.

Wiki [41] has been started to document how the group will work together. Also an etherpad [42] for brainstorming.

 
Quelle: openstack.org

da Agency

OpenStack Developer Mailing List Digest January 21-27

SuccessBot Says

dims [1] : Nova now has a python35 based CI job in check queue running Tempest tests (everything running on py35)
markvoelker [2]: Newly published Foundation annual report starts off with interoperability right in the chairman&#8217;s note [3]
Tell us yours via #OpenStack IRC channels with message “#success <message>”
All: [4]

Get Active in Upstream Training

There is a continuous effort in helping newcomers join our community by organizing upstream contribution trainings [5][6] before every summit.

1.5 &#8211; 2 days of hands-on steps of becoming an active OpenStack contributor.

Like everything else, this is a community effort.

In preparation for the Boston summit and the upcoming PTG in Atlanta, we are looking for coaches and mentors to help us make the training better.
If you’re interested in helping contact:

Ildiko Vancsa IRC freenode at ildikov or email [7]
Kendall Nelson IRC freenode at diablo_rojo or email [8]

Full thread: [9]

Project Team Gathering Coordination Tool

No central scheduling, beyond assigned rooms to teams and days.

Each team arranges their time in their room.
List of etherpads [10]

We still need centralized communication beyond each room:

An event IRC channel: openstack-ptg on free node IRC

Do public service announcements
Pings from room to room.

An EtherCalc spreadsheet powered dynamic schedule with extra rooms available:

One fishbowl
A few dark rooms with projectors and screens (not all will have a/v equipment due to budget).
Infra is working on setting up EtherCalc

Full thread: [11]

POST /api-wg/news

API Guidelines proposed for freeze:

Add guidelines on usage of state vs. status [12]
Clarify the status values in versions [13]
Add guideline for invalid query parameters [14]

Guidelines currently under review:

Add guidelines for boolean names [15]
Define pagination guidelines [16]
Add API capabilities discovery guideline [17 ]

Full thread: [18]

Lots of Teams Without PTL Candidates

We are reaching close to the end of the PTL nominations (Jan 29, 2017 23:45 UTC), but have projects that are leaderless:
Community App Catalog
Ec2 API
Fuel
Karbor
Magnum
Monasca
OpenStackClient
OpenStackUX
Packaging Prm
Rally
RefStack
Requirements
Senlin
Stable Branch Maintenance
Vitrage
Zun
Full thread [19]

 
Quelle: openstack.org

da Agency

OpenStack Developer Mailing List Digest January 14-20

SuccessBot Says

stevemar 1 : number of open keystone bugs < 100!
morgan 2 : Good policy meeting, provided history and background that cleared up a lot of confusion
Tell us yours via OpenStack IRC channels with message “#success <message>”
All

FIPS Compliance

Previous threads 3 have been discussing enabling Federal Information Processing Standards (FIPS).
Various OpenStack projects make md5 calls. Not for security purposes, just hash generation, but even that blocks enabling FIPS.
A patch has been proposed for newest versions of Python for users to set if these are used for security or not 4 .

Won’t land until next versions of Python, but in place for current RHEL and CentOS versions.
We will create a wrapper around md5 with a useforsecurity=False parameter to check the signature of hashlib.md5.

Steps forward:

Create the wrapper
Replace all md5 calls in OpenStack projects with the wrapper.

Unfortunately the patch 4 has stopped having progress since 2013. We should get that merged first.

Even if this did land, it would be a while before it was adopted, since it would land in Python 3.7.

Full thread

Refreshing and Revalidating API Compatibility Guidelines

In the last TC meeting 5 , a tag was in review for supporting API compatibility 6 .
The tag evaluates projects by using the API guideline which is out of date 7.

A review has been posted to refresh these guidelines 8 .
API compatibility of overtime is a fundamental aspect of OpenStack interoperability. Not only do we need to get it it right, we need to make sure we understand it.

Full thread

Base Services

in open stack all components can assume that a number of external services won&#8217;t be present and available (e.g. A message queue, database).
The Architecture working group has started this effort 9 .
This proposal 10 is a prerequisite in order for us to have more strategic discussions with adding base services.
Review the proposal and/or join the Architecture working group meeting 11
Once solidified the technical committee will have a final discussion and approval.
Full thread

Improving Vendor Discoverability

In previous Technical Committee meetings, it was agreed that vendor discoverability needs to be improved.
This is done today with the OpenStack Foundation marketplace 12 .

This is powered by the community driven project call driver log which is a big JSON file 13.

Various people in the community did not know #how the marketplace worked and we&8217;re unhappy that the projects themselves weren&8217;t owning it.
The goal of this discussion is to have this process be more community driven than it is today.
Suggestion: Split driver log into smaller JSON files that are inside each project to maintain.

Projects will set how they validate vendors into this list.
There’s a trend today for third party CI’s being a choice of validation 14.

Full thread

Nominations for OpenStack PTLs Are Now Open!

Will remain open until January 29, 2017 23:45 UTC.
Candidates must submit a text file openstack/election repository 15

Filename convention is $cyclename/$projectname/$ircname.txt.
To be eligible, you need to have contributed an accepted patch to one of the corresponding program’s projects 16 during the Neutron-Ocata timeframe (April 11, 2016 00:00 UTC to January 23, 2017 23:59 UTC).

Additional information about the nomination process 17
Approved candidates will be listed 18.
Electorate should confirm their email address in Gerrit 19 in Settings ←Contact Information ←Preferred Email prior to Jan 25, 2017 23:59 UTC.
Full thread

The Process of Creating stable/ocata branches

As previously mentioned 20, it’s possible for teams to setup stable branches when ready.
The release team will not be automatically setting up branches this cycle.

The release liaison within teams will need to inform when ready.
The PTL or release liaison may request a new branch by submitting a patch to the openstack/releases repository specifying the tagged version to be used as the base of the branch.

Guidelines for when projects should branch:

Projects using the cycle-with-milestone release model should include the request for their stable branch along with the RC1 tag request (target week is R-3 week, so use Feb 2 as the deadline)
Library projects should be branched with, or shortly after, their final release this week (use Jan 19 as the deadline)
I will branch the requirements repository shortly after all of the cycle-with-milestone projects have branched. After the   requirements repository is branched and the master requirements list is opened, projects that have not branched will be tested with #Pike requirements as the requirements master branch advances and stable/ocata stays stable. Waiting too long to create the stable/ocata branch may result in broken CI jobs in either stable/ocata or master. Don&8217;t delay any further than necessary.
Projects using the cycle-trailing release model should branch by R-0 (23 Feb). The remaining two weeks before the trailing deadline should be used for last-minute fixes, which will need to be backported into the branch to create the final release.
Other projects, including cycle-with-intermediary and independent  projects that create branches, should request their stable branch when they are ready to declare a final version and start working on Pike-related changes. This must be completed before the final release week, use 16 Feb as the deadline.

See the README.rst file in openstack/releases for more details about how to format branch specifications.
Full thread

Why Are Projects Trying To Avoid Barbican, Still?

Some projects are wanting to implement their own secret storage to avoid Barbican or avoid adding a dependency on it.

Some developers are doing this to make the operator’s lives simpler.

Barbican Positives:

Barbican has been around for a few years and deployed by several companies that have probably been audited for security purposes.
Most of the technology involved in Barbican is proven to be secure. This has been analyzed by the OpenStack’s own security group.
Doesn’t have a requirement on hardware TPM, so no hardware cost.
Several services provide the option of using Barbican, but not a hard requirement.

Feedback of problems with Barbican:

Relying on something that cannot be guaranteed will be present in a deployment.

The base service 9 proposal could help with this.

OpenStack specific solution. Some companies are using solutions that integrate with other things:

Keywhiz 21 to work with Kubernetes and their existing systems.

Devstack plugin just sets up Barbican. It’s not actually configuring any existing services to use it.
No fixed key manager for testing. The Barbican team pushed back on maintaining this because it’s not secure.
API stability with version 2 ←3 changes were made without a deprecation path or guarantees.
Tokens are open ended for users. Keystone and Barbican need to be much closer.

Castellan provides an abstraction for key management, but today only Barbican.
Rackspace recently made Barbican available. Maybe it’s easier now to perform an HA deployment.
Full thread

POST /api-wg/news

New guidelines:

Accurate status code vs backwards compatibility 22
Fix no sample file in browser 23

Guidelines proposed for freeze:

Add guidelines on usage of state vs. status 24
Clarify the status values in versions 25
Add guideline for invalid query parameters 26

Under review:

Add guidelines for boolean names 27
Define pagination guidelines 28
Add API capabilities discovery guideline 29

Full thread

Release Countdown for Week R-4 Jan 23-27

Focus:

This week begins feature freeze for all milestone-based projects.
No feature patches should be landed after this point.
PTLs may grant exceptions
Soft string freeze begins.

Review teams should reject any modifications to user-facing strings.

Requirement freeze begins.

Only critical requirements and constraints changes will be allowed.

Release Tasks:

Prepare final release and branch requests for all client libraries.
Review stable branches for unreleased changes and prepare those releases.
Milestone based projects should ensure that membership of $project-release gerri groups is up to date with the team who will finalize the project release.

General Notes:

RC1 target week in R-3 is only one week after freeze.

Important Dates:

Ocata 3 Milestone, with Feature and Requirements Freezes: 26 Jan
Ocata RC1 target: 2 Feb
Ocata Final Release candidate deadline: 16 Feb
Ocata release schedule 30

Full thread

 
[1] &#8211; http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2017-01-18.log.html
[2] &8211; http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2017-01-18.log.html
[3] &8211; http://lists.openstack.org/pipermail/openstack-dev/2016-November/107035.html
[4] &8211; http://bugs.python.org/issue9216
[5] &8211; http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-01-17-20.00.log.html
[6] &8211; https://review.openstack.org/#/c/418010/
[7] &8211; http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html
[8] &8211; https://review.openstack.org/#/c/421846/
[9] &8211; https://review.openstack.org/421956
[10] &8211; https://review.openstack.org/421957
[11] &8211; http://eavesdrop.openstack.org/#Architecture_Working_Group
[12] &8211; https://www.openstack.org/marketplace/drivers/
[13] &8211; http://git.openstack.org/cgit/openstack/driverlog/tree/etc/default_data.json
[14] &8211; https://etherpad.openstack.org/p/driverlog-validation
[15] &8211; http://governance.openstack.org/election/how-to-submit-your-candidacy
[16] &8211; http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
[17] &8211; https://governance.openstack.org/election/
[18] &8211; https://governance.openstack.org/election/pike-ptl-candidates
[19] &8211; https://review.openstack.org
[20] &8211; http://lists.openstack.org/pipermail/openstack-dev/2016-December/108923.html
[21] &8211; https://github.com/square/keywhiz
[22] &8211; https://review.openstack.org/#/c/422264/
[23] &8211; https://review.openstack.org/#/c/421084/
[24] &8211; https://review.openstack.org/#/c/411528/
[25] &8211; https://review.openstack.org/#/c/411849/
[26] &8211; https://review.openstack.org/417441
[27] &8211; https://review.openstack.org/#/c/411529/
[28] &8211; https://review.openstack.org/#/c/390973/
[29] &8211; https://review.openstack.org/#/c/386555/
[30] &8211; http://releases.openstack.org/ocata/schedule.html
Quelle: openstack.org

da Agency

OpenStack Developer Mailing List Digest January 7-13

SuccessBot Says

dims 1: Rally running against Glance (Both Rally and Glance using py3.5).
AJaegar 2: docs.openstack.org is served from the new Infra file server that is AFS based.
jd 3: Gnocchi 3.1 will be shipped with an empty /etc and will work without any config file by default.
cdent 4 : edleafe found narrowed down an important bug in gabbi.
Tell us yours via OpenStack IRC channels with message “#success <message>”
All

Return of the Architecture Working Group

Meeting times Alternate, even weeks Thursday at 20:00UTC, odd weeks Thursday at 01:00UTC
Currently two proposes:

“Base Services” proposal 5 recognizes components leveraging features from external services that OpenStack components can assume will be present. Two kinds:

Local (like a hypervisor on a compute node)
Global (like a database)

“Nova Compute API” proposal 6 breaking nova-compute out of Nova itself.

Full thread

Restarting Service-types-authority / service catalog work

In anticipation of having a productive time in Atlanta for the PTG, various patches have been refreshed 7.
Two base IASS services aren’t in the list yet because of issues:

Neutron / network &#8211; discrepancy between common use of “network” and “networking” in the API reference URL. Other services in the list have the service-type and the URL name for the API reference are the same.
Cinder / volume &8211; Moving forward from using volumev2 and volumev3 in devstack.

Full thread

Feedback From Driver Maintainers About Future of Driver Projects

Major observations

Yes drivers are an important part of OpenStack.
Discoverability of drivers needs to be fixed immediately.
It’s important to have visibility in a central place of the status of each driver.
Both driver developer and a high level person at a company should feel they’re part of something.
Give drivers access to publish to docs.openstack.org.
What constitutes a project was never for drivers. Drivers are part part of the project. Driver developers contribute to OpenStack by creating drivers.

Discoverability:

Consensus: it is currently all over the place 8 9 10.
There should be CI results available.
Discoverability can be fixed independently of governance changes.

Driver projects official or not?

Out-of-tree vendors have a desire to become “official” OpenStack projects.
Opinion: let driver projects become official without CI requirements.
Opinion: Do not allow drivers projects to become official, that doesn’t mean they shouldn’t easily be discoverable.
Opinion: We don&#8217;t need to open the flood gates of allowing vendors to be teams in the OpenStack governance to make the vendors developers happy.
Fact: This implies being placed under the TC oversight. It is a significant move that could have unintended side-effects, it is hard to reverse (kicking out teams we accepted is worse than not including them in the first place), and our community is divided on the way forward. So we need to give that question our full attention and not rush the answer.
Opinion: Consider driver log 11 an official OpenStack project to be listed under governance with a PTL, weekly meetings, and all that it required to allow the team to be effective in their mission of keeping the marketplace a trustworthy resource for learning about OpenStack driver ecosystem.

Driver Developers:

Opinion: A driver developer that ONLY contributes to vendor specific driver code should not have the same influence as other OpenStack developers, voting for PTL, TC, and ATC status.
Opinion: PTLs should leverage the extra-atcs option in the governance repo.

In-tree VS out-of-tree

Cinder has in-tree drivers, but also has out-of-tree drivers when their CI is not maintained or when minimum feature requirements are not met. They are marked as ‘not supported’ and have a single release to get things working before being moved out-of-tree.
Ironic has a single out-of-tree repo 12 &#8212; But also in-tree 13
Neutron has all drivers out-of-tree, with project names like: ‘networking-cisco’.
Many opinions on the “stick-based” approach the cinder team took.
Opinion: The in-tree vs out-of-tree argument is developer focused. Out-of-tree drivers have obvious benefits (develop quickly, maintain their own team, no need for a core to review the patch). But a vendor that is looking to make sure a driver is supported will not be searching git repos (goes back to discoverability).
Opinion: May be worth handling the projects that keep supported drivers in-tree differently that we handle projects that have everything out-of-tree.

Full thread

POST /api-wg/news

Guidelines currently under review:

Add guidelines on usage of state vs. status 14
Add guidelines for boolean names 15
Clarify the status values in versions 16
Define pagination guidelines 17
Add API capabilities discovery guideline 18
Add guideline for invalid query parameters 19

Full thread

New Deadline for PTG Travel Support Program

Help contributors that are not otherwise funded to join their project team gathering 20
Originally the application acceptance was set to close January 15, but it’s now extended to the end-of-day Tuesday January 17th.
Apply now if you need it! 21
Submissions will be evaluated next week and grantees will be notified by Friday, January 20th.
Register for the event 22 if you haven’t yet. Prices will increase on January 24 and February 14.
If you haven’t already booked your hotel yet, do ASAP in the event hotel itself using the PTG room block. This helps us keep costs under control and helps share the most time with the event participants.

Closes January 27
Book now 23

Full thread

Release Countdown For Week R-5

Focus:

Feature work and major refactoring be starting to wrap up as we approach the the third milestone.

Release Tasks:

stable/ocata branches will be created and configured with a small subset of the core review team. Release liaisons should ensure that these groups exist and the membership is correct.

General Notes:

We will start the soft string freeze during R-4 (Jan 23-27) 24
Subscribe to the release calendar with your favorite calendaring software 25

Important Dates:

Final release for non-client libraries: January 19
Ocata 3 milestone with feature and requirements freeze: January 26
Ocata release schedule 26

Full thread

 
[1] &8211; http://eavesdrop.openstack.org/irclogs/%23openstack-glance/%23openstack-glance.2017-01-09.log.html
[2] &8211; http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2017-01-10.log.html
[3] &8211; http://eavesdrop.openstack.org/irclogs/%23openstack-telemetry/%23openstack-telemetry.2017-01-11.log.html
[4] &8211; http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-01-12.log.html
[5] &8211; http://git.openstack.org/cgit/openstack/arch-wg/tree/proposals/base-services.rst
[6] &8211; https://review.openstack.org/#/c/411527/1
[7] &8211; https://review.openstack.org/#/c/286089/
[8] &8211; http://docs.openstack.org/developer/cinder/drivers.html
[9] &8211; http://docs.openstack.org/developer/nova/support-matrix.html
[10] &8211; http://stackalytics.openstack.org/report/driverlog
[11] &8211; http://git.openstack.org/cgit/openstack/driverlog
[12] &8211; https://git.openstack.org/cgit/openstack/ironic-staging-drivers
[13] &8211; http://git.openstack.org/cgit/openstack/ironic/tree/ironic/drivers
[14] &8211; https://review.openstack.org/#/c/411528/
[15] &8211; https://review.openstack.org/#/c/411529/
[16] &8211; https://review.openstack.org/#/c/411849/
[17] &8211; https://review.openstack.org/#/c/390973/
[18] &8211; https://review.openstack.org/#/c/386555/
[19] &8211; https://review.openstack.org/417441
[20] &8211; http://www.openstack.org/ptg##tab_travel
[21] &8211; https://openstackfoundation.formstack.com/forms/travelsupportptg_atlanta
[22] &8211; https://pikeptg.eventbrite.com/
[23] &8211; https://www.starwoodmeeting.com/events/start.action?id=1609140999&key=381BF4AA
[24] &8211; https://releases.openstack.org/ocata/schedule.html##o-soft-sf
[25] &8211; https://releases.openstack.org/schedule.ics
[26] &8211; http://releases.openstack.org/ocata/schedule.html
Quelle: openstack.org

da Agency

OpenStack Developer Mailing List Digest December 31 – January 6

SuccessBot Says

Dims &#8211; Keystone now has Devstack based functional test with everything running under python3.5.
Tell us yours via #OpenStack IRC channels with message &#8220;#success <message>&#8221;
All

Time To Retire Nova-docker

nova-docker has lagged behind the last 6 months of nova development.
No longer passes simple CI unit tests.

There are patches to at least get the unit tests work 1 .

If the core team no longer has time for it, perhaps we should just archive it.
People ask about it on openstack-nova about once or twice a year, but it’s not recommended as it’s not maintained.
It’s believed some people are running and hacking on it outside of the community.
The Sun project provides lifecycle management interface for containers that are started in container orchestration engines provided with Magnum.
Nova-lxc driver provides an ability of treating containers like your virtual machines. 2

Not recommended for production use though, but still better maintained than nova-docker 3.

Nova-lxd also provides the ability of treating containers like virtual machines.
Virtuozzo which is supported in Nova via libvirt provides both a virtual machine and OS containers similar to LXC.

These containers have been in production for more than 10 years already.
Well maintained and actually has CI testing.

A proposal to remove it 4 .
Full thread

Community Goals For Pike

A few months ago the community started identifying work for OpenStack-wide goals to “achieve visible common changes, push for basic levels of consistency and user experience, and efficiently improve certain areas where technical debt payments have become to high &8211; across all OpenStack projects.”
First goal defined 5 to remove copies of incubated Oslo code.
Moving forward in Pike:

Collect feedback of our first iteration. What went well and what was challenging?
Etherpad for feedback 6

Goals backlog 7

New goals welcome
Each goal should be achievable in one cycle. If not, it should be broken up.
Some goals might require documentation for how it could be achieved.

Choose goals for Pike

What is really urgent? What can wait for six months?
Who is available and interested in contributing to the goal?

Feedback was also collected at the Barcelona summit 8
Digest of feedback:

Most projects achieved the goal for Ocata, and there was interest in doing it on time.
Some confusion on acknowledging a goal and doing the work.
Some projects slow on the uptake and reviewing the patches.
Each goal should document where the “guides” are, and how to find them for help.
Achieving multiple goals in a single cycle wouldn’t be possible for all team.

The OpenStack Product Working group is also collecting feedback for goals 9
Goals set for Pike:

Split out Tempest plugins 10
Python 3 11

TC agreeements from last meeting:

2 goals might be enough for the Pike cycle.
The deadline to define Pike goals would be Ocata-3 (Jan 23-27 week).

Full thread

POST /api-wg/news

Guidelines current review:

Add guidelines on usage of state vs. status 12
Add guidelines for boolean names 13
Clarify the status values in versions 14
Define pagination guidelines 15
Add API capabilities discovery guideline 16

Full thread

 
Quelle: openstack.org

da Agency

OpenStack Developer Mailing List Digest December 31 – January 6

SuccessBot Says

Dims &#8211; Keystone now has Devstack based functional test with everything running under python3.5.
Tell us yours via #OpenStack IRC channels with message &#8220;#success <message>&#8221;
All

Time To Retire Nova-docker

nova-docker has lagged behind the last 6 months of nova development.
No longer passes simple CI unit tests.

There are patches to at least get the unit tests work 1 .

If the core team no longer has time for it, perhaps we should just archive it.
People ask about it on openstack-nova about once or twice a year, but it’s not recommended as it’s not maintained.
It’s believed some people are running and hacking on it outside of the community.
The Sun project provides lifecycle management interface for containers that are started in container orchestration engines provided with Magnum.
Nova-lxc driver provides an ability of treating containers like your virtual machines. 2

Not recommended for production use though, but still better maintained than nova-docker 3.

Nova-lxd also provides the ability of treating containers like virtual machines.
Virtuozzo which is supported in Nova via libvirt provides both a virtual machine and OS containers similar to LXC.

These containers have been in production for more than 10 years already.
Well maintained and actually has CI testing.

A proposal to remove it 4 .
Full thread

Community Goals For Pike

A few months ago the community started identifying work for OpenStack-wide goals to “achieve visible common changes, push for basic levels of consistency and user experience, and efficiently improve certain areas where technical debt payments have become to high &8211; across all OpenStack projects.”
First goal defined 5 to remove copies of incubated Oslo code.
Moving forward in Pike:

Collect feedback of our first iteration. What went well and what was challenging?
Etherpad for feedback 6

Goals backlog 7

New goals welcome
Each goal should be achievable in one cycle. If not, it should be broken up.
Some goals might require documentation for how it could be achieved.

Choose goals for Pike

What is really urgent? What can wait for six months?
Who is available and interested in contributing to the goal?

Feedback was also collected at the Barcelona summit 8
Digest of feedback:

Most projects achieved the goal for Ocata, and there was interest in doing it on time.
Some confusion on acknowledging a goal and doing the work.
Some projects slow on the uptake and reviewing the patches.
Each goal should document where the “guides” are, and how to find them for help.
Achieving multiple goals in a single cycle wouldn’t be possible for all team.

The OpenStack Product Working group is also collecting feedback for goals 9
Goals set for Pike:

Split out Tempest plugins 10
Python 3 11

TC agreeements from last meeting:

2 goals might be enough for the Pike cycle.
The deadline to define Pike goals would be Ocata-3 (Jan 23-27 week).

Full thread

POST /api-wg/news

Guidelines current review:

Add guidelines on usage of state vs. status 12
Add guidelines for boolean names 13
Clarify the status values in versions 14
Define pagination guidelines 15
Add API capabilities discovery guideline 16

Full thread

 
Quelle: openstack.org