OpenStack Developer Mailing List Digest December 17-23

SuccessBot Says

AJaeger: We&;ve now got the first Deployment guide published for Newton, see http://docs.openstack.org/project-deploy-guide/newton/ . Congrats to OpenStack Ansible team!
clarkb: OpenStack CI has moved off of Ubuntu Trusty and onto Ubuntu Xenial for testing Newton and master.
ihrachys: first oslo.privsep patch landed in Neutron.
dulek: Cinder now supports ZeroMQ messaging!
All

Release Countdown for Week R-8, 26-30 December

Feature work and major refactoring should be well under way as we pass the second milestone.
Focus:

Deadline for non-client library releases is R-5 (19 Jan).

Feature freeze exceptions are not granted for libraries.

General Notes:

Project teams should identify contributors that have a significant impact this cycle who not otherwise qualify for ATC status.
Those names should be added to the governance repository for consideration as ATC.
The list needs to be approved by the TC by 20 January to qualify for contributor discounts codes for the event.
Submit these by 5 January

Important Dates:

Extra ATCs deadline: 5 January
Final release of non-client libraries: 19 January
Ocata 3 Milestone, with Feature and Requirements freezes: 26 January

Ocata release schedule [1]
Full thread

Lives

There is movement to still move to Storyboard as our task tracker.
To spread awareness, some blog posts have been made about it, and it’s capabilities:

General over and decision to move from Launchpad [2].
Next post will focus on compare and contrast of Launchpad and Storyboard.

If you want to hear about something in particular in the blog posts, let the team know on storyboard IRC channel on Freenode.
Attend their weekly meeting [3].
Try out Storyboard in the sandbox [4].
Storyboard documentation [5]
Full thread

 
[1] &; http://releases.openstack.org/ocata/schedule.html
[2] &8211; https://storyboard-blog.sotk.co.uk/why-storyboard-for-openstack.html
[3] &8211; https://wiki.openstack.org/wiki/StoryBoard
[4] &8211; https://storyboard-dev.openstack.org/
[5] &8211; http://docs.openstack.org/infra/storyboard/
Quelle: openstack.org

OpenStack Developer Mailing List Digest December 31 – January 6

SuccessBot Says

Dims &; Keystone now has Devstack based functional test with everything running under python3.5.
Tell us yours via IRC channels with message &; <message>&;
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

Azure Media Services Live Monitoring Dashboard open-source release

We are excited to announce the open-source release of the Azure Media Services (AMS) Live Monitoring Dashboard on GitHub.

The Live Monitoring Dashboard is a .NET C# web app that enables Azure Media Services (AMS) customers to view the health of their channel and origin deployments. The dashboard captures the state of ingest, archive, encode, and origin telemetry entities, enabling customers to quantify the health of their services with low latency. The dashboard supplies data on the incoming data rate for video stream ingestion, dropped data in storage archive, encoding data rate, and origin HTTP error statuses and latencies.

Special thanks to Prakash Duggaraju for his help and contributions to this project.

Dashboard overview

The image below illustrates the account-level view of the Live Monitoring Dashboard. The upper left pane highlights each deployment’s health status with a different status code color. Ingest, archive, origin, and encode telemetry entities are denoted by i, a, o, and e abbreviations respectively. Each color of theindicator summarizes whether an entity is currently impacted. Green denotes healthy, orange indicates mildly impacted, red indicates unhealthy, and gray indicates inactive. You can modify the thresholds for which these flags are raised from the storage account JSON configuration file. From the right pane, you can drill down into the detailed views for each deployment by clicking on the active status squares.

This dashboard is backed by a SQL database that reads telemetry data from your Azure storage account. Our telemetry release announcement blog post details the types of telemetry data supported today. Every 30 seconds all views within the dashboard are automatically refreshed with the latest telemetric data.

Channel Detailed View

The channel detailed view provides incoming bitrate, discontinuity count, overlap count, and bitrate ratio data for a given channel. In this view, these fields represent the following:

Bitrate: the expected bitrate for a given track and incoming bitrate is the bitrate that the channel receives
Discontinuity count: the count of instances where a fragment was missing in the stream
Overlap count: the count of instances where the channel receives fragments with the same or overlapping stream timestamp
Bitrate ratio: the ratio of incoming bitrate to expected bitrate

Optimally, a channel should have no discontinuities, no overlaps, and a bitrate ratio of one. Flags are set to raise when these dimensions deviate from normal values.

Archive Detailed View

The archive detailed view provides bitrate, dropped fragment count, and dropped fragment rate for the archive entities backing each track. In this view, these fields represent the following:

Bitrate: the expected bitrate of the given track
Dropped fragment count: the number of fragments dropped in the program
Dropped fragment ratio: the number of fragments dropped per minute

Optimally, the dropped fragment count and dropped fragment ratio should be zero.

Origin Detailed View

The origin detailed view provides request count, bytes sent, server latency, end-to-end (E2E) latency, request ratio, bandwidth, and data output utilization ratio for a given origin. In this view, these fields represent the following:

Request count: the number of times a client requested data from the origin, categorized by the HTTP status code
Bytes sent: the number of bytes returned to the client
Server latency: the server latency component for responding to a request
End-to-end latency: the total latency for responding to a request
Request rate: the number of requests the origin receives per minute
Bandwidth: the origin response throughput
Request ratio: the percentage of requests for a given HTTP status code
Data output utilization ratio: the percentage of maximum throughput that the origin utilizes

Optimally, origin requests should return only HTTP 200 status codes and there should be no failed requests (HTTP 4XX + 5XX – 412). The data out utilization should preferably not exceed 90 – 95% of the maximum available throughput.

Encode Detailed View

The encode detailed view provides the health status for inputs, transcoders, output, and overall health.

Optimally, the encoder detailed view should reflect overall healthy status.

Providing feedback & feature requests

We love to hear from our customers and better understand your needs! To help serve you better, we are always open to feedback, new ideas, and appreciate any bug reports so that we can continue to provide an amazing service with the latest technologies. To request new features, provide ideas or feedback, please submit to User Voice for Azure Media Services. If you have any specific issues, questions, or find any bugs, please post your question or feedback to our forum.
Quelle: Azure