OpenStack

With edge, we have closed vendor solutions and open reference architectures, but nothing for VNF and software vendors to build on top of. Changing that is the first step towards virtualized edge.

With just over two weeks to go before the OpenStack Summit EU, the Cisco team is starting to get very excited about being back at this awesome event. For...

Highlights you’ll want to add to your schedule about HPC, GPU and AI. The post Inside HPC, GPU, AI : Must-see sessions at the Berlin Summit appeared first on Superuser.

Join the people building and operating open infrastructure at the OpenStack Summit Berlin in November. The Summit schedule features over 200 sessions organized by use cases including: artificial intelligence and machine learning, high performance ... [More] computing, edge computing, network functions virtualization, container infrastructure and public, private and multi-cloud strategies. Here we’re highlighting some of the sessions […] The post Inside HPC, GPU, AI : Must-see sessions at the Berlin Summit appeared first on Superuser. [Less]

A placement update for you. Most Important Same as last week: The major factors that need attention are managing database migrations and associated tooling and getting the ball rolling on properly producing documentation. More on both of these things ... [More] in the extraction section below. Matt has sent out an email seeking volunteers from OpenStack Ansible or TripleO to get placement upgrade tooling in one of those projects. Bugs I guess it is because of various people doing upgrades, and some of the downstream projects starting to take more advantage of placement, but there's been a raft of interesting bugs recently. Many related to some of the more esoteric aspects of the ProviderTree handling in the resource tracker, the SQL in the placement service, or management of global state in WSGI servers. Initially this is a bit frustrating, but it's also a good thing: Finding and fixing bugs is the beating heart of an open source project. So thanks to everyone finding and fixing them. Placement related bugs not yet in progress: 15. -1. In progress placement bugs 11. Specs The spec review sprint happened and managed to get some specs merged, so this list should have shrunk some. https://review.openstack.org/#/c/544683/ Account for host agg allocation ratio in placement (Still in rocky/) https://review.openstack.org/#/c/595236/ Add subtree filter for GET /resource_providers https://review.openstack.org/#/c/597601/ Resource provider - request group mapping in allocation candidate https://review.openstack.org/#/c/549067/ VMware: place instances on resource pool (still in rocky/) https://review.openstack.org/#/c/555081/ Standardize CPU resource tracking https://review.openstack.org/#/c/599957/ Allow overcommit of dedicated CPU (Has an alternative which changes allocations to a float) https://review.openstack.org/#/c/591037/ Modelling passthrough devices for report to placement https://review.openstack.org/#/c/603585/ Spec: allocation candidates in tree https://review.openstack.org/#/c/603805/ [WIP] generic device discovery policy https://review.openstack.org/#/c/603955/ Nova Cyborg interaction specification. https://review.openstack.org/#/c/601596/ supporting virtual NVDIMM devices https://review.openstack.org/#/c/603352/ Spec: Support filtering by forbidden aggregate https://review.openstack.org/#/c/552924/ Proposes NUMA topology with RPs https://review.openstack.org/#/c/569011/ Count quota based on resource class https://review.openstack.org/#/c/607989/ WIP: High Precision Event Timer (HPET) on x86 guests https://review.openstack.org/#/c/571111/ Add support for emulated virtual TPM https://review.openstack.org/#/c/141219/ Adds spec for instance live resize https://review.openstack.org/#/c/612497/ Provider config YAML file Main Themes Making Nested Useful Work on getting nova's use of nested resource providers happy and fixing bugs discovered in placement in the process. This is creeping ahead. We recently confirmed that end-to-end success with nested providers is priority one for resource provider related work. https://review.openstack.org/#/q/topic:bp/use-nested-allocation-candidates There's a topic for reshaper that still has some open patches: https://review.openstack.org/#/q/topic:bp/reshape-provider-tree+status:open Extraction There continue to be three main tasks in regard to placement extraction: upgrade and integration testing database schema migration and management documentation publishing There's been some good progress here. The grenade job works and is ready to merge independent of other things. The related devstack change is still waiting on the database management that's part of (2). As mentioned above, volunteers from OSA or TripleO are being recruited. That db management is making some good headway with a working alembic setup but the tooling to use it needs to be formalized. The command line hack has been updated to use the alembic setup. We have work in progress to tune up the documentation but we are not yet publishing documentation (3). The plan here is to incrementally improve things as we have attention and discover things. One goal with this is to keep the process moving and use followups to avoid nitpicking each other too much. Other Various placement changes out in the world. https://review.openstack.org/#/c/601866/ Generate sample policy in placement directory (This is a bit stuck on not being sure what the right thing to do is.) https://review.openstack.org/#/q/topic:bp/initial-allocation-ratios Improve handling of default allocation ratios https://review.openstack.org/#/q/topic:minimum-bandwidth-allocation-placement-api Neutron minimum bandwidth implementation https://review.openstack.org/#/c/602160/ Add OWNERSHIP $SERVICE traits https://review.openstack.org/#/c/604182/ Puppet: Initial cookiecutter and import from nova::placement https://review.openstack.org/#/c/586960/ zun: Use placement for unified resource management https://review.openstack.org/#/q/topic:bug/1799727 Update allocation ratio when config changes https://review.openstack.org/#/q/topic:bug/1799892 Deal with root_id None in resource provider https://review.openstack.org/#/q/topic:bug/1795992 Use long rpc timeout in select_destinations https://review.openstack.org/#/c/529343/ Cleanups for scheduler code https://review.openstack.org/#/q/topic:bp/bandwidth-resource-provider Bandwith Resource Providers! https://review.openstack.org/#/q/topic:bug/1799246 Harden placement init under wsgi https://review.openstack.org/#/q/topic:cd/gabbi-tempest-job Using gabbi-tempest for integration tests. https://review.openstack.org/#/c/613118/ Make tox -ereleasenotes work https://review.openstack.org/#/c/613343/ placement: Add a doc describing a quick live environment End It's tired around here. [Less]

Answers to your most common questions about the upcoming Forum at the Summit Berlin. The post What to expect from the upcoming OpenStack Forum appeared first on Superuser.

One day a while back, I started blabbing out loud about some quick ways to experiment with a live placement service and was (very appropriately) reminded that I make a ton of incorrect assumptions about the familiarity people have with things I do ... [More] most days. Statements like "just spin up the wsgi script against uwsgi and a stubbed out placement.conf and see what happens" are a good example of me being bad. So, to help, here are some instructions on how to spin up the wsgi script against uwsgi and a stubbed out placement.conf, in case you want to see what happens. The idea here is that you want to experiment with the current placement code, using a live database, but you're not concerned with other services, don't want to deal with devstack, but need a level of interaction with the code and process that something like placedock can't provide. As ever, even all of the above has lots of assumptions about experience and context. This post assumes you are someone who either is an OpenStack (and probably placement) developer, or would like to be one. To make this go you need a unix-like OS, with a python3 dev environment, and git and mysql (or postgresql) installed. We'll be doing this work from within a virtualenv, built from the tox.ini in the placement code. At the time of writing, some required code is not yet merged into placement, so we'll be using a patch that is currently under review. I'll update this document when that code merges so we can skip a step. Get The Code and Deps The placement code lives at https://git.openstack.org/cgit/openstack/placement. We want to clone that: git clone git://git.openstack.org/openstack/placement cd placement Then we want to get the extra code mentioned above: git pull https://git.openstack.org/openstack/placement refs/changes/61/600161/13 Setup The Database That patch adds a commands to create tables in a database. We need to 1) create the database, 2) create a virtualenv to have the command, 3) use it to create the tables. The database can have whatever name you like. Whatever you choose, use it throughout this process. I choose placement. You may need a user and password to talk to your database, setting that up is out of scope for this document. I'm using a machine that has had devstack on it before so mysql is configured in what might be a familiar way: mysql -uroot -psecret -e "DROP DATABASE IF EXISTS placement;" mysql -uroot -psecret -e "CREATE DATABASE placement CHARACTER SET utf8;" You may also need to set permissions: mysql -uroot -psecret \ -e "GRANT ALL PRIVILEGES ON placement.* TO 'root'@'%' identified by 'secret';" Get the table create command by updating the virtualenv: tox -epy36 --notest Create a bare minimum placement.conf in the /etc/placement directory (which you may need to create): [placement_database] connection = mysql+pymysql://root:[email protected]/placement?charset=utf8 (Note that when this command matures you will be able to name the location of the configuration file on the command line.) Run the command to create the tables: .tox/py36/bin/placement-manage db table_create You can confirm the tables are there with mysqlshow placement Run The Service Now we want to run the service. We need to update placement.conf so it will produce debugging output and use the noauth strategy for authentication (so we don't also have to run Keystone). Make placement.conf look like this (adjusting for your database settings): [DEFAULT] debug = True [placement_database] connection = mysql+pymysql://root:[email protected]/placement?charset=utf8 [api] auth_strategy = noauth2 We need to install the uwsgi package into the virtualenv: .tox/py36/bin/pip install uwsgi And then use uwsgi to run the service. Start it with: .tox/py36/bin/uwsgi --http :8000 --wsgi-file .tox/py36/bin/placement-api If that worked you'll see lots of debug output and spawned uWSGI worker 1. Test that things are working from another terminal with curl: curl -v http://localhost:8000/ Get a list of resource providers with (the x-auth-token header is required, openstack-api-version is optional but makes sure we are getting the latest functionality): curl -H 'x-auth-token: admin' \ -H 'openstack-api-version: placement latest' \ http://localhost:8000/resource_providers The result ought to look something like this: {"resource_providers": []} If it doesn't then something went wrong with the above and there should be more information in the terminal where uwsgi is running. From here you can experiment with creating resource providers and related placement features. If you change the placement code, ctrl-c to kill the uwsgi process and start it up again. For testing, you might might enjoy placecat. Here's a script to do the install for you: [Less]

Insight from a recent market research study conducted by ClearPath Strategies and the OpenStack Foundation. The post Taking a closer look at open source infrastructure appeared first on Superuser.

OVH hits the right notes at their annual Summit in Paris. The post Rocking the innovation revolution with open source appeared first on Superuser.