The post Exciting Features of OpenStack’s 21st Release: Ussuri appeared first on VEXXHOST.

So, Megacli is to be replaced by Storcli, both being proprietary tools for configuring RAID cards from LSI.

So I went to download what’s provided by Lenovo, available here:
https://support.lenovo.com/fr/en/downloads/ds041827

It’s very annoying, because they force users to download a .zip file containing a deb file, instead of providing a Debian repository. Well, ok, though at least there’s a deb file there. Let’s have a look what’s using my favorite tool before installing (ie: let’s run Lintian).
Then it’s a horror story. Not only there’s obvious packaging wrong, like the package provide stuff in /opt, and all is statically linked and provide embedded copies of libm and ncurses, or even the package is marked arch: all instead of arch: amd64 (in fact, the package contains both i386 and amd64 arch files…), but there’s also some really wrong things going on:

E: storcli: arch-independent-package-contains-binary-or-object opt/MegaRAID/storcli/storcli
E: storcli: embedded-library opt/MegaRAID/storcli/storcli: libm
E: storcli: embedded-library opt/MegaRAID/storcli/storcli: ncurses
E: storcli: statically-linked-binary opt/MegaRAID/storcli/storcli
E: storcli: arch-independent-package-contains-binary-or-object opt/MegaRAID/storcli/storcli64
E: storcli: embedded-library opt/MegaRAID/storcli/storcli64: libm
E: storcli: embedded-library … use –no-tag-display-limit to see all (or pipe to a file/program)
E: storcli: statically-linked-binary opt/MegaRAID/storcli/storcli64
E: storcli: changelog-file-missing-in-native-package
E: storcli: control-file-has-bad-permissions postinst 0775 != 0755
E: storcli: control-file-has-bad-owner postinst asif/asif != root/root
E: storcli: control-file-has-bad-permissions preinst 0775 != 0755
E: storcli: control-file-has-bad-owner preinst asif/asif != root/root
E: storcli: no-copyright-file
E: storcli: extended-description-is-empty
W: storcli: essential-no-not-needed
W: storcli: unknown-section storcli
E: storcli: depends-on-essential-package-without-using-version depends: bash
E: storcli: wrong-file-owner-uid-or-gid opt/ 1000/1000
W: storcli: non-standard-dir-perm opt/ 0775 != 0755
E: storcli: wrong-file-owner-uid-or-gid opt/MegaRAID/ 1000/1000
E: storcli: dir-or-file-in-opt opt/MegaRAID/
W: storcli: non-standard-dir-perm opt/MegaRAID/ 0775 != 0755
E: storcli: wrong-file-owner-uid-or-gid opt/MegaRAID/storcli/ 1000/1000
E: storcli: dir-or-file-in-opt opt/MegaRAID/storcli/
W: storcli: non-standard-dir-perm opt/MegaRAID/storcli/ 0775 != 0755
E: storcli: wrong-file-owner-uid-or-gid … use –no-tag-display-limit to see all (or pipe to a file/program)
E: storcli: dir-or-file-in-opt opt/MegaRAID/storcli/storcli
E: storcli: dir-or-file-in-opt … use –no-tag-display-limit to see all (or pipe to a file/program)

Some of the above are grave security problems, like wrong Unix mode for folders, even with the preinst script installed as non-root.
I always wonder why this type of tool needs to be proprietary. They clearly don’t know how to get packaging right, so they’d better just provide the source code, and let us (the Debian community) do the work for them. I don’t think there’s any secret that they are keeping by hiding how to configure the cards, so it’s not in the vendor’s interest to keep everything closed. Or maybe they are just hiding really bad code in there, that they are ashamed to share? In any way, they’d better not provide any package than this pile of dirt (and I’m trying to stay polite here…).

Nominations are open for the annual Superuser Awards. The deadline is September 4. Nominees will select to nominate their organization depending on its Open Infrastructure use case:

• AI / Machine Learning
• Containers
• CI/CD
• Edge Computing
• Data Center

This year, we will be recognizing award recipients by use case category.

All nominees will be reviewed by the community, and the Superuser editorial advisors will determine the winners. The nominees and winners will be announced in October by the OpenStack Foundation and the previous winner, Baidu.

Open Infrastructure provides resources to developers and users by integrating various open source components. The benefits are obvious, whether that infrastructure is in a private or a public context: the absence of lock-in, the power of interoperability opening up new possibilities, the ability to look under the hood, tinker with, improve the software and contribute back your changes.

The Superuser Awards recognize teams using Open Infrastructure to meaningfully improve business and differentiate in a competitive industry, while also contributing back to the open source communities.  They aim to cover the same mix of open technologies as our publication, namely OpenStack, Kubernetes, Kata Containers, Airship, StarlingX, Ceph, Cloud Foundry, OVS, OpenContrail, Open Switch, Zuul, OPNFV and more.

Teams of all sizes are encouraged to apply. If you fit the bill, or know a team that does, we encourage you to submit a nomination here.

After the community has reviewed all nominees, the Superuser editorial advisors will select winning organization(s).

When evaluating a winner for the Superuser Awards, advisors take into account the unique nature of use case(s), as well as integrations and applications of a particular team. Questions include how this team innovates with open infrastructure, for example working with container technology, NFV, and other unique workloads.

Additional selection criteria includes how the workload has transformed the company’s business, including quantitative and qualitative results of performance as well as community impact in terms of code contributions, feedback and knowledge sharing.

Winners will be recognized in a ceremony presented by the OpenStack Foundation and the previous winner, Baidu. Submissions are open now until September 4, 2020. You’re invited to nominate your team or someone you’ve worked with, too.

Launched at the Paris Summit in 2014, the community has continued to award users who show how open infrastructure is making a difference and provide strategic value in their organization. Past winners include  AT&T, CERN, City Network, Comcast, NTT Group, Tencent TStack, and  VEXXHOST.

Wonder what these organizations are doing with open infrastructure now? Superuser reached out to previous Award recipients to find out. We’ll be posting them for the next couple of weeks as a part of our “Where are they now?” series, leading up to our celebration of 10 years of OpenStack in July.

For more information about the Superuser Awards, please visit http://superuser.openstack.org/awards.

The post Annual Superuser Awards Open! appeared first on Superuser.

The RDO community is pleased to announce the general availability of the RDO build for OpenStack Ussuri for RPM-based distributions, CentOS Linux and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Ussuri is the 21st release from the OpenStack project, which is the work of more than 1,000 contributors from around the world.

The release is already available on the CentOS mirror network at http://mirror.centos.org/centos/8/cloud/x86_64/openstack-ussuri/.

The RDO community project curates, packages, builds, tests and maintains a complete OpenStack component set for RHEL and CentOS Linux and is a member of the CentOS Cloud Infrastructure SIG. The Cloud Infrastructure SIG focuses on delivering a great user experience for CentOS Linux users looking to build and maintain their own on-premise, public or hybrid clouds.

All work on RDO and on the downstream release, Red Hat OpenStack Platform, is 100% open source, with all code changes going upstream first.

PLEASE NOTE: At this time, RDO Ussuri provides packages for CentOS8 only. Please use the previous release, Train, for CentOS7 and python 2.7.

Welcome to all of you and Thank You So Much for participating!

But we wouldn’t want to overlook anyone. A super massive Thank You to all 54 contributors who participated in producing this release. This list includes commits to rdo-packages and rdo-infra repositories:

Twice during each release cycle, RDO hosts official Test Days shortly after the first and third milestones; therefore, the upcoming test days are 25-26 June 2020 for Milestone One and 17-18 September 2020 for Milestone Three.

To spin up a proof of concept cloud, quickly, and on limited hardware, try an All-In-One Packstack installation. You can run RDO on a single node to get a feel for how it works.

For a production deployment of RDO, use the TripleO Quickstart and you’ll be running a production cloud in short order.

Finally, for those that don’t have any hardware or physical resources, there’s the OpenStack Global Passport Program. This is a collaborative effort between OpenStack public cloud providers to let you experience the freedom, performance and interoperability of open source infrastructure. You can quickly and easily gain access to OpenStack infrastructure via trial programs from participating OpenStack public cloud providers around the world.

The #rdo channel on Freenode IRC is also an excellent place to find and give help.

We also welcome comments and requests on the CentOS devel mailing list and the CentOS and TripleO IRC channels (#centos, #centos-devel, and #tripleo on irc.freenode.net), however we have a more focused audience within the RDO venues.

Join us in #rdo and #tripleo on the Freenode IRC network and follow us on Twitter @RDOCommunity. You can also find us on Facebook and YouTube.

The first public commit to what would become OpenStack Nova was made ten years ago today — at Thu May 27 23:05:26 2010 PDT to be exact. So first off, happy tenth birthday to Nova!

A lot has happened in that time — OpenStack has gone from being two separate Open Source projects to a whole ecosystem, developers have come and gone (and passed away), and OpenStack has weathered the cloud wars of the last decade. OpenStack survived its early growth phase by deliberately offering a “big tent” to the community and associated vendors, with an expansive definition of what should be included. This has resulted in most developers being associated with a corporate sponser, and hence the decrease in the number of developers today as corporate interest wanes — OpenStack has never been great at attracting or retaining hobbist contributors.

My personal involvement with OpenStack started in November 2011, so while I missed the very early days I was around for a lot and made many of the mistakes that I now see in OpenStack.

What do I see as mistakes in OpenStack in hindsight? Well, embracing vendors who later lose interest has been painful, and has increased the complexity of the code base significantly. Nova itself is now nearly 400,000 lines of code, and that’s after splitting off many of the original features of Nova such as block storage and networking. Additionally, a lot of our initial assumptions are no longer true — for example in many cases we had to write code to implement things, where there are now good libraries available from third parties.

That’s not to say that OpenStack is without value — I am a daily user of OpenStack to this day, and use at least three OpenStack public clouds at the moment. That said, OpenStack is a complicated beast with a lot of legacy that makes it hard to maintain and slow to change.

For at least six months I’ve felt the desire for a simpler cloud orchestration layer — both for my own personal uses, and also as a test bed for ideas for what a smaller, simpler cloud might look like. My personal use case involves a relatively small environment which echos what we now think of as edge compute — less than 10 RU of machines with a minimum of orchestration and management overhead.

At the time that I was thinking about these things, the Australian bushfires and COVID-19 came along, and presented me with a lot more spare time than I had expected to have. While I’m still blessed to be employed, all of my social activities have been cancelled, so I find myself at home at a loose end on weekends and evenings at lot more than before.

Thus Shaken Fist was born — named for a Simpson’s meme, Shaken Fist is a deliberately small and highly opinionated cloud implementation aimed at working well in small deployments such as homes, labs, edge compute locations, deployed systems, and so forth.

I’d taken a bit of trouble with each feature in Shaken Fist to think through what the simplest and highest value way of doing something is. For example, instances always get a config drive and there is no metadata server. There is also only one supported type of virtual networking, and one supported hypervisor. That said, this means Shaken Fist is less than 5,000 lines of code, and small enough that new things can be implemented very quickly by a single middle aged developer.

Shaken Fist definitely has feature gaps — API authentication and scheduling are the most obvious at the moment — but I have plans to fill those when the time comes.

I’m not sure if Shaken Fist is useful to others, but you never know. Its apache2 licensed, and available on github if you’re interested.

I recently had to validate some interactions between the OpenStack Image service, glance, and the Compute service, nova. For this, I needed separate kernel and ramdisk images.

Work is ongoing in nova to provide support for attaching virtual Trusted Platform Modules (vTPMs) to instances. The below guide demonstrates how you can go about testing this feature for yourself.

The post How Governments Use OpenStack Around The World appeared first on VEXXHOST.

A brief history of Python2 -> Python3:

Python version 2.0 was officially released in 2000, OpenStack was founded in 2010 and has since used Python 2.0 as its base language. The Python Foundation realized that in order to prevent users from having to perform tasks in a backward or difficult way, big improvements needed to be made to the software.

We released Python 2.0 in 2000. We realized a few years later that we needed to make big changes to improve Python. So in 2006, we started Python 3.0. Many people did not upgrade, and we did not want to hurt them. So, for many years, we have kept improving and publishing both Python 2 and Python 3.

In 2015, The Python Foundation made a very clear announcement on multiple platforms to migrate to Python 3 and discontinue Python 2. This initial plan was later extended to 2020. 

We have decided that January 1, 2020, was the day that we sunset Python 2. That means that we will not improve it anymore after that day, even if someone finds a security problem in it. You should upgrade to Python 3 as soon as you can.

OpenStack Starting Support of Python 3:

With the announcement of the sunset of Python 2, it became very clear that OpenStack also could not support Python 2 for much longer. Because it would have been impossible to fix any security bugs on Python 2, it was better for OpenStack to drop its support completely and instead concentrate on Python 3.

OpenStack’s support of  Python 3 started in 2013, and many developers contributed towards the enormous task of transitioning the software. After so much hard work from the community, the Stein cycle (September 2018) was the time when running OpenStack under Python3 as default work became a community goal. The community goal is a way to achieve common changes in OpenStack. OpenStack runs under Python3 as default was a great effort and includes a lot of hard work by many developers. Doug Hellmann was one of the key developers and showed coordination and leadership with other developers and projects to finish this goal.

OpenStack Train (Oct 2019): Python3 by default:

In the OpenStack Train release (October 2019), OpenStack was tested on Python 3 by default. This meant that  you could upgrade your Cloud to Python 3 environment with full confidence. OpenStack Train was released with well tested Python 3 support, but still also supported Python 2.7. At the same time, we kept testing the latest Python 3 version, and the OpenStack Technical Committee (TC) started defining the testing runtime for each cycle. OpenStack is targeting Python 3.8 in the next development cycle beginning soon.

OpenStack Ussuri (May 2020): Python3-Only: Dropped the support of Python2:

With the Ussuri cycle, OpenStack dropped all support of Python 2. All the projects have completed updating their CI jobs to work under Python 3. This achievement allows the software to be able to remove all Python 2 testing as well as the configuration that goes along with it..

Very first thing in the Ussuri cycle, we started planning for the drop of Python 2.7 support. Dropping Python 2.7 was not an easy task when many projects depend on each other and also integrate CI/CD. For example, if Nova drops Python 2.7 support and becomes Python 3 only, it can break Cinder and many other projects’s CI/CD. We prepared a schedule and divided the work into three phases, dropping support from services first, then library or testing tools.

    Phase-1: Start of Ussuri -> Ussuri-1 milestone: OpenStack Services to start

             dropping the py2.7 support.

    Phase-2: milestone-1 -> milestone-2:  Common libraries and testing tooling

    Phase-3: at milestone-2: Final audit.

Even still, a few things got broken in initial work. So, we made DevStack as Python 3 by default which really helped move things forward. In phase 2, when I started making Tempest and other testing tools as python3-only, a lot of stable branch testing started breaking. That was obvious because Tempest and many other testing tools are branchless, meaning the master version is being used for testing both the current and  older releases of OpenStack. So all Python 2.7 testing jobs were using the Tempest master version. Finally, capping and fixing Tempest installed in py3 venv made all stable branches and master testing green.

Just a couple of weeks before the Ussuri release, we completed this work and made OpenStack as python3-only, with an updated wiki page. Two projects, Swift and Storlets, are going to keep supporting Python 2.7 for another one or two cycles.

What “OpenStack is Python3-Only” means for Users/Upgrades:

If your existing Cloud is on Python 3 env, then you do not need to worry at all. If it is on Python 2.7 and you are upgrading to Ussuri,then you need to check that your env has the Python 3.6 or higher version available. From the Ussuri release onwards, OpenStack will be working on Python 3.6 or higher only. For example, if you want to install Nova Ussuri version, then it will give an error if Python 3.6 or higher is not available. It is done via metadata (“python-requires = >=3.6”) in setup configuration file. Below is the screenshot of how the setup config file looks in the Ussuri release onwards:

python-requires = >=3.6

classifier =

      Environment :: OpenStack

      Intended Audience :: Information Technology

      Intended Audience :: System Administrators

      License :: OSI Approved :: Apache Software License

      Operating System :: POSIX :: Linux

      Programming Language :: Python

      Programming Language :: Python :: 3

      Programming Language :: Python :: 3.6

      Programming Language :: Python :: 3.7

      Programming Language :: Python :: 3 :: Only

      Programming Language :: Python :: Implementation :: CPython

If you are using a distribution that does not have Python 3.6 or higher available, then you need to upgrade your distro first. There is no workaround or any compatible way to keep running OpenStack on Python 2.7. We have sunset the Python 2.7 support from Ussuri onwards, and the only way is to also upgrade your python version. There are a few questions on the python upgrade which are covered in the FAQ section below.

FAQ:

Q1: Is Python 2 to Python 3 upgrade being tested in Upstream CI/CD?

Answer: Not directly, but it is being tested indirectly.We did not set up the grenade testing (upstream upgrade testing) for py2 setup to py3 setup. However, previous OpenStack releases like Stein and Train were tested on both the python versions. This means that the OpenStack code was not working or well-tested on the previous version before it was python3 only. This makes sure that upgrading the py2->py3 for OpenStack has been tested indirectly. If you are upgrading OpenStack from Stein or Train to Ussuri, then there should not be any issues.

Q2: How are the backport changes from Ussuri onwards to old stable branches going to be python2.7 compatible?

Answer: We still run the Python 2.7 jobs until Stable Train testing so that any backport from Ussuri or higher (which are tested on Python 3 only) will be backported on Train or older stable branches with testing on Python 2.7 also. If anything breaks on Python 2.7, it will be fixed before backporting. That way we will keep Python 2.7 support for all stable branches greater than Ussuri.

Q3: Will testing frameworks like Tempest which are branchless (using the master version for older release testing) keep working for Python 2.7 as well?

Answer: No. We have released the last compatible version for Python 2.7 for Tempest and other branchless deliverables. Branchless means that the tools master version is being used to test the current or older OpenStack releases. For example, Tempest 23.0.0 can be used as a Python 2.7 supported version and Tempest 24.0.0 or master is Python 3 only. But there is a way to keep testing the older Python 2.7 release also (until you upgrade your cloud and want Tempest master to test your cloud). You can run Tempest on a Python 3 node or virtual env and keep using the master version for testing Python 2.7 cloud. Tempest does not need to be installed on the same system as other OpenStack services, as long as the APIs are accessible from the separate testing node, or the virtual env Tempest is functioning.

For any other questions, feel free to ping on the #openstack-dev IRC channel.

 

The post OpenStack Ussuri is Python3-Only: Upgrade Impact appeared first on Superuser.

Today marks 2 months since I was laid off from my job at DataRobot. It was part of a 25% reduction that was made in anticipation of the business slump from the COVID-19 pandemic, and having just been there for 6 months, I was one of the ones let go. I have spent the last … Continue reading "Writing Again"

CERN has introduced OpenStack Ironic for bare metal provisioning as a production service in 2018. Since then, the service has grown to manage more than 5000 physical nodes and is currently used by all IT services still requiring physical machines. This includes storage or database services, but also the infrastructure for compute services. Even the “compute nodes” used by OpenStack Nova are instances deployed via Nova and Ironic (but that will be a different blog post!

Codership is proud to announce the first Generally Available (GA) release of Galera Cluster 4 for MySQL 8 and improve MySQL High Availability a great deal. The current release comes with MySQL 8.0.19 and includes the Galera Replication Library 4.5 with wsrep API version 26. You can download it now (and note that we have packages for various Linux distributions). 

Galera 4 and MySQL 8.0.19 have many new features, but here are some of the highlights:

• Streaming replication to support large transactions by splitting transaction replication then applying them in smaller fragments. You can use this feature to load data faster, as data is written to all nodes simultaneously (or not at all in case of a failure in any single node).
• Improved foreign key support, as write set certification rules are optimised and there will be a reduction in the number of foreign key related false conflicts in certifications.
• Group commit is supported and integrated with the native MySQL 8 binary log group commit code. Within the codebase, the commit time concurrency controls were reworked such that the commit monitor is released as soon as the commit has been queued for a group commit. This allows transactions to be committed in groups, while still respecting the sequential commit order.
• There are new system tables for Galera Cluster that are added to the mysql database: wsrep_cluster, wsrep_cluster_members and wsrep_streaming_log. You can now view cluster membership via system tables.
• New synchronization functions have been introduced to help applications implement read-your-writes and monotonic-reads consistency guarantees. These functions are: WSREP_LAST_SEEN_GTID(), WSREP_LAST_WRITTEN_GTID() and WSREP_SYNC_WAIT_UPTO_GTID().
• The resiliency of Galera Cluster against poor network conditions has been improved. Handling of irrecoverable errors due to poor network conditions has also been improved, so that a node will always attempt to leave the cluster gracefully if it is not possible to recover from errors without sacrificing data consistency. This will help your geo-distributed multi-master MySQL clusters tremendously.
• This release also deprecates the system variables: wsrep_preordered and wsrep_mysql_replication_bundle.

We are pleased to offer packages for CentOS 7, CentOS 8, Ubuntu 18.04, Ubuntu 20.04, Debian 10, OpenSUSE 15, and SUSE Linux Enterprise (SLES) 15 SP1. Installation instructions are similar to previous releases of Galera Cluster.

In addition to the release, we are going to run a webinar to introduce this new release to you. Join us for Galera Cluster 4 for MySQL 8 Release Webinar happening Thursday  June 4 at 9-10 AM PDT or 2-3 PM EEST (yes, we are running two separate webinars for the Americas and European timezones).  

EMEA webinar 4th of June, 2-3 PM EEST  (Eastern European Time)

JOIN THE EMEA WEBINAR 

USA webinar 4th of June, 9-10 AM PDT

JOIN THE USA WEBINAR

Headquartered out of Frankfurt, Germany; T-Systems GmbH is a German, global IT company. The 20 year-old company is a subsidiary of Deutsche Telekom and operates Open Telekom Cloud, one of the largest OpenStack-powered public clouds in the world.

Artem Goncharov, Open Telekom cloud architect, shares why T-Systems chose Zuul, an open source CI tool, and how they use it with GitHub and OpenStack.

How did your organization get started with Zuul? 

We started using Zuul for some of the internal developments using OpenStack. Getting some required changes merged into Zuul, we were able to deploy it productively as continuous integration (CI) for development of the open source tooling we offer to our clients. Moreover Zuul is currently used for monitoring of our platform services quality by periodically executing a set of tests (including permanent monitoring of the RefStack compliance). 

Currently we are working on making an internal offering inside of the Deutsche Telekom to allow usage of Zuul in different projects. Zuul is run in our own public cloud (OpenTelekomCloud) and so the VMs are also being spawned in the cloud. For the moment we are all-in OpenStack!

Describe how you’re using Zuul: 

Due to a complex (though more powerful) workflow using Gerrit, we made a decision to stay with GitHub to allow more people in the community to participate in the development of our projects. So currently we have Zuul working on our own public tenants and interacting with GitHub. Nodepool is used with an OpenStack driver to spin up virtual machines (VMs) for Zuul.

What is your current scale?

Currently a five nodes ZK, 1x Scheduler, 1x nodepool-builder, 1x nodepool-launcher, 1-2 Zuul-executors are satisfying our needs. Only 10 projects are currently effectively using Zuul (will increase soon to 30-50). Daily average 50 builds.

What benefits has your organization seen from using Zuul?

Implementing gating, while keeping control over where VMs are running and what they are doing. We now can easily implement testing workflows, that address all our needs.

What have the challenges been (and how have you solved them)?

• Functional testing against real cloud (everyone can submit a pull request in GitHub, even allowing exposing real credentials). On the other hand we want to ensure pull requests still don’t break anything before doing manual code review. We solved this by dedicating separate domains for functional tests, which is available only to Zuul, so leaked credentials can not be misused. Additionally VMs only get a token, which is then immediately revoked and “project cleanup” is executed.
• We have challenges with access controls on Github pull requests around controlling who can approve changes for merging. Currently we use a /merge comment.
• Another challenge is complex operations of Zuul in real life. This is not yet solved properly besides Ansible playbooks. Not having a dedicated ops is heavily limiting future improvements.
• Internal security department is picky on publishing that much information in logs (published to Swift), thus we have needed to override some Zuul/Zuul-jobs
• Deploying everything in containers under Podman is a challenge, thus some components are deployed natively. Podman containers on FedoraCoreOS is another challenge.
• Absence of out-of-box project admin user interface is blocking us from migrating further Jenkins jobs, which are scheduled ad-hoc.

What are your future plans with Zuul?

• Make Deutche Telekom internal offering for another subsidiaries and projects to start using Zuul
• Move to Kubernetes/OpenShift for operations of Zuul (where the challenge is “multi-cloud” for high availability)
• Start using it more for continuous deployment (CD) which is in progress
• Migrate all Jenkins job and drop it completely

Are there specific Zuul features that drew you to Zuul?

• Gating 
• Describing workflow with Ansible is so powerful, that it can literally do anything you will ever need.
• Additionally Zuul architecture is so good, that we repeat it in some internal projects (which by purpose can not be handled by Zuul, but may soon see the light in OpenStack world).

 

The post Zuul: A T-Systems Case Study appeared first on Superuser.

If I had a euro for every time someone had asked me or someone else working on nova for the ability to schedule an instance to a specific host NUMA node, I might never have to leave the pub (back in halcyon days pre-COVID-19 when pubs were still a thing, that is).

In early March—at what turned out to be one of the last non-virtual technology events held before Coronavirus lockdowns ended in-person conferences—I was fortunate to be among more than 200 attendees who gathered for two days in Boston at the Open Cloud Workshop to discuss the intersection of academic research and cloud computing software. 

The workshop is hosted by Massachusetts Open Cloud (MOC), a name that will be familiar to those who have attended OpenStack and Open Infrastructure Summits over the past few years. MOC is a consortium of universities in the New England area that share computing resources, data sets and operational practices. MOC equips its members with virtual resource sharing and on-demand user provisioning through high-bandwidth connections, all built upon OpenStack and driven by OpenStack APIs. Collectively, the members of MOC are active contributors to the OpenStack community and have delivered several Summit presentations, including in Atlanta (MOC Overview and Lessons Learned), Boston and Berlin. 

Another great outcome of MOC’s involvement in the OpenStack community is a new initiative called OpenInfra Labs. OpenInfra Labs is a community created by and for academic and research cloud operators who are testing open source code in production and publishing complete, reproducible stacks for existing and emerging research workloads. 

The primary objective of OpenInfra Labs is to deliver open source tools to run cloud, container, AI, machine learning and edge workloads repeatedly and predictably. 

OpenInfra Labs focuses on three core activities:

• Integrated testing of all the components necessary to provide a complete use case
• Documentation of operational and functional gaps required to run upstream projects in a production environment
• Shared code repositories for operational tooling and the “glue” code that is often written independently by users

The OpenInfra Labs community was initiated by MOC, the OSF, and Red Hat. It has since welcomed a host of additional core industry partners and contributors who are interested not only in supporting academic research but also in knowledge transfer to help enterprises develop reliable and powerful federated computing resources. 

Learn More about OpenInfra Labs

To learn more, check out the April 28 meeting of the OpenStack Scientific SIG, which featured an introduction to OpenInfra Labs. 

If you are interested in building infrastructure for university or research purposes or represent an ecosystem vendor who would like to contribute to OpenInfra Labs, here are three ways to get involved:

• Mailing list: http://lists.opendev.org/cgi-bin/mailman/listinfo/openinfralabs
• Freenode IRC: #openinfralabs
• Email: info@openinfralabs.org

Everyone is invited to engage with the OpenInfra Labs community and contribute your talents and expertise to current activities and community goals. 

The post OpenInfra Labs: An Open Infrastructure Collaboration for Research Use Cases appeared first on Superuser.

Fleio 2020.05 is now available! The latest version was published today, 2020-05-19. New reseller customization With the latest version we have added to the reseller frontend more customization options. We have implemented themes support and custom logo support. This was added so that your resellers can actually differentiate from the cloud provider platform. You can […]

“Brace yourselves: upcoming hardware deliveries may come with UEFI-only support.” This announcement from our hardware procurement colleagues a few months ago triggered the OpenStack and Linux teams to look into how to add UEFI support to our cloud images. Up to now, CERN cloud users had been using the very same image for virtual and physical instances and we wanted to keep it that way. This blog post summarises some of the tweaks needed to arrive with an image that can be used to instantiate virtual and physical machines, can boot both of these in BIOS and UEFI mode, and works with Ironic managed software RAID nodes for both BIOS/UEFI boot modes as well.

beagle is a command line tool for querying a hound code search service such as http://codesearch.openstack.org What’s new in 0.2.2? fix the reference to undefined function in link formatter Fix issues (contributed by Hervé Beraud) Refactor pipelines (contributed by Hervé Beraud) [doc] refresh oslo examples (contributed by Hervé Beraud)

We recently covered Installing Galera Cluster 4 with MySQL 8 on Ubuntu 18.04 , the new Galera version for MySQL High Availability. We got a request to see if we would be able to install it on Amazon Linux 2, and the short answer is yes, we are able to deploy Galera Cluster on Amazon Linux 2.

We have even published Installing a Galera Cluster on AWS guide for Geo-distributed MySQL Multi-master clustering which covers how to install a 3-node Galera Cluster on CentOS 7 to achieve disaster recovery . It turns out, Amazon Linux 2 tends to be quite compatible with this article (documentation). Heed the notices about how to configure SELinux, the firewall, as well as the security settings on AWS.

Today we will focus on installing Galera Cluster with MySQL 5.7 on Amazon Linux 2 (yes, the same instructions apply to installing the beta of MySQL 8 & Galera 4).

uname -a
Linux ip-172-30-0-54.ec2.internal 4.14.173-137.229.amzn2.x86_64 #1 SMP Wed Apr 1 18:06:08 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

[ec2-user@ip-172-30-0-54 ~]$ cat /etc/system-release
Amazon Linux release 2 (Karoo)

[ec2-user@ip-172-30-0-54 ~]$ cat /etc/os-release 
NAME="Amazon Linux"
VERSION="2"
ID="amzn"
ID_LIKE="centos rhel fedora"
VERSION_ID="2"
PRETTY_NAME="Amazon Linux 2"
ANSI_COLOR="0;33"
CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2"
HOME_URL="https://amazonlinux.com/"

So beyond the article above, all you have to do is to ensure that there is a /etc/yum.repos.d/galera.repo file:

[galera]
name = Galera
baseurl = https://releases.galeracluster.com/galera-3/redhat/7/x86_64
gpgkey = https://releases.galeracluster.com/GPG-KEY-galeracluster.com
gpgcheck = 1

[mysql-wsrep]
name = MySQL-wsrep
baseurl =  https://releases.galeracluster.com/mysql-wsrep-5.7/redhat/7/x86_64
gpgkey = https://releases.galeracluster.com/GPG-KEY-galeracluster.com
gpgcheck = 1

And then you install it via: sudo yum install galera-3 mysql-wsrep-5.7

Since this example took the smallest instance just for testing, a simple /etc/my.cnf was used to bootstrap a cluster:

default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
innodb_flush_log_at_trx_commit=0
innodb_buffer_pool_size=128M
binlog_format=ROW

wsrep_on=ON
wsrep_provider=/usr/lib64/galera-3/libgalera_smm.so

wsrep_node_name="g1"
wsrep_node_address="ip"
wsrep_cluster_name="galera4"
wsrep_cluster_address="gcomm://ip1,ip2,ip3"
wsrep_provider_options="gcache.size=128M; gcache.page_size=128M"
wsrep_sst_method=rsync

When you install MySQL 5.7, you’ll have to remember that you need to grab the password from the MySQL log, so do this via grep password /var/log/mysqld.log. After that, login and remember to change the root password by doing something like alter user 'root'@'localhost' identified with mysql_native_password by 'rootyes123A!';. Go ahead and run mysqld_bootstrap on the first node, and start MySQL normally on the 2nd and 3rd nodes.

We ran the MySQL test suite which has Galera Cluster tests as well, and the tests passed. As a company, Codership, considers the Amazon Linux 2 distribution compatible with our CentOS 7 binaries. Don’t forget we also release for Ubuntu, Debian, CentOS, openSUSE, Red Hat Enterprise Linux, and SUSE Enterprise Linux. This is of course in addition to FreeBSD. Expect a lot more distributions when MySQL 8 + Galera 4 goes Generally Available (GA).

Spotlight on: OpenStack Ussuri 

Ussuri, the 21st release of OpenStack, includes improvements in core functionality, automation, cross-cell cold migration, containerized applications, and support for new use cases at multiple levels in the stack.

Thank you to the more than 1,000 contributors from more than 50 countries and 188 organizations that contributed to the OpenStack Ussuri release. With these metrics, OpenStack continues to be one of the top three open source projects in the world in terms of active contributions, along with the Linux kernel and Chromium.

Among the many enhancements contributors delivered in Ussuri, three highlights are:

1. Ongoing improvements to the reliability of the core infrastructure layer
2. Enhancements to security and encryption capabilities
3. Extended versatility to deliver support for new and emerging use cases

This year, we are celebrating 10 years of the OpenStack project. Since the software pioneered the concept of open infrastructure ten years ago, it has rapidly become the open infrastructure-as-a-service standard. Recently, new workload demands like AI, ML, edge, and IoT have given rise to the project’s support for new chip architectures, automation at scale down to the bare metal, and integration with myriad open source components. Intelligent open infrastructure—the integration of open source components that are evolving to meet these demands—creates an infrastructure that is self-monitoring, self-replicating, and delivering a versatile set of use cases.

The Ussuri release reinforces what OpenStack is well known for—namely, rock-solid virtual machine, container, and bare metal performance at massive scale. At the same time, Ussuri delivers security improvements via Octavia and Kolla. And, it supports new and emerging use cases with improvements to projects like Zun and Cyborg. 

Learn more about Ussuri features, check out screenshots from different OpenStack projects, and find out who contributed to the 21st OpenStack release at openstack.org/ussuri.

OpenStack Foundation news

Project Teams Gathering (PTG) June 1-5

• Register now for free!  
• Schedule is now live. If your team is interested in meeting at the PTG, please email ptg@openstack.org. Time slots are still available!

OpenDev

• Large-scale Usage of Open Infrastructure Software
  June 29 – July 1, 2020. Register now for free!
  
• Hardware Automation
  July 20 – 22, 2020
• Containers in Production
  August 10 – 12, 2020

Airship: Elevate your infrastructure

• Airshipctl has completed its 2.0 alpha milestone and is now working towards beta.
• Airship will be participating in the virtual PTG! View the draft agenda, and make any suggestions by May 23.
• If you are evaluating or running Airship, share your feedback in the Airship User Survey! Take the chance and provide anonymous feedback back to the community. Take the user survey now.

Kata Containers: The speed of containers, the security of VMs

• We are happy to announce the new stable release for Kata 1.11.x branch. This is the first official release for 1.11.x and includes many changes compared to 1.10.x. See more details on the 1.11.x release.
  • Take a look at the full release notes for the changes in this release here.
  • We have released a new version of 1.10.x branch: 1.10.4.
• If you are running Kata Containers, the user survey is your opportunity to provide anonymous feedback to the upstream community, so the developers can better understand Kata Containers environments and software requirements. Take your Kata survey today.

OpenStack: Open source software for creating private and public clouds

• Ghanshyam Mann announced the completion of the Python 3 transition goal. It’s been a long journey since we started to introduce Python 3 support in 2013! OpenStack components and libraries are now Python3-only (except Swift and Storlets which will continue to support Python 2 in Ussuri).
• Following the recent elections, the OpenStack Technical Committee selected Mohammed Naser as its chair for the Victoria cycle. It also confirmed the removal of the Congress and Tricircle projects in the Victoria release (scheduled for October 2020), and the merge of the LOCI team into the OpenStack-Helm team, due to commonality of scope.
• Are you ready to take your cloud skills to another level? The updated Certified OpenStack Administrator (COA) exam can help you with that. Check out the OpenStack COA exam and become a Certified OpenStack Administrator

StarlingX: A fully featured cloud for the distributed edge

• The nomination period for the upcoming TSC elections is starting next week! For details about the process please see the elections website. 
• The StarlingX user survey is live. Take the StarlingX user survey and provide anonymous feedback to the upstream community.

Zuul: Stop merging broken code

• Zuul’s Github driver now supports reporting results via the Github Checks API. Find out more in the Zuul Github driver docs.
• Work has begun to support multi architecture docker image builds. Help us improve the system by setting the ‘arch’ parameter on your docker image build jobs.
• Are you a Zuul user? Fill out the Zuul User Survey to provide feedback and information around your deployment. All information is confidential to the OpenStack Foundation unless you designate that it can be public. Take your Zuul survey today.

Check out these Open Infrastructure Community Events!

• May 20, SUSECon Digital’20
• June1-5, Project Team Gathering (PTG)
• June 2-3, Virtual Cisco Live
• June 16-18,  StackConf online
  • OSF presentation by Kendall Nelson
• June 29-July 1, OpenDev – Large-scale Usage of Open Infrastructure Software
  
• June 29-July 2, Virtual OpenSource Summit 
  • OSF presentation by Kendall Nelson
• July 15, Virtual Cloud Operator Day Tokyo
• July 20-22, OpenDev – Hardware Automation
• August 10-12, OpenDev – Containers in Production

For more information about these events, please contact denise@openstack.org

Questions / feedback / contribute

This newsletter is written and edited by the OSF staff to highlight open infrastructure communities. We want to hear from you! If you have feedback, news or stories that you want to share, reach us through community@openstack.org . To receive the newsletter, sign up here.

The post Inside open infrastructure: The latest from the OpenStack Foundation appeared first on Superuser.

If you’ve been around the OSF community for any amount of time, chances are you’ve heard the name CERN.

Famous for their Large Hadron Collider, Higgs boson, and antimatter studies, the Geneva-based laboratory has spent decades researching physics and the universe. So what does that have to do with OpenStack? All of that research produces massive amounts of data, thus requiring a substantial amount of infrastructure.

Keep reading to find out how CERN’s OpenStack environment has evolved since they won the first Superuser Award at the OpenStack Summit six years ago.

What has changed in your OpenStack environment since you won the Superuser Awards?

At the OpenStack Summit Paris in 2014, CERN received the first Superuser Award from Guillaume Aubuchon, CTO of Digitalfilm Tree.

At the time, CERN’s cloud had been in production for a year with 65,000 cores running Havana providing VMs, images and identity. After six years and 13 upgrades, the CERN cloud now covers 11 OpenStack projects adding containers, bare metal, block, share, workflows, networking and file system storage.

What is the current size of CERN’s OpenStack environment?

Currently, the CERN cloud is around 300,000 cores across 80 cells with big recent growth in OpenStack Magnum to manage Kubernetes clusters, OpenStack Ironic servers for all the computer center hardware, and Fileshares with CephFS.

What version of OpenStack is CERN running?

We are in the process of upgrading from Stein to Train with most components already running Train. We use the RDO distribution.

What open source technologies does your team integrate with OpenStack?

The list is very long! The aim for the CERN cloud environment was to build a toolchain based on a set of open source projects which could also be used by other labs collaborating with CERN. A few examples are:

Cloud and Containers

• CentOS for Linux
• RDO for an OpenStack distribution
• Kubernetes for container orchestration with Helm
• Tungsten Fabric for software defined networking

Configuration

• Puppet and Foreman for configuration management
• Terraform for automated provisioning (including external clouds)

Monitoring

• Collectd for sensors
• Prometheus for containers
• Flume and Logstash for transport
• Grafana, Kibana and Jupyter for displays

Storage

• Ceph for image, block, shares and object store
• MySQL, Postgres, InfluxDB for databases
• Hadoop and ElasticSearch for logs and archive

Identity

• FreeIPA and Keycloak for authentication and single sign on

Workflows

• Gitlab for version control, continuous integration
• Koji for builds
• Rundeck for automation

What workloads are you running on OpenStack?

Over 90% of the infrastructure in the CERN computer center is managed and provisioned by OpenStack. This includes the physics processing and storage, databases along with the infrastructure for the laboratory administration. The remaining hardware in the computer center is now being enrolled into Ironic to ensure strong resource management, accounting and lifecycle tracking.

How big is your OpenStack team?

The production support team in the CERN IT Department is around seven engineers with further students and fellows contributing to various project enhancements.

How is your team currently contributing back to the OpenStack project? Is your team contributing to any other projects supported by the OpenStack Foundation (Airship, Kata Containers, StarlingX, Zuul)?

CERN has made over 1,000 commits to OpenStack since the implementation started in 2011. The largest three OpenStack projects CERN have contributed to are Magnum, Nova and Keystone. CERN’s experiences have been presented at more than 30 talks at OpenStack summits as well as regional events such as the open Infrastructure days which have provided an opportunity to share the experiences of running OpenStack at scale and our current focus areas. This included an OpenStack day at CERN in 2019 covering experiences of OpenStack usage in science and hosting the Ironic mid-cycle meetup in 2020.

The CERN blog is available at https://techblog.web.cern.ch/techblog/ and local developments are shared at https://github.com/cernops.

CERN has also contributed to governance and project management including an elected OpenStack individual board member, two members of the User Committee and PTL/core roles in Magnum, Keystone and Ironic.

What kind of challenges has your team overcome using OpenStack?

Given the demands of the Large Hadron Collider and the CERN experiments, provisioning more computing capacity without increasing the number of engineers was a challenge to overcome. Working with other members of the open source community in areas such as Container Orchestration-as-a-Service, Nova Cells, Identity Federation and Spot Market functionality has allowed these new features to be developed, reviewed by community and further enhanced. OpenStack Special Interest Groups such as the Scientific SIG and Large Scale SIG have provided a useful framework for debate, information sharing and common contribution.

A single framework for tracking, authentication and accounting for bare metal, virtual machines, storage and containers has been a major benefit for the CERN IT department. Allowing users to have self-service resources in a few minutes while ensuring that these are clearly allocated (and expired if appropriate) allows the CERN cloud users to focus on the goals of the laboratory rather than how to get the infrastructure they need.

Stay tuned for more updates from previous Superuser Award winners!

 

Cover Image: CERN

The post Where are they now? Superuser Awards winner: CERN appeared first on Superuser.

The post 3 KPIs Your Business Needs For Successful Cloud Infrastructure appeared first on VEXXHOST.

Since the beta of Galera Cluster 4 with MySQL 8 has been released, we’ve had people asking questions as to how to install it on Ubuntu 18.04. This blog post will cover just that.

Prerequisites

• All 3 nodes need to have Ubuntu 18.04 installed
• Firewall (if setup) needs to accept connections on 3306, 4444, 4567, 4568 (a default setup has the firewall disabled)
• AppArmor disabled (this is as simple as executing: systemctl stop apparmor and systemctl disable apparmor).

Installation and Configuration

We have good installation documentation as well as a quick how to get this installed in AWS (though this is CentOS centric).

First, you will need to ensure that the Galera Cluster GPG key is installed:

apt-key adv --keyserver keyserver.ubuntu.com --recv BC19DDBA

 

This is followed by editing /etc/apt/sources.list.d/galera.list to have the following lines in the file:

deb https://galeracluster.com/wsrep_8.0.19-26.3-rc/galera-4/ubuntu bionic main

deb https://galeracluster.com/wsrep_8.0.19-26.3-rc/mysql-wsrep-8.0/ubuntu bionic main

You should now run an apt update and then install Galera 4 with MySQL 8:

apt install galera-4 mysql-wsrep-8.0

You are now told to enter a root password as apt/dpkg supports interactivity during installations. Please enter a reasonably secure password. Then you are asked if you should use a strong password, which is caching_sha2_password (you are encouraged to pick this).

 

Then you need to edit the/etc/mysql/mysql.conf.d/mysqld.cnf file to add the following lines:

default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
innodb_flush_log_at_trx_commit=0
innodb_buffer_pool_size=128M
binlog_format=ROW
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_node_name="g1"
wsrep_node_address="ipaddress"
wsrep_cluster_name="galera4"
wsrep_cluster_address="gcomm://ip1,ip2,ip3"
wsrep_provider_options="gcache.size=128M; gcache.page_size=128M"
wsrep_slave_threads=4
wsrep_sst_method=rsync

Remember that you will need to change wsrep_node_name and wsrep_node_address. The above is a very basic configuration.

Ensure that you have stopped MySQL (systemctl stop mysql). On the first node, execute:

mysqld_bootstrap

You can execute: mysql -u root -p -e "show status like 'wsrep_cluster_size'” and see:

+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 1     |
+--------------------+-------+

Now, when you bring up the second node as simply as systemctl start mysql, you can execute the same command above and will see that the wsrep_cluster_size has increased to 2. Repeat this again for the third node. You can also choose to test replication by creating a database and table on one node, and see that the replication is happening in real time.

To find out more, start MySQL and execute show status like 'wsrep%';.

We hope this helps you get started, and we are definitely looking at providing packages for Ubuntu 20.04 which just got released. Look forward to more guides on getting started on other types of Linux distributions.

 

With the current Coronavirus lockdown affecting many countries (including all the countries in which we work), remote working and videoconference has become the only way to be productive.

At StackHPC our flexible and distributed team is already used to working this way with clients. We have gone further, and developed online training for workshops we would normally deliver in person.

Spotlight on: Upcoming OSF Virtual Events  

We’re Going Virtual!
Last month, based on the input from the community, board, and the latest information available from the health experts, we announced our decision not to host the OpenDev + PTG in Vancouver this June. Instead, we’d like to invite you to join us for the upcoming, first of its kind virtual OSF event series! 

OpenDev 

Join us for OpenDev, an ongoing collaborative event series focused on advancing open source software and communities. Participants can expect discussion oriented, interactive sessions exploring challenges, sharing common architectures, and collaborating around potential solutions. Previous OpenDev events include Edge Computing in 2017 and CI/CD in 2018.

The virtual OpenDev event series will consist of three separate events hosted in the upcoming months, each focused on a different open infrastructure topic:

• Large-scale Usage of Open Infrastructure Software
  June 29 – July 1, 2020. Register now!
• Hardware Automation
  July 20 – 22, 2020
• Containers in Production
  August 10 – 12, 2020

If you are interested in the Hardware Automation or Containers events, we’d love your input on the best time block to host the sessions before registration goes live. Please share your preference here: Hardware Automation, Containers in Production.   

PTG

The Project Teams Gathering (PTG) is an event where open source upstream contributors (user working groups, development teams, operators, SIGs) gather to collaborate on software requirements and roadmaps. Registration is now open for the virtual PTG, taking place June 1-5.

The event is open to all OSF projects, and teams are currently signing up for their time slots. Find participating teams here, and the schedule will be posted on the PTG website in the upcoming weeks. Join us! 

Sponsor Shout Out

We also want to thank all of the OpenStack Foundation Platinum, Gold, and Corporate sponsors for their ongoing support that make these virtual events possible and free to attend. We couldn’t do it without you!  

Airship: Elevate your infrastructure

• Join Airship at the virtual PTG! Stay up to date on meeting plans via the mailing list.
• Check out the April update on the blog for the latest Airship 2.0 progress, virtual March meeting notes, and more.
• Interested in learning how to set up a Cluster API development environment? Find step-by-step directions and documentation in this tutorial. This development environment will allow you to deploy virtual nodes as Docker containers in Kind, test out changes to the Cluster API codebase, and gain a better understanding of how Airship works at the component level to deploy Kubernetes clusters.
  • Read more about how Airship 2.0 plans to use Cluster API in this blog post.

Kata Containers: The speed of containers, the security of VMs

• The community has set up an etherpad page for Kata virtual PTG. Please register your name and time slots if you plan to attend it. Also if you have anything to discuss during PTG, feel free to add it there as well.
• Kata Containers Demo: A Container Experience with VM Security
  • Eric Ernst, principal systems software engineer, for Ampere and Bharat Kunwar, software engineer, for StackHPC explain how Kata Containers work, as well as its performance and security advantages. They also describe a use-case scenario and new research.

OpenStack: Open source software for creating private and public clouds

• The OpenStack community is in the final preparation stage for the ‘Ussuri’ release, scheduled for May 13. Discussion on how to properly celebrate virtually is under way on the openstack-discuss mailing-list.
• The election cycle to designate the stewards for our next development cycle, Victoria, just concluded. The Technical Committee (now a group of 11 people) welcomes two new members: Belmiro Moreira and Kristi Nikolla. They, along with three returning members (Graham Hayes, Mohammed Naser, and Rico Lin) make the newly elected members of the TC. Also, huge thank you to Alexandra Settle, Jim Rollenhagen, Thierry Carrez, and Zane Bitter for their past service. PTLs for project teams were also renewed, with 12 new people stepping up.
• The 2019 User Survey results have been analyzed by the OpenStack Technical Committee. Read the full report for more information.
• The Kolla team set up a new way to engage with users, and improve communication between Kolla operators and Kolla developers: the Kolla Klub. Interested? Read more information on how to join the next meeting.

StarlingX: A fully featured cloud for the distributed edge

• The community is preparing for the upcoming virtual PTG to discuss topics like planning for the 5.0 release cycle, testing and cross-project collaboration. Stay tuned for updates as the event is getting closer!
• The next StarlingX TSC elections are happening in less than a month! Check out the details on the elections web page in case you are interested in running for one of the 4 seats.

Check out these Open Infrastructure Community Events!

• May 20, SUSECon Digital’20
• June1-5, Project Team Gathering (PTG)
• June 2-3, Virtual Cisco Live
• June 16-18,  StackConf online
  • OSF presentation by Kendall Nelson
• June 29-July 1, OpenDev – Large-scale Usage of Open Infrastructure Software
  
• June 29-July 2, Virtual OpenSource Summit 
  • OSF presentation by Kendall Nelson
• July 15, Virtual Cloud Operator Day Tokyo
• July 20-22, OpenDev – Hardware Automation
• August 10-12, OpenDev – Containers in Production

For more information about these events, please contact denise@openstack.org

Questions / feedback / contribute

This newsletter is written and edited by the OSF staff to highlight open infrastructure communities. We want to hear from you! If you have feedback, news or stories that you want to share, reach us through community@openstack.org . To receive the newsletter, sign up here.

The post Inside open infrastructure: The latest from the OpenStack Foundation appeared first on Superuser.

StackHPC are pleased to announce along with our partner, Linomtha ICT, a new OpenStack system at the Centre for High Performance Computing to support researchers and academics across South Africa. StackHPC worked with Linomtha, Supermicro and Mellanox to jointly engineer the system and support project management. The system deploys OpenStack Kayobe together with a billing system engineered around CloudKitty & Monasca.

The text below can also be found on Linomtha's blog.

The Centre for High Performance Computing (CHPC) is proud to announce a new on-premise cloud infrastructure that has been delivered recently under exceptional circumstances. The delivery of the system is testament to the close collaboration CHPC has with Linomtha ICT (SA) and their strategic technology partners StackHPC Ltd (UK), Supermicro (SA), and Mellanox (IL), and will ensure that the CHPC has a stable environment to continue to deliver on its mandate. The OpenStack Production Cloud Services caters for the CHPC scientific users executing, for example, custom workflows, embarrassingly parallel workloads and webhosting. The OpenStack services will also be a road-header for such HPC configuration in the future. It is envisaged that this platform will build both the skills and operational experience for CHPC, to develop, provision and operate a National federated OpenStack platform, which will be linked with other countries, that are involved in the Square Kilometre Array (SKA) project.

The Cloud infrastructure has been designed in such a way that the transportation of data to and from the CHPC to the external institutions that are connected to the NICIS network or those that want to utilise the DIRISA long term storage can be achieved.

Linomtha, a majority black owned company comprising of an energetic mix of business people, entrepreneurs and engineers with experience and skills from various fields, together with CHPC, successfully completed the installation of the OpenStack Production Cloud Service project.

Linomtha recognises the important role that ICT can play in terms of economic growth, social inclusion and government efficiency. The key individuals driving Linomtha all have extensive practical experience in the field of ICT, working on large scale government and private sector projects across the country and are recognized as experts, both locally and internationally. Linomtha is a value-added reseller of StackHPC as well as Supermicro, the key technology partners in responding to CHPC's RFP. LinomthaICT's sister company, LinomthaID, provided the Billing/Invoicing portal for the solution through its VOIS platform.

The CHPC has been running a VMware virtual environment or cluster (IT-Shop) previously, as an alternative to support scientific projects or applications which were not best suited for High Performance Computing Platform. Projects were mostly hosted on the IT-Shop Cluster as web portals to support these special scientific groups to share data-knowledge or compute their specific scientific workflows.

The IT-Shop cluster is currently over-provisioned, especially for memory resources, due to the large demand of numerous projects requiring high-spec virtual machines and has become an unreliable environment, no longer able to adequately serve the users, as the performance and available capacity has deteriorated over time.

The CHPC OpenStack Production Cloud will provide a sufficient and efficient environment to continue to support these kinds of projects from the IT-Shop. In addition, the CHPC Cloud Solution will offer the following benefits and functionalities which were not met on the current IT-Shop:

• Self-Service Portal. CHPC Cloud users will now have the ability to deploy application on-demand with limited technical support to promote rapid and efficient IT Service.
• Metered Service and Resource Monitoring. CHPC will now be able to monitor resource utilization from individual users or projects to prepare billing statement as per our cost-recovery model.
• Avoid Vendor Lock-In. The OpenStack solution is open source. CHPC will Reduce-On-Cost related to proprietary software such as the VMware vSphere Solution.
• Enable Rapid Innovations (DevOps). The CHPC Staff can significantly reduce on development and testing periods and have more freedom to experiment with new technology or even do customisation to expand the capabilities of the OpenStack Cloud.

The CentOS based OpenStack Cloud is a self-service Virtual Machine (VM) provisioning portal for CHPC Administrators where common administrative tasks like VM creation, recoup unused resources, and infrastructure maintenance tasks are automated and capacity analysis, utilization, and end-user costing reports can be generated.

Through this project, CHPC administrators have been exposed to the initial implementation of the OpenStack system and have hands on experience of performing the various required tasks.

Linomtha together with Supermicro, Mellanox, StackHPC and LinomthaID have jointly-engineered the CSIR OpenStack Cloud Solution. This solution is built on Supermicro Server and Storage systems that deliver first to market innovation and optimized for value, performance and efficiency. Using the Supermicro TwinPro Servers to provide 320cores/640threads (2.50 - 3.90GHz) and over 3TB DDR4 2933 Memory providing some 9GB RAM per core all in just 4U of rack space, connected through Mellanox 100GB Ethernet Networking to Supermicro Ultra and Supermicro Simply Double Servers providing a CEPH Storage cluster with over 1.5PB (1500TB) of Mechanical Disk Storage and more than 220TB of Flash Storage.

OpenStack was deployed with OpenStack Kayobe, a tool largely developed and maintained by StackHPC within the OpenStack Foundation. Kayobe provides for easy management of the deployment process across all compute, storage and networking infrastructure using a high degree of automation through infrastructure as code. Kayobe invokes a containerised Kolla control plane providing for easier upgrades and maintainability. In addition to the infrastructure element, Kayobe also deploys rating, monitoring and logging services providing insight on resources and their use.

The integration of the invoicing engine and portal, VOIS, was undertaken by LinomthaID who extracted the billing information of the Openstack Usage provided by CloudKitty, and localised and customised the invoicing to CHPC requirements.

Ensuring there was constant and clear communication during the project, the Linomtha project team ensured daily stand-up calls, weekly progress meetings and utilised tools such as Slack and Google Meet - which allowed for quick turnaround times for addressing queries.

We were impressed with the Slack communication and the shared Google drive provided for documentation between team members, it made the sharing of thoughts much easier resulting in solving problems quickly and collaboratively.

A single point of contact was identified from each stakeholder involved in the project, allowing for communication to flow to the right people and ensuring action items were accomplished and ultimately, meeting the challenging deadline.

One component of the project was training which initially was to take place on-site, but due to the restraints of COVID-19, the team improvised and the training was successfully delivered remotely, over a five-day period. The training was deemed a great success! The training has ensured that the CHPC Administrators have sufficient knowledge and confidence to efficiently manage the environment.

The training was one of the best we've attended, the setup was great, the trainer's expertise and their quick thinking or rather well-considered answers in providing solutions to our questions was impressive. The information gathered and shared is helping us with our OpenStack operations and we can only grow strong from here with our OpenStack expertise as well.

No project is without challenges and this one was no exception. One of the lessons learnt was that the time between the initial workshop and implementation was too compressed. It did not allow for all team members, including technical resources, to fully understand the finer technical detail of the project and allow them to all contribute.

Despite the challenges encountered during the project, through the professional Linomtha Project Management deployment, milestones were met, the deadline accomplished, quality documentation drafted, successful training delivered and the handover to operations completed within the required deadline and budget.

Our team draws on a broad base of expertise in the technologies used to build the high-peformance cloud. Occasionally our research breaks new ground, and we are always thrilled with the opportunity to talk about it.

The New Stack recently approached Bharat from our team to participate in a webinar on Kata containers. Often Kata containers are pitched with the soundbite "the speed of containers, the security of VMs". Bharat's previous research on IO performance suggested the real picture was more nuanced.

The end result is a great article and webinar (with Eric Ernst from Ampere), which can be read here. Bharat's presentation can be downloaded here (as PDF).

The post 6 Reasons Why You Should Run Your Containers On OpenStack appeared first on VEXXHOST.

The post 3 Tips For Easy Cloud Application Development appeared first on VEXXHOST.

This post is part of the Women of Open Infrastructure series to spotlighting the women in various roles in the community who have helped make the Open Infrastructure successful. With each post, we learn more about each woman’s involvement in the community and how they see the future of Open Infrastructure taking shape. If you’re interested in you are interested in being featured or would like to nominate someone to tell their stories, please email editor@openstack.org.

This time we’re talking to Melanie Witt from the OpenStack Nova project. She tells Superuser about how she became an active contributor in the community and her best practices on stay on top of things in the fast-moving open source industry.

What’s your role (roles) in the Open Infrastructure community?

I am a core reviewer in the OpenStack Nova project. I also served as Nova Project Team Lead (PTL) for the Rocky and Stein release cycles.

What obstacles do you think women face when getting involved in the Open Infrastructure community?   

For me, I think the primary obstacle I faced when I was first getting involved in the community was being different than most everyone else. Questions like, “will they accept me?” or “do I belong here?” came to my mind. I think I started off too shy because of this.

The community documentation made it easy for me to get started and before I knew it, I was proposing patches, filing and triaging bugs, and chatting on IRC with members of the community. Everyone was (and still is, eight years later) so welcoming and willing to help me. I love this community and am still so happy I joined. The only thing I would change is I would have started off less shy.

Why do you think it’s important for women to get involved with open source?

I think it’s important for everyone to get involved with open source. Open source software is such a unique model where a large community of contributors works together on software we all share. Each contribution is multiplied not only to a single company’s product or customers but to everyone in the world who uses that same open source software. It’s like “distributed software.” We have so many improvements constantly flowing into the software from different people and organizations that it can get difficult to keep track of all of them (in a good way!).

Open source is so important and impactful that I think everyone who is interested in getting involved should absolutely get involved. You might hesitate and wonder whether it’s for you if you are different, but I encourage everyone to give it a try. It can be very rewarding.

Efforts have been made to get women involved in open source, what are some initiatives that have worked and why?

I think the most important thing is general community encouragement. When someone asks a question in an IRC channel or when they propose a patch, file a bug, post to the mailing list, having a community that responds with friendliness, helpfulness, and actionable guidance makes all the difference, in my opinion. When someone reaches out to make a contribution, they’ve put themselves out there to a new community. It’s important to help them learn the ropes and by doing that you also let them know you appreciate their contribution. When people know their contributions are appreciated, they are more likely to return and make more contributions. Keep it going and eventually, they will hold positions in the community like core reviewer, PTL, Technical Committee (TC) member, etc.

Community documentation is the second most important thing, in my opinion. This will be the first thing that prospective contributors see and interact with, so it’s important that it be clear, concise, and easy to consume as a layperson. All of us had to start somewhere and the easier it is to understand the documentation as a new person who doesn’t know anything yet, the more likely we are to obtain new contributors. It’s hard to make that first step to get involved when you have no clue what anything is or how to use it.

Open source moves very quickly. How do you stay on top of things and what resources have been important for you during this process?

I do a lot of things to stay up to speed. First, I have a separate email address for open source work and I set up email filters for Gerrit notifications, launchpad bugs, and mailing lists. This helps me to find highlights in each area: of code reviews|bugs|community discussion mailing list quickly. Next, I try to attend community meetings on IRC and if I can’t attend, I read the recorded meeting log created by the channel meetbot. I have my IRC client set up with a ZNC bouncer and receive notifications when my IRC nick is mentioned. I review these at the start of each workday and respond to items related to me.

By doing these things, I’m able to have at least a high-level idea of what’s going on even when I’m more occupied with downstream work. During the busiest of downstream times, I spend at least 15 minutes a day reviewing the code review|bug|community mailing list email filter folders just so I have an idea what’s been going on.

The last thing I’ll mention might sound obvious, but another thing to do is to let people know when you’re interested in something. If you’re interested in a feature or a bug fix, chime in on the review or the bug or  IRC. When people know others are interested, they’re more mindful about communicating updates and will likely keep you in the loop directly.

What advice would you give to a woman considering a career in open source? What do you wish you had known?

I would say, give it a try! Each open source community is different and it’s important to know that you can find the right community that is a good match for you. Not everyone finds the same fit in the same communities. I would advise not to give up on a career in open source if the first community you tried was not a good match. Communities are mostly about people, not only code, so there is an element of match-making personalities and styles involved.

I think the number one thing I wish I had known a long time ago is how rewarding it is to take risks. I’m actually thinking more about small risks, like asking questions, jumping into a code review|bug report|community mailing list post that you weren’t previously involved with, asking for advice, and proposing an idea or patch and potentially being wrong or having people not like your idea. Lots of these things can feel like embarrassments or failures but I’ve learned over the years that these are things that make you part of a community and team. You might feel embarrassed but what others see is that you are engaged and motivated to solve problems. That you are someone they might want to ask to weigh in on something later or you might be someone to go to for questions on that topic.

Push yourself to ask questions and share thoughts on code reviews, even if they are not perfect. Oftentimes, an imperfect question or comment will build a little bridge for someone else to catch a problem in a patch or see a way to improve a patch. This helps build your relationship with the community as people get to know your contributions and get more chances to appreciate them.

Taking risks is hard but I think it’s really worth it. I’d say it’s even essential. Otherwise, you stay “distant” in the community, to some degree. So, please take risks. I have been in the community for many years and I am still pushing myself to take risks.

The post Women of Open Infrastructure: Meet Melanie from the OpenStack Nova Project appeared first on Superuser.

Here at Mirantis we're committed to making things easy for you to get your work done, so we've decided to put together this guide to Kubernetes.

Three incredible articles by Lars Kellogg-Stedman aka oddbit – mostly about adjustments and such made due to COVID-19. I hope you’re keeping safe at home, RDO Stackers! Wash your hands and enjoy these three fascinating articles about keyboards, arduino and machines that go ping…

Some thoughts on Mechanical Keyboards by oddbit

Since we’re all stuck in the house and working from home these days, I’ve had to make some changes to my home office. One change in particular was requested by my wife, who now shares our rather small home office space with me: after a week or so of calls with me clattering away on my old Das Keyboard 3 Professional in the background, she asked if I could get something that was maybe a little bit quieter.

Read more at https://blog.oddbit.com/post/2020-04-15-some-thoughts-on-mechanical-ke/

Grove Beginner Kit for Arduino (part 1) by oddbit

The folks at Seeed Studio have just released the Grove Beginner Kit for Arduino, and they asked if I would be willing to take a look at it in exchange for a free kit. At first glance it reminds me of the Radio Shack (remember when they were cool?) electronics kit I had when I was a kid – but somewhat more advanced. I’m excited to take a closer look, but given shipping these days means it’s probably a month away at least.

Read more at https://blog.oddbit.com/post/2020-04-15-grove-beginner-kit-for-arduino/

I see you have the machine that goes ping… by oddbit

We’re all looking for ways to keep ourselves occupied these days, and for me that means leaping at the chance to turn a small problem into a slightly ridiculous electronics project. For reasons that I won’t go into here I wanted to generate an alert when a certain WiFi BSSID becomes visible. A simple solution to this problem would have been a few lines of shell script to send me an email…but this article isn’t about simple solutions!

Read more at https://blog.oddbit.com/post/2020-03-20-i-see-you-have-the-machine-tha/

The post Why Decision Makers Need To Build Cloud Culture appeared first on VEXXHOST.

The key factor that is missing in many discussions about edge computing is a clear view of how we will be expected to deploy, manage and gain a clear picture of these edge resources.

2020 has already shown us that the future can be unpredictable. We’re just three short months into the year, and already our global community has experienced the unexpected in myriad ways. In the open infrastructure community—and the OpenStack Foundation (OSF) specifically—we certainly don’t have a “crystal ball” for what 2020 has in store, but we are confident that the future holds progress, because we have a shared vision and three critical assets:

1. an operational model for building open source software and communities that truly works;
2. strong open source software projects that are making steady progress; and
3. a global community that continues to make great strides in engagement and collaboration.

The Vision

The open infrastructure community remains committed to the OSF mission of helping people build and operate open infrastructure. Our vision, articulated in “big picture” terms, is our community’s four-way method:

1. identify use cases
2. collaborate across communities
3. build the required new technology
4. test everything end-to-end

You can read more about this in theOSF 2019 Annual Report, which highlights our recent achievements across the community and expresses some of our goals for the year ahead.

A Model that Works

A couple of years ago, our community recognized that we had something special at OSF: a successful approach to helping software communities thrive and grow, an approach that was worth replicating. At the same time, we recognized that the best way to support open infrastructure was to expand our contributions to a broader ecosystem of open source projects.

We developed a formal model for project supportthat includes (1) accepting pilot projects to nurture and (2) confirming for long-term support those projects that demonstrate progress and our community’s core values (Four Opens). Using this model, we have confirmed three new open infrastructure projects to complement OpenStack in powering the world’s open infrastructure: Kata Containers, Airship and Zuul. Those are in addition to active growth in the StarlingX community. In 2020, our goal is to create more documentation around this model.

Progress with Open Infrastructure Software Projects

In 2019, the OSF community had a productive year, merging 58,000 code changes to produce open source infrastructure software like Airship, Kata Containers, StarlingX, and Zuul, along with the third most active open source project in the world, OpenStack.

Here’s a quick run-down of what each of these projects aspire to accomplish in 2020:

• Airship: The Airship community plans a complete rebuild of Airship core code with a beta version planned for June and a full 2.0 release later in 2020. In addition, Airship 2.0 will penetrate into more industry domains such as Common NFVi Telco (CNTT) and 5G testbeds. Other goals include:
  • Supporting smaller deployments
  • Making all workflows fully declarative
  • Adopting upstream entrenched projects
  • Enabling simpler document creation and management (Airship YAML was hard)
  • Providing an improved flow for executing updates (changing the tires while the car is moving is hard)/li>
  • Penetrating into the NFVi domain, enabling the reference implementation of Common Telco NFVi (CNTT) and supporting its VNF certification.
  • Capitalizing on hardware donations by Ericsson and Dell for an Airship community lab to leverage as 3rd-party CI
  • Empowering the 5G testbed by Ericsson

• Kata Containers:Looking ahead to 2020, the Kata community will focus on supporting its growing user community, driving innovation with the Kata 2.0 roadmap, and continuing open collaboration with the rapidly expanding container ecosystem.
• OpenStack:As usual, the OpenStack technical committee members will continue their work to expose special interest groups (SIGs) broadly, to ensure all the different profiles and interests in OpenStack are efficiently represented, working and collaborating together.
• StarlingX: Edge computing use cases are emerging among organizations running StarlingX in production. At the Shanghai Summit in November 2019, China UnionPay presented how its contactless payment system leverages StarlingX. In 2020, the community is focusing on project upgrades and functional testing as the contributors work towards the 4.0 release.
• Zuul: Zuul maintainers have begun collaborating with the Gerrit project to add Gerrit Checks API support to Zuul. The goal is to have a Zuul running to help gate the Gerrit project once this feature is added. Looking ahead, the Gerrit Checks API is only one of many features they would like to add to Zuul. From an integration standpoint Gitlab and Bitbucket support is under active development, changes have begun to merge Google Compute Engine support to Nodepool, and Microsoft Azure driver work has begun. Developers still have plans to remove the current single point of failure for the scheduler process and manage job and queue state with the distributed database. This will make it easier to run Zuul reliably without downtime.

In 2020, we are continuing to highlight emerging technologies and ask our community to proactively address the demands of intelligent open infrastructure. For example, workloads like AI and ML require support for new chip architectures, automation at scale down to the bare metal, and integration with many other open source components, all while stretching “cloud” to the edge for 5G and IoT. That’s why “Intelligent Open Infrastructure” will be the theme of our first virtual events of 2020—OpenDev + PTG—where we will focus on the integration of open source components to create an infrastructure that is monitoring itself, replicating itself, and delivering a versatile set of use cases.

A Productive, Engaged Community

With over 100,000 members and millions more visiting OSF websites in 2019 to get involved, the community made huge strides in addressing the needs of what 451 Research predicts will soon be a $7.7B market for OpenStack and a $12B+ combined market for OpenStack & containers.

Some of the world’s largest brands—AT&T, Baidu, Blizzard Entertainment, BMW, China UnionPay, Walmart, and Volvo among others—shared their open source infrastructure use cases and learnings last year. We had the opportunity to engage directly with all of our Gold and Platinum sponsors as well as numerous organizations that have not historically been involved in OpenStack directly. New contributors were on-boarded through multiple internship and mentoring programs as well as through the OpenStack Upstream Institute, which was held in seven countries last year.

We’re looking to make 2020 just as productive.

So even though the future is unknown, we can confidently predict great progress in the OSF community in 2020 as we pour our efforts into growing software projects, the open infrastructure ecosystem, and the open source movement as a whole.

The post What’s Next for Open Infrastructure and the OpenStack Foundation appeared first on Superuser.

The OpenStack Foundation announced in April 2019 that its Ironic software is powering millions of cores of compute all over the world, turning bare metal into automated infrastructure ready for today’s mix of virtualized and containerized workloads.

Over 30 organizations joined for the initial launch of the OpenStack Ironic Bare Metal Program, and Superuser is running a series of case studies to explore how people are using it.

Today, Red Hat is sharing how they integrate OpenStack Ironic into its product offerings and what benefit this provides its customers.

Why did you select OpenStack Ironic for your bare metal provisioning in your product?

As part of Red Hat’s decision to use TripleO, Ironic offers an abstraction layer for bare metal nodes that provides a similar experience to managing virtual instances with OpenStack. This common experience allows a predictable way of working with bare metal nodes. This includes using bare metal in automation workflows such as CI/CD, testing automation of hardware components or any kind application deployments on bare metal. Additionally, Ironic provides a vendor agnostic community where the vendors work together with the community.

These and other use cases that we keep learning from our customers made incorporating and supporting Ironic an easy decision. We have been supporting Ironic with Red Hat OpenStack Platform starting with our OSP 10 release.

What was your solution before implementing OpenStack Ironic?

As Red Hat was looking at determining solutions to facilitate bare metal machine deployment around the time frame of OSP 7, The TripleO project and ultimately Ironic projects were chosen over Foreman for OSP 7 for the first time. It made sense to use an OpenStack project (Ironic) to deploy OpenStack based on feedback from customers using Ironic to deploy OpenStack. That decision that helped make Ironic better over the years by introducing new enterprise capabilities such as lifecycle management as part of “day 2 operations” for bare metal nodes, remote management via API and scaling out of bare-metal resources.

What benefits does OpenStack Ironic provide your users?

Ironic provides a more efficient way to consume bare metal-managed nodes for our customers who were asking for a more simplified and cost effective way to deploy and  manage large numbers of bare metal nodes with OpenStack. Ironic allows them to accomplish it for a variety of use cases including:

• API driven Installation of physical machines to support cloud infrastructure or tenant workloads.
• A repeatable and reliable way to test the performance of every new revision of a hardware component for servers and Ironic is well-suited to include physical servers in a CI environment.
• Performing 3D rendering in a large number of nodes and with the ability to automate the tests.
• GPU PCI passthrough with Red Hat OpenStack Platform director – Ironic and its family of tools enables retrieval of hardware information prior to installation which allows OpenStack installers to have advanced features such as GPU pass-through in their environments – supporting AI/ML workloads such as TensorFlow
• Multi-tenant access to bare metal with network isolation allowing multiple teams to work with the same pool of bare metal nodes in a safe way, thanks to integrating support to manage switches via networking-ansible and neutron

Ultimately we are bringing lessons learned using APIs to manage virtual machines to bare metal enabling our customers to leverage automation instead of issuing help tickets to request physical machine resources. Ironic is the tool kit that is leveraged facilitating the installation of Red Hat OpenStack Platform and OpenShift automated Installer Provisioned Infrastructure (IPI) upon bare metal using the Metal3 project.

What feedback do you have to provide to the upstream OpenStack Ironic team?

Our feedback would be to focus on stability and integration with hardware vendors, a good example is the Ironic integration with the Redfish standard over the years. Redfish is the modern, vendor-agnostic bare metal machine management protocol developed by DMTF (Distributed Management Task Force) and already supported by several major vendors (as well as by Ironic since OpenStack Pike release).  It is important and an opportunity to standardize across vendors, as IPMI has done so far, but with advanced features. DHCP-less types of deployment will also help operators and Red Hat is working on this via virtual-media provisioning. Integration via Metal3 is also strategic for both Kubernetes and Ironic, so maintaining focus on expanding Ironic with Kubernetes is important to ensure both projects will be more successful and ready for consumption by a large number of users.

The post OpenStack Ironic Bare Metal Program case study: Red Hat appeared first on Superuser.

The post Who Is The OpenStack Community? appeared first on VEXXHOST.

This post is part of the Women of Open Infrastructure series to spotlighting the women in various roles in the community who have helped make the Open Infrastructure successful. With each post, we learn more about each woman’s involvement in the community and how they see the future of Open Infrastructure taking shape. If you’re interested in you are interested in being featured or would like to nominate someone to tell their stories, please email editor@openstack.org.

This time we’re talking to Amy Wheelus, VP – Broadband and Video Systems at AT&T. She tells Superuser about how she became an active member in the community, and why it’s important for women to get involved with open source.

What’s your role (roles) in the Open Infrastructure community?

In my previous role within AT&T, I led our Network Cloud team which is responsible for AT&T’s internal private network cloud. This team is very active in the Open Infrastructure community, and I had the privilege to support my team in their efforts in Open Infrastructure. I served in the capacity of evangelist for the use of open source software within AT&T and within the telecommunications industry. One specific area that I was involved with in the last year was the creation of the CNTT Common NFVi Telco Task Team whose mission was to create a small number of common reference architectures and implementations. It was a really exciting endeavor and the first reference architecture was based on OpenStack.

What obstacles do you think women face when getting involved in the Open Infrastructure community?   

Just like most of the technology industry, the Open Infrastructure community is male dominated, but in the few years that I have been an active participant, I’ve seen an increase in the number of women presenting talks and taking leadership roles in the community. I think that we have to continue to spotlight women who are changing the game and highlight contributions from women across the field from developers to code reviewers to leaders in their companies.

Why do you think it’s important for women to get involved with open source?

Open Source is about working together to solve common problems and the best way to do that is with diverse thought.  Women think differently than men – not better and not worse – just differently and it is this difference of viewpoint that is important to creating solutions as a team. This is what Open Source is all about – bringing a diverse group of people together to work for the good of everyone.  We need the diversity of thought that women bring to the table.

Efforts have been made to get women involved in open source, what are some initiatives that have worked and why?

I think the best initiatives are when others are personally invested in getting women involved.  We need to each personally commit to encouraging and supporting a woman to become more involved in open source.  If each person (male and female) were to encourage one woman to get more involved – think of the impact that could have on the open source community.

Open source moves very quickly. How do you stay on top of things and what resources have been important for you during this process?

You aren’t joking when you say that open source moves very fast – it is difficult to stay on top of everything going on which is why it is important to focus your energy on a few areas where you can make a difference.  The OpenStack website is a great resource on infrastructure. Linux Foundation’s Open Source Networking site is another resource that I use to stay on top of the trends in the telecommunications and networking areas.

What advice would you give to a woman considering a career in open source? What do you wish you had known?

Open source gives the opportunity to work with hundreds of people around the world to solve common problems. It gives people the opportunity to explore many different areas. If I had understood how working upstream in open source could eliminate costs for my company many years ago, I would have been a believer sooner. I think women can flourish in open source careers whether it is in the technical expert areas or in the management areas. There are no limits to what can be achieved if we bring the best minds of the world together to solve common problems.

 

The post Women of Open Infrastructure: Meet Amy Wheelus at AT&T appeared first on Superuser.

A time for new beginnings beckons upon us, and Codership is pleased to announce the much anticipated Release Candidate of MySQL 8.0 that comes with Galera 4. It comes with MySQL 8.0.19 and includes the Galera Replication Library 4.5 Release Candidate and wsrep API version 26. 

 

Galera 4 and MySQL 8.0.19 have many new features, but here are some of the highlights:

• Streaming replication to support large transactions by splitting transaction replication then applying them in smaller fragments.
• Improved foreign key support, as write set certification rules are optimised and there will be a reduction in the number of foreign key related false conflicts in certifications.
• Group commit is supported and integrated with the native MySQL 8 binary log group commit code. Within the codebase, the commit time concurrency controls were reworked such that the commit monitor is released as soon as the commit has been queued for a group commit. This allows transactions to be committed in groups, while still respecting the sequential commit order.
• There are new system tables for Galera Cluster that are added to the mysql database: wsrep_cluster, wsrep_cluster_members and wsrep_streaming_log. You can now view cluster membership via system tables.
• New synchronization functions have been introduced to help applications implement read-your-writes and monotonic-reads consistency guarantees. These functions are: WSREP_LAST_SEEN_GTID(), WSREP_LAST_WRITTEN_GTID() and WSREP_SYNC_WAIT_UPTO_GTID().
• Poor network conditions can lead to errors in a Galera Cluster, and handling of this is now improved, such that a node will attempt to leave the cluster gracefully if there is ever a possibility of data inconsistency.
• A more robust wsrep codebase, with better state handling and error handling. 

We are pleased to offer packages for CentOS 7, CentOS 8, and Ubuntu 18.04. Installation instructions are similar to previous releases of Galera Cluster.

Please evaluate Galera 4 at our downloads page (http://galeracluster.com/downloads/)

 

Known issues with this release candidate are:

• This is still a release candidate not meant for production use.
• Upgrading from an earlier version of Galera Cluster is not supported yet.

Please try this release candidate, and provide feedback via our Google Group or via email to: info@galeracluster.com. 

 

 

Today I wandered into a bit of a rat hole discovering how to export data from OpenStack Cinder volumes when you don’t have admin permissions, and I thought it was worth documenting here so I remember it for next time.

Let’s assume that you have a Cinder volume named “child1”, which is a 64gb volume originally cloned from “parent1”. parent1 is a 7.9gb VMDK, but the only way I can find to extract child1 is to convert it to a glance image and then download the entire volume as a raw. Something like this:

$ cinder upload-to-image $child1 "extract:$child1"

Where $child1 is the UUID of the Cinder volume. You then need to find the UUID of the image in Glance, which the Cinder upload-to-image command will have told you, but you can also find by searching Glance for your image named “extract:$child1”:

$ glance image-list | grep "extract:$cinder_uuid"

You now need to watch that Glance image until the status of the image is “active”. It will go through a series of steps with names like “queued”, and “uploading” first.

Now you can download the image from Glance:

$ glance image-download --file images/$child1.raw --progress $glance_uuid

And then delete the intermediate glance image:

$ glance image-delete $glance_uuid

I have a bad sample script which does this in my junk code repository if that is helpful.

What you have at the end of this is a 64gb raw disk file in my example. You can convert that file to qcow2 like this:

$ qemu-img convert $child1.raw $child1.qcow2

But you’re left with a 64gb qcow2 file for your troubles. I experimented with virt-sparsify to reduce the size of this image, but it doesn’t work in my case (no space is saved), I suspect because the disk image has multiple partitions because it originally came from a VMWare environment.

Luckily qemu-img can also re-create the COW layer that existing on the admin-only side of the public cloud barrier. You do this by rebasing the converted qcow2 file onto the original VMDK file like this:

$ qemu-img create -f qcow2 -b $parent1.qcow2 $child1.delta.qcow2
$ qemu-img rebase -b $parent1.vmdk $child1.delta.qcow2

In my case I ended up with a 289mb $child1.delta.qcow2 file, which isn’t too shabby. It took about five minutes to produce that delta on my Google Cloud instance from a 7.9gb backing file and a 64gb upper layer.

Swarm support continues, but if you're embracing Kubernetes, we've developed a suite of services, and tooling to make things as painless as possible.

The post Why Open-Source Tools For Cloud Management Matter appeared first on VEXXHOST.

The post A Dive Into Fully Managed Services appeared first on VEXXHOST.

FIRST ACQUAINTANCE WITH CLOUD

In the 1990s, when I was a child, Bill Gates, who was the co-founder and the CEO of Microsoft, published a book called The Road Ahead. The book summarized the implications of the personal computing revolution and described a future profoundly changed by the arrival of a global information superhighway. Gates mentioned that things have been changed over the past two decades. However, besides the information superhighway he predicted, it extended to everywhere in our society, such as e-commerce, social networking applications, network conference and cloud computing massively impacted our life every day, which was far beyond his estimation.

Computer science, as a novel technology and area to human beings since the last century, is actually an unexplored ocean and has been attracting more and more navigators to explore. People can’t imagine which is ahead in the way of the boat and can’t forecast which land they are about to discover, due to the fast evolution of information technology. I was one of them, when I was admitted to the university, I resolutely chose computer science as my major. And now I discovered my new land – cloud computing.

After I became a postgraduate student, I totally got immersed in the ocean and attempted to find a facility for deployment, orchestration, operation and management of those virtual and physical machines. OpenStack became the beacon light for me, and I got started with the project at that time. It is such a magic box that is powerful enough to cover almost every need, but also a complex system since it is combining so many components together, each with different functionalities. OpenStack is my first impression on how the cloud actually works behind virtualization and how the cloud service providers (CSP) offer their services. These tricks and features make me get far more interested while digging into the land of clouds.

Hey, things look much more exciting when I start to know there’s something called open source community, where tens of thousands of people are working together to build one super project, and they all come from different countries, companies and with different gender, age and races. The OpenStack community is definitely a typical example and also one of the powerful leaders for that.

According to an empirical study on OpenStack conducted by Prof. Minghui Zhou and her team in Beijing University in 2018, companies are taking the lead in open source software development by making far more contributions than volunteers. Consequently, company engagement inspires individual volunteers to participate in the community, including myself. I then realized that security and privacy are the top concern of companies using cloud since it shares resources on the networks. After determining cloud security as the research area in school, I made use of OpenStack to perform penetration tests on clouds where security threats were faced.

COMMUNITY DIVERSITY

It’s a fait accompli that the field of computer science is heavily skewed toward men, and the gender situation in the open source arena is even more lopsided. The OpenStack community has been making huge efforts to improve diversity and inclusion spanning from leadership, governance, event representation, to code-and noncode-related contributions.

The percentages of code- and noncode-related artifacts contributed by women (blue), men (red), and individuals whose gender could not be identified (green). The percentage of women is 10–12%, depending on the data source and the analysis. Participation at the governance and leadership level increased remarkably, and participation in all of the code- and noncode-related contributions also increased.

I dived into cloud computing and OpenStack after finishing my study, and became a company contributor in January 2018 at Intel, which is a Platinum Member of the OpenStack Foundation and one of the top five companies contributing then. Like the community, Intel has always committed to developing a culture of equality, diversity, and inclusion. In Intel, my team is a big family and the female members hold up half the sky. In this family, our primary responsibility is to take advantage of technologies to change the world and make it better, from the lower-level perspective. We have been enabling server capabilities to enrich the functionality of cloud computing according to new use scenarios, e.g. Enhanced Platform Awareness (EPA).

The OpenStack community doesn’t exclude anyone, even elementary school students, and doesn’t hesitate to offer a helping hand to any people needed. I learned from others and started to be familiar with many other projects and people inside the community. In May 2019, I was invited to present my analysis on edge computing projects as a speaker at the Open Infrastructure Summit in Denver. Warm encouragement and greetings from the audience encouraged me a lot and made me believe I am part of it.

MENTEE AND MENTOR

The next generation is the future of our open source community. Intel continuously supports joint programs with universities and research institutes. In 2015 Intel sponsored the eighth Intel-Cup National Collegiate Software Innovation Contest based on OpenStack and performed a study on OpenStack’s ease of use. Only one out of the 20 teams succeeded to deploy OpenStack independently within 36 hours. The final survey showed that for those undergraduate students, it was difficult for them to master numerous OpenStack operations, and the deployment process was complicated with most issues in the networking part. Nowadays we believe its ease of use has been improved dramatically, but we still admit ease of use is the biggest barrier for newcomers to enter this area and participate in the community. Therefore, mentorship always matters.

In the summer of 2019, my team and I got a chance to mentor some brilliant undergraduates from the Joint Institute of University of Michigan and Shanghai Jiaotong University (UM-SJTU) with the art of cloud computing and introduce them to the OpenStack community. The students were appealed by the charm of cloud computing and edge and took a lot of effort while studying the projects inside the OpenStack community. Although some of the projects looked a bit complex and difficult, they still tried their best to construct a cloud gaming infrastructure with StarlingX, which is an edge computing project with low latency and high bandwidth that incorporates OpenStack components and is one of the open infrastructure projects supported by the OSF. In the end, those four students managed to win the Gold Prize in the demo design summit of the university and received a chance to present a session to illustrate their project at Open Infrastructure Summit Shanghai in November 2019.

In addition to the new blood, the open source community is showing more and more vitality. Joy Liu, an 18-year-old girl who is even studying in her high school with much knowledge on computer science as well as cloud computing, showed her enthusiasm on facial recognition on top of edge infrastructure, which motivated me to become her mentor in this area. Based on the Integrated Cloud Native (ICN),  blueprint in Akraino, they constructed a reference architecture and successfully presented a session about the architecture at Open Infrastructure Summit Shanghai.

The deeper a person integrates into the community, the more impressive the person feels. Things look quite different after my transition from a mentee to a junior mentor. There seems to be more areas to explore and also more places that I could devote myself to. The OpenStack community is embracing everyone who has the capability and willingness to join, and we could see more chances available for the new generation to explore and participate in the future.

STEP FURTHER

Inside the open source community, we witnessed so many intelligent and skillful people (both men and women) delivering their power and expertise to drive the growth of the community, as well as the development of the technology. Also, more and more people growing with the open source community, from learning to mentorship offering, just like I did. To these participants, open source culture is never just reusing free code on GitHub to enhance and promote their products. The culture is an ethos that values sharing. It embraces an approach to technology innovation, invention and development that emphasizes internal and external collaboration across different genders, ages, races, countries and companies.

People are now in the best era. As technology is evolving rapidly, everything is changing every day with innovations. It might be impossible to reproduce the miracle that The Road Ahead did, as it is quite difficult for someone to predict what the world will happen in the next two decades, either 5G, edge computing, artificial intelligence, or Internet of Things (IoT). However, us contributors will hold our hands and embrace the bright future together with the community.

The post Women of Open Infrastructure – Growing with the Open Source Community appeared first on Superuser.

The post Why Your Enterprise Needs OpenStack’s Cloud Infrastructure appeared first on VEXXHOST.

The post How OpenStack Can Cut Costs Without Impacting Quality appeared first on VEXXHOST.

The post Why You Need An OpenStack Powered Private Cloud To Save The Day appeared first on VEXXHOST.

The post Why Containers Plus OpenStack Is The Best Way To Manage Applications appeared first on VEXXHOST.

The post The Impact Of Cloud Computing In Fintech appeared first on VEXXHOST.

The post A Brief Comparison of Containers and Virtual Machines appeared first on VEXXHOST.

The post Object Storage With OpenStack Swift appeared first on VEXXHOST.

Spotlight on: 10 Years Of OpenStack

Many amazing tech milestones happened in 2010. Steve Jobs launched the first iPad. Sprint announced its first 4G phone. Facebook reached 500 million users. OpenStack was born. 

In real time, the pace of change in the tech industry often feels glacial, but looking at things over a ten-year span, a lot of stark differences have emerged since 2010. So before you plug back in your AirPods, fire up Fornite and watch a new show on Disney+, let’s take a look at how OpenStack has transformed the open source industry in the past 10 years. 

The Decade Challenge – OpenStack Edition

What began as an endeavor to bring greater choice in cloud solutions to users, combining Nova for compute from NASA with Swift for object storage from Rackspace, has since grown into a strong foundation for open infrastructure. None of it would be possible without the consistent growth of the OpenStack community. In the 10 years since the community was established, OpenStack is supported by one of the largest, global open source communities of over 105,000 members in 187 countries from over 700 organizations, backed by over 100 member companies! Developers from around the world work together daily on a six-month release cycle with developmental milestones.

Looking back to OpenStack in 2010, we were ecstatic to celebrate our first year of growth from a couple dozen developers to nearly 250 unique contributors in the Cactus release (the third OpenStack release). Fast Forward to the year of 2019, we have a total of 1,518 unique change authors who approved more than 47,500 changes and published two major releases (Stein and Train). Between that, the community successfully delivered 16 software releases on time. Today, we are not only celebrating our community’s achievement for the past 10 years, but also looking forward to the continuous prosperity of the community in the next 10 years.

Your Top 10 Favorite Moments With OpenStack Are…

As you can see, there are so many milestones to celebrate in the past 10 years of OpenStack with the community. We want to hear from you about what your top 10 favorite things related to OpenStack are. Go into this survey and choose a question to answer. The topics range from your top 10 most memorable moments of OpenStack, your top 10 most used features in OpenStack to your top 10 favorite cities you visited for OpenStack. We are looking forward to hearing your favorites, and we invite you all to join us and celebrate 10 awesome years of OpenStack.

OpenStack Foundation news

• Based on the input from the community, board, and the latest information available from the health experts, we’ve made the decision not to hold the OpenDev + PTG in Vancouver this June. Instead, we’re exploring ways to turn it into a virtual event and would love the help of everyone in the community. Learn more in this mailing list post by Mark Collier.
• There will be two community meetings next week to discuss the OpenStack 10th anniversary planning, current community projects, and an update on OSF events. Learn more in this mailing list.
  • Thursday, April 2 at 10am CT / 1500 UTC
  • Friday, April 3 in Mandarin at 10am China Standard Time

Airship: Elevate your infrastructure

• The Airship community will be holding a virtual meet-up on March 31 from 1400-2200 UTC that will serve much the same purpose as the originally planned KubeCon face-to-face team meeting. Goals of the meetup include aligning on Airship use cases and high-level design, finalizing actionable low-level design for the upcoming release, and reviewing work in progress.
• Catch up on the latest news in the March update, live on the Airship blog now.
• Connect with the Airship community on Slack! We’re mirroring to #airshipit on IRC so you can use your preferred platform. Join at airshipit.org/slack.

Kata Containers: The speed of containers, the security of VMs

• We have just released the latest stable 1.9.6, 1.10.2 releases and cut 1.11.0-alpha1 release. The 1.9.6 and 1.10.2 stable releases included latest bug fixes. And the 1.11.0-alpha1 release prepared more stuff for the incoming 1.11.0 release, notably. See the message here. We look forward to stabilizing it in the next few weeks. Thank you to the users and contributors!

OpenStack: Open source software for creating private and public clouds

• If you’re running OpenStack, please share your feedback and deployment information in the 2020 OpenStack User Survey. It only takes 20 minutes and anonymous feedback is shared directly with developers!
  • Why is it important for you to take the user survey? Find out here!
• We are entering the final stages of the Ussuri development cycle, with feature freeze happening on April 6, in preparation for the final release on May 13. The schedule for the next cycle (Victoria) was published, with a final release planned for October 14. The ‘W’ release (planned for Q2, 2021) will be called ‘Wallaby’.
• In the coming weeks the OpenStack community will renew its leadership, with 5 TC seats up for election, as well as all PTL positions. Nominations are open until March 31!
• A framework for proposing crazy ideas for OpenStack has been created, with the first idea being posted there: project Teapot.

StarlingX: A fully featured cloud for the distributed edge

• The StarlingX community recently held their Community Meetup in Chandler, AZ. Check out the updates on the current development activities and plans for future releases on the StarlingX blog.
• If you’re currently testing StarlingX, running PoC implementations or running the software in production take a few minutes and fill out a short survey to provide feedback to the community. All information is confidential to the OpenStack Foundation unless you designate that it can be public.

Zuul: Stop merging broken code

• Are you a Zuul user? Please take a few moments to fill out the Zuul User Survey to provide feedback and information around your deployment. All information is confidential to the OpenStack Foundation unless you designate that it can be public.
• Zuul versions 3.17.0 and 3.18.0 have been released. Both releases address security issues and you should refer to the release notes for more details. Additionally, socat and kubectl must now be installed on the executors.
• Nodepool 3.12.0 has been released. This adds support for Google Cloud instances. Refer to the release notes for more information.

Upcoming Open Infrastructure and Community Events

• April 28-29, Virtual Red Hat Summit
• June 2-3, Virtual Cisco Live

For more information about these events, please contact denise@openstack.org

Questions / feedback / contribute

This newsletter is written and edited by the OSF staff to highlight open infrastructure communities. We want to hear from you! If you have feedback, news or stories that you want to share, reach us through community@openstack.org . To receive the newsletter, sign up here.

The post Inside open infrastructure: The latest from the OpenStack Foundation appeared first on Superuser.

Superuser is an online publication for the community, by the community. We’re publishing our editorial process to actively solicit submissions from the open infrastructure community, and we want to hear from you!

When Superuser launched in 2014, the goal was to serve as a conduit for our community of developers and users to share their experiences building and operating open infrastructure around the world. Summits, PTGs, Open Infrastructure Days, and other community gatherings are great ways to connect offline, and Superuser is an online way to keep those connections going. Content has historically been developed by a team of writers working with the foundation, as well as a handful of community members, and we want to invite the entire community to share their lessons learned, use cases, tutorials, and overall open infrastructure thoughts here as well.

We want to hear your ideas for articles you’d like to contribute about open source infrastructure and open source projects. Share your ideas with the Superuser editorial team. You might want to read over the Superuser Editorial Guidelines first, before reaching out.

So, what topics are fair game? Most anything relating to building and operating open infrastructure is a candidate:

• AI/machine learning
• Bare metal
• Container infrastructure
• CI/CD
• Edge computing
• Telecom + NFV
• Public cloud
• Private & hybrid cloud
• Security
• General open infrastructure thoughts

We’ll be particularly interested in content that’s relevant to projects in the open infrastructure community, like Airship, Ansible, Ceph, Docker, Kata Containers, Kubernetes, ONAP, OpenStack, Open vSwitch, OPNFV, StarlingX, Zuul, and others.

User case studies are always a big hit, but so are how-to tutorials, best practices, lessons learned, event recaps, project roadmap updates, and new release information. We’ll even consider product version updates and thought leadership content, provided it’s vendor neutral and focused on the community rather than competitors. Superuser is not a trade publication: we’re here to amplify the values of openness, collaboration, and solving shared problems.

So, what are some examples of content we’ll decline? Anything that reads like an advertisement or sales solicitation won’t make the cut. Opinion submissions must be supported by verifiable facts and voiced in a collaborative tone that invites community participation in finding solutions everyone can use equally.

Examples of submissions that fit the editorial mission of Superuser include:

• The latest Kata Containers release features
• A personal take on the latest Open Infrastructure Summit
• How Verizon Media is using OpenStack at scale
• How to run a packaged function with OpenStack Qinling
• Running StarlingX at the edge for telcos
• How to run project gating with Zuul

What ideas do you have? Share them with us using this short form to engage with our editorial team.

The post From Tutorials to Case Studies, Share your Open Infrastructure Wisdom with Superuser appeared first on Superuser.

The post Block Storage With OpenStack Cinder appeared first on VEXXHOST.

Introduction

Applications and the network have become distributed. Applications are fragmented to micro-services so the network is being composed of different clouds from different regions. But with this, the need to have control of all resource aspects is increased due to increasing security concerns. SD-WAN is available for enterprise. But what if data centers or endpoints are less and spread across multiple regions? This article focuses on the interconnection of OpenStack clouds using Neutron APIs.

The Neutron to Neutron Communication

There may be a situation where you need to interconnect two or more separate data centers or NFV PoPs powered with OpenStack. Those data centers are considered to be located in different regions as well. These data centers either want to have an interconnection on-demand initially. Further, the interconnection may require private addressing and isolation to share data end-to-end with a dedicated communication channel. A combination of on-demand and private addressing and isolation possible with Neutron VPN as a service (VPNaaS). We have different VPN options available after performing selecting a suitable solution after VPN reviews. But this solution involved IPSec which has a performance overhead. Additionally, for a proper interconnection, you want a solution that avoids the overhead of packet isolation.

One of the architecture for interconnection of OpenStack cloud can be – adding an orchestrator in between clouds and resources in participant clouds are interconnected. But it has several demerits. Like

The orchestrator may need admin rights to establish networking in resources of data centers. But it is difficult when there are different organizations are involved. Also, adding orchestrator will expose the APIs to different attacks and because of this, it is treated as a complex system.

The recommended option remain is to extend the Neutron APIs to interconnect resources like virtual routers of OpenStack powered data centers. It involves two facets User Facing API and Neutron to Neutron API.

In User facing APIs, there will be a symmetrical call that will be made by centrally located admin to neutron modules in data centers. A link will be established with approval from both of the data centers.

In Neutron to Neutron, the API will allow each Neutron component to check if the symmetrical interconnection has been defined on the other side. In this way, Neutron components in the different regions coordinate together to set up these private isolated interconnections without orchestration nor network device configuration.

The solution was discussed at the OpenStack summit Berlin back in 2018. This solution is applicable to use cases where:

• OpenStack is involved in the data center
• If there are multiple regions involved with one OpenStack cloud
• Between multiple OpenStack clouds where trust entities are co-ordinated
• And, where different OpenStack cloud instances use the different SDN solutions

You can download the presentation from here and watch a demo



The post Establishing Trusted Network Interconnection of OpenStack Clouds appeared first on Superuser.

Part of the process when updating Red Hat’s TripleO based OpenStack is to apply the package and container updates, viaupdate run step, to the nodes in each Role (like Controller, CephStorage and Compute, etc). This is done in-place, before the ceph-upgrade (ceph-ansible) step, converge step and reboots.

openstack overcloud update run --nodes CephStorage

Rather than do an entire Role straight up however, I always update one node of that type first. This lets me make sure there were no problems (and fix them if there were), before moving onto the whole Role.

I noticed recently when performing the update step on CephStorage role nodes that OSDs and OSD nodes were going down in the cluster. This was then causing my Ceph cluster to go into backfilling and recovering (norebalance was set).

We want all of these nodes to be done one at a time, as taking more than one node out at a time can potentially make the Ceph cluster stop serving data (all VMs will freeze) until it finishes and gets the minimum number of copies in the cluster. If all three copies of data go offline at the same time, it’s not going to be able to recover.

My concern was that the update step does not check the status of the cluster, it just goes ahead and updates each node one by one (the seperate ceph update run step does check the state). If the Ceph nodes are updated faster than the cluster can fix itself, we might end up with multiple nodes going offline and hitting the issues mentioned above.

So to work around this I just ran this simple bash loop. It gets a list of all the Ceph Storage nodes and before updating each one in turn, checks that the status of the cluster is HEALTH_OK before proceeding. This would not possible if we update by Role instead.

source ~/stackrc
for node in $(openstack server list -f value -c Name |grep ceph-storage |sort -V); do
  while [[ ! "$(ssh -q controller-0 'sudo ceph -s |grep health:')" =~ "HEALTH_OK" ]] ; do
    echo 'cluster not healthy, sleeping before updating ${node}'
    sleep 5
  done
  echo 'cluster healthy, updating ${node}'
  openstack overcloud update run --nodes ${node} || { echo 'failed to update ${node}, exiting'; exit 1 ;}
  echo 'updated ${node} successfully'
done

I’m not sure if the cluster doing down like that this is expected behaviour, but I opened a bugzilla for it.

The post Looking At OpenStack Glance appeared first on VEXXHOST.

The post Let’s Get Networking: OpenStack Neutron appeared first on VEXXHOST.

In the current climate, where we are either unable to travel to collaborate or because we just want to reduce our impact on the environment, the ability to effectively collaborate remotely is critical.

While a lot of RDO contributors are remote, there are many more who are not and now find themselves in lock down or working from home due to the coronavirus. A few members of the RDO community requested tips, tricks, and best practices for working on and managing a distributed team.

Connectivity

I mean, obviously, there needs to be enough bandwidth, which might normally be just fine, but if you have a partner and kids also using the internet, video calls might become impossible.

Communicate with the family to work out a schedule or join the call without video so you can still participate.

Manage Expectations

Even if you’re used to being remote AND don’t have a partner / family invading your space, there is added stress in the new reality.

Be sure to manage expectations with your boss about priorities, focus, goals, project tracking, and mental health.

This will be an ongoing conversation that evolves as projects and situations evolve.

Know Thyself

Some people NEED to get ready in the morning, dress in business clothes, and work in a specific space. Some people can wake up, grab their laptop and work from the bed.

Some people NEED to get up once an hour to walk around the block. Some people are content to take a break once every other hour or more.

Some people NEED to physically be in the office around other people. Some will be totally content to work from home.

Sure, some things aren’t optional, but work with what you can.

Figure out what works for you.

Embrace #PhysicalDistance Not #SocialDistance

Remember to stay connected socially with your colleagues. Schedule a meeting without an agenda where you chat about whatever.

Come find the RDO Technical Community Liaison, leanderthal, and your other favorite collaborators on Freenode IRC on channels #rdo and #tripleo.

For that matter, don’t forget to reach out to your friends and family.

Even introverts need to maintain a certain level of connection.

Further Reading

There’s a ton of information about working remotely / distributed productivity and this is, by no means, an exhaustive list, but to get you started:

• Ergonomic Essentials for Remote Working
• Cornell University Ergonomics
• Wikipedia.Org Time Management
• You’re Taking Breaks The Wrong Way
• WHO | Health Workforce Burnout
• Wikipedia.Org Stress Management
• Lessons from Community Leaders on Working Remote
• Top 15 Tips To Effectively Manage Remote Employees

Now let’s hear from you!

What tips, tricks, and resources do you recommend to work from home, especially in this time of stress? Please add your advice in the comments below.

And, as always, thank you for being a part of the RDO community!