Event organizers and participants experience a variety of emotions during the lifecycle of an event: excitement, anticipation, stress, and sadness when it’s over. OpenDev: Large Scale Usage of Open Infrastructure was no exception. To be honest, baby Yoda put it best.

This week, the OpenStack Foundation (OSF) held its third OpenDev conference. This iteration focused on scaling challenges for open infrastructure across a variety of topics including upgrades, high availability (HA) networking, bare metal, and more. Jonathan Bryce, OSF executive director, kicked off the event explaining how OpenDev events are an example of how the global Open Infrastructure community collaborates without boundaries. He encouraged participants to think broadly and remember that collaboration is built by people who are actively engaged and participating by sharing their knowledge and experiences so they can learn from each other.

This virtual event recruited participants from over 70 countries who spent three days asking questions, sharing scaling challenges, and explaining implementations that worked for their local environments. Each moderated session combined various perspectives on the challenges, questions for how to improve, and next steps that the community can collectively collaborate on to ease these operator challenges.

Thanks for all those involved in organising #OpenDev2020 from the chairs, track organisers and the OSF staff. Having a few hours each day remotely worked well but I missed the F2F too. pic.twitter.com/XQ8UlAmqMl

— Tim Bell (@noggin143) July 1, 2020

Thank you to the OpenDev: Large-scale Usage of Open Infrastructure Software programming committee members: Beth Cohen, Roman Gorshunov, Belmiro Moreira, Masahito Muroi, and Allison Price. You helped to make these discussions possible!

So, what happened? Below is a snapshot of the conversations that took place, but I want to encourage you to check out the event recordings as well as the discussion etherpads found in the OpenDev event’s schedule to join the discussion.

Jump to the User Stories recap
Jump to the Upgrades recap
Jump to the Tools recap
Jump to the HA Networking Solutions recap
Jump to the Software Stack recap
Jump to the Bare Metal recap
Jump to the Edge Computing recap
Jump to the OpenDev event’s next steps

User Stories

Ahead of the weeks’ discussions, speakers from Blizzard Entertainment. OpenInfra Labs, and Verizon shared their own scaling challenges via short user story presentations Monday morning followed by audience questions moderated by Mark Collier, OSF COO.

Colin Cashin, Blizzard Entertainment senior director of cloud engineering, and Erik Andersson, Blizzard Entertainment technical lead, senior cloud engineer, discussed four key scaling challenges that affect their 12,000 node OpenStack deployment that spans multiple regions. Their challenges were: Nova scheduling w/ NUMA pinning, scaling RabbitMQ (a frequent challenge repeated throughout the week), scaling Neutron, and compute fleet maintenance. The Blizzard team received a flurry of questions about their specific challenges and their multi-cloud approach (OpenStack, Amazon, Google, and Alibaba). They also used the opportunity to share that they’re hiring engineers to help manage their massive OpenStack footprint, so if you’re interested, check out their openings.

Michael Daitzman provided an overview of OpenInfra Labs, the newest OSF pilot project, that is a collaboration among several research institutions including Boston University, Harvard University, MIT, Northeastern University, and University of Massachusetts. He covered some challenges for integrating different open source technologies into a single environment including specific problem areas like monitoring and what happens when your Ceph clusters aren’t properly backed up (TL;DR: you lose all your data).

Beth Cohen, OpenDev veteran and moderator of the HA networking solutions discussion, presented an updated Verizon case study centered around some of their challenges. Her team is seeing that application configuration (written by partners) has a significant effect on how the applications behave in the environment (i.e. w/ encryption turned on, throughput halved). With traffic going through all of these systems, it can be hard to identify the source of the problem. In order to isolate and reproduce this, they have built a full production engineering lab with full testing capabilities that is also used by their development team, ultimately providing a really nice feedback loop.

Upgrades

When asking OpenStack operators their number one challenge with their deployments, upgrades are often at the top of the list. This discussion, moderated by Belmiro Moreira, cloud architect at CERN, explored the different setbacks around upgrades, including why operators find them so daunting. Top reasons shared included upgrading across versions, the amount of resources needed, the feeling of “once you’re behind, you’re behind,” and API downtime. Some suggestions included the recent pre-upgrade checks that the OpenStack TC set as a goal in the Stein cycle in 2019 as well as fast forward upgrades.

As can be expected, this session included a lot of discussion about specific upgrade scenarios. One of the next steps that Jonathan mentioned in the event wrap-up was the opportunity to use the OpenDev event as a launching off point for some upgrade documentation. If you’re an operator who has successfully upgraded your OpenStack environment and would like to collaborate on a set of tips, please sign up here.

Tools

Moderated by John Garbutt, principal engineer at StackHPC, the Tools discussion covered a few topics: Different ways to measure scale, the different considerations into what you’re trying to scale and how that will affect tools, and finding and removing bottlenecks, which is naturally where a lot of the conversation centered. Shared challenges included RabbitMQ flatlining, legacy Keystone UUID tokens, and losing access to Cinder volumes.

The next step for this topic was largely centered around sharing tooling, which included the idea of revisiting the OsOps initiative that was started a few years ago so that operators could share tooling with each other and collaborate more closely.

HA Networking Solutions

What does HA mean from a network perspective? Are you concerned with networking connectivity failures in your environment and if so what are you doing about them? Do you have a diverse network? Beth Cohen, cloud product technologist at Verizon, started the discussion with these questions to make sure that everyone knows what networking high availability means in this context and get to know how important HA is in the participants’ deployments.

Later, the participants dived into discussions around different factors that apply to scaling, where you put failure domains and what the most cost-effective way is to do that. Should we pay for a lot of redundant and expensive hardware or handle failure at the rack level, and trust the software to be able to work around that? The interactive discussion continues. If you are interested in adding your thoughts to the etherpad, please add it here.

Software Stack

The Software Stack discussion, moderated by Masahito Muroi, senior software engineer at LINE Corp., centered around what the open source mix will be over time and how to plan for deployment infrastructure software and the resources that the end users will want. A poll during this session helped show that networking and deployment were the two biggest challenges that participants faced.

Bare Metal

James Penick, architect director at Verizon Media, moderated an active discussion around bare metal, including multiple opportunities where he activated his own team to implement learnings back in their own environment. The conversation included use cases for bare metal and where participants see those use cases evolving to, including scenarios like 5G, the tooling required around bare metal management, and lifecycle management. With only an hour available for discussion, participants were only able to scratch the surface on the bare metal conversation, but luckily, the next OpenDev event (Hardware Automation, July 20-22) will be centered around this topic, including an entire day on lifecycle management.

Edge Computing

The last session of the event was around the edge computing use case and was moderated by Shuquan Huang, technical director at 99cloud. The discussion kicked off with use cases that included farming, high performance computing (HPC), 5G, facial recognition, and an impressive China Tower edge computing use case that was planning to leverage StarlingX across 2 million antenna towers in China. The different architectural requirements for the varying edge use cases was a popular question and unsurprising as participants had earlier identified networking as their number one pain point in the Software Stack discussion. This was a good opportunity to promote the OSF Edge Computing Group’s latest whitepaper, Edge Computing: Next Steps in Architecture, Design, and Testing.

Next Steps

The goal with the OpenDev events is to extend this week’s learnings into future work and collaboration, so Jonathan Bryce and Thierry Carrez, OSF VP of Engineering, wrapped up the event to discuss next steps. These include:

• Join the OpenStack Large Scale SIG to continue sharing challenges and solutions around scaling
• Take the OpenStack User Survey to share feedback with the upstream community
• Collaborate on documentation around common pain points, like upgrades
• Revive OsOps Tools
• Join the OpenDev: Hardware Automation event to continue discussing bare metal use cases
• Check out OpenInfra Labs and get involved in their mission to refine a model for fully integrated clouds supporting bare metal, VMs, and container orchestration.

Let’s keep talking about open infrastructure! Check out the next two OpenDev events:

• Hardware Automation, July 20-22, 2020
• Containers in Production, August 10-12, 2020

The post Takeaways and next steps from OpenDev: Large Scale Usage of Open Infrastructure appeared first on Superuser.

Starting with just a handful of servers 10 year ago, Nokia Enterprise and Services Cloud (NESC) has grown into one of the world’s largest OpenStack private clouds providing 484,000 virtual computing cores, 40PB of storage and a sustained monthly usage in excess of 230 million active core hours in month. NESC is distributed globally across three continents in six Tier three data centers and is used by Nokia for hosting mission critical research and development workloads and customer interfacing business applications. NESC provides standard Infrastructure As A Service components strengthened with ISO27001 certification.

Key to the success of NESC has been constant evolution, empowering our Nokia R&D and applications teams to reliably and rapidly build the virtual environments via self-service and automation. Every day in NESC there are over 200,000 new virtual server instance starts and close to 100,000 API calls per minute during peak hours, a challenge for any cloud.

Fortunately NESC has a great developer team who focus not on telling users what is not possible, but instead on figuring out how. This has driven the team to develop and excel in some key areas like:

Monitoring, logging and metrics analytics: NESC Logstash solution collects around 2 million log lines per minute which is then indexed and enriched in real-time to maximize the value of the data. In addition, NESC continuously collects huge volumes of metrics that are used not only for looking at current status, but also by applying Machine learning, are able to find anomalies,  performance degradations and even to make future predictions of outcomes based on trends.

Operation Automation:  “The best sysadmin is a lazy one”. They don’t want to fix same things over and over again.  Anything that can be automated in NESC is, from upgrades to database clean-ups and other resource leaks. 

Master data:  The key to successful and reliable automation is the reliability of programmable inventory data. You need to know with certainty on which assets what services are running so you can automate them. NESC tried enterprise commercial auto-discovery tools and other methods for many years, but none of them were reliable enough or able to keep dependencies and context consistent. Today, we have developed and implemented our own auto-discovery solution for inventory and configuration management as single source of truth.  

Security: With NESC software development tools & processes and the overall service being ISO 27001 certified, the security journey has been filled with automated controls and dedicated toolsets that are mostly open source based.  

Today NESC is stronger and better as a result, a dependable service within Nokia. The ability to embrace challenges forced the team to learn faster and adopt new ideas and services like GeoDNS, tiered storage solutions or NESC’s latest fast growing Kubernetes as service offering.  NESC DNA of fast development cycles,  fail sooner than later and extensive automation has pushed us this far.

The next chapter for NESC is to offer it as a managed service to Nokia customers worldwide, either as an on-Premises or off-premises solution.

The post Turning your challenges to opportunities in Nokia NESC OpenStack appeared first on Superuser.

I've had to re-teach myself how to do this so I'm writing my own notes.

Prerequisites:

1. Get a working undercloud (perhaps from tripleo-lab)
2. git clone https://git.openstack.org/openstack/tripleo-ansible.git ; cd tripleo-ansible
3. Determine the test name: ls roles

Once you have your environment ready run a test with the name from step 3.

./scripts/run-local-test tripleo_derived_parameters

 export TRIPLEO_JOB_ANSIBLE_ARGS="--skip-tags run_ceph_ansible,run_uuid_ansible"
 ./scripts/run-local-test tripleo_ceph_run_ansible

This last tip should get added to the docs.

The OpenStack Foundation (OSF) Edge Computing Group is excited to announce we published our latest white paper, a result of collaboration among fellow open infrastructure operators and vendors! With deployments of IoT devices and the arrival of 5G networks, edge computing has rapidly gained popularity over the past few years. While the popularity has rapidly increased, there are still countless debates about the definition of related terms and the right business models, architectures and technologies required to satisfy the seemingly endless number of emerging use cases of this novel way of deploying applications over distributed networks.

In our previous white paper, the OSF Edge Computing Group defined cloud edge computing as resources and functionality delivered to the end users by extending the capabilities of traditional data centers out to the edge, either by connecting each individual edge node directly back to a central cloud or several regional data centers, or in some cases connected to each other in a mesh. From a bird’s eye view, most of those edge solutions look loosely like interconnected spider webs of varying sizes and complexity.

Our second white paper, Edge Computing: Next Steps in Architecture, Design and Testing, delivers the specific ways open source communities are shaping the future of edge computing by collecting use cases, identifying technology requirements and contributing architectures, open source components and considerations for testing activities.

This white paper also highlights the OSF Edge Computing Group’s work to more precisely define and test the validity of various edge reference architectures. To help with understanding the challenges, there are use cases from a variety of industry segments, demonstrating how the new paradigms for deploying and distributing cloud resources can use reference architecture models that satisfy these requirements. 

Check out the lastest edge computing white paper here!

The post OSF Edge Computing Group defines architectures, open source components, and testing activities for massively distributed systems appeared first on Superuser.

If you are new to OpenStack Community and want to start the contribution, this document can help you in a quick way. OpenStack does not use github pull request instead it uses Gerrit for code collaboration tool. Also, there is some accounts setup required for using the Gerrit system. This guide will quickly help you to set up those accounts and the minimal steps

  Step1: Set up accounts

            sudo apt install git

            sudo yum install git

            sudo dnf install git

            sudo zypper in git

            git config --global user.name "Firstname Lastname"

            git config --global user.email "your_email@youremail.com"

• • • Use the same email address that was used during the OpenStack Foundation account setup.

• Setup Your Gerrit Account

  • Visit OpenStack’s Gerrit page and click the sign in link.
  • You will be prompted to select a username. Choose and type your username carefully. Once it is set, you cannot change the username.
  • From here on out when you sign in to Gerrit, you’ll be prompted to enter your Launchpad login info. This is because Gerrit uses it as an OpenID single sign on.
  • Sign Individual Contributor License Agreement. If you want to contribute from company then ask your company to sign the Company CLA.
    • In Gerrit’s settings click the “New Contributor Agreement” link and sign the agreement.

• Setup SSH Keys

  • In order to push patches to Gerrit we need to have a way to identify ourselves and ssh key is the one way to authenticate. You can submit patches from any machine but you need to update the ssh key of that machine.
  • Generate SSH Key Pairs

         ssh-keygen -t rsa

• • Copy Public Key

        cat ~/.ssh/id_rsa.pub

• • Add Public Key Into Gerrit
    • Go to Gerrit’s SSH Public Keys settings.
    • Click the ‘Add Key’ button.
    • Paste the public key into the Add SSH Public Key text box and click Add.

• Install git-review tool

  • pip install git–review
    • If you don’t have pip installed already, follow the installation documentation for pip.
  • git config —global gitreview.username <username>

  Step2: Push your change

        git clone https://opendev.org/openstack/<PROJECT_NAME>

    git checkout -b <branch_name>

        git status

    git add -A

    git commit
    or 
    git commit --amend (if you are ammending the previously written commit msg)

    git review

Spotlight on: Project Teams Gathering (PTG) Recap

It has been a week since the first virtual Project Teams Gathering (PTG)! While it was not the same experience as our traditional in-person PTGs, the community made the best of the current situation. We’ve been amazed by how many people have joined us online this year to collaborate on OSF-supported projects. We not only had the highest attendance and gender diversity in this PTG, but also had 20 more countries represented than the Denver PTG last year. Thank you to all the community members who have worked together virtually in this unprecedented time to collaborate without boundaries.

*Attendees’ attendance might be counted twice in the same day if they are participating in multiple sessions.

If you didn’t attend—or if you did and want a replay—check out the PTG spotlight on Superuser where we have collected the project announcements, community updates, and discussions you may have missed.

OpenStack Foundation news

• The OSF Edge Computing Group published its second white paper, Edge Computing: Next Steps in Architecture, Design and Testing.
• There will be two community meetings next week to cover OSF-supported project updates and event updates. One is on Thursday, June 25 at 1500 UTC and the other is Friday, June 26 at 0200 UTC. You can find the dial-in information here.
• The OSF has entered into a partnership with ETSI. The partnership will help strengthen collaboration between standardization and open source activities, including the area of edge computing.
• The OSF Board of Directors approved the 2020.06 RefStack guidelines.
• OpenDev: Large-scale Usage of Open Infrastructure Software, the first of three virtual OpenDev events, kicks off June 29. Register here.

Airship: Elevate your infrastructure

• Nominations for the Airship Technical Committee are now open, and will remain open until EOD June 21. More information here.
• Airship 2.0’s alpha milestone was completed in May. Stay updated on progress toward the beta through the blog.
• Running or evaluating Airship? The User Survey is available here. 

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

• We published two stable releases at the end of last week – 1.11.1 and 1.10.5.
  • Among other bug fixes, these releases include security fixes for CVE-2020-2023 and CVE-2020-2026.
  • Kata Security Advisory for the above CVEs describing impact and mitigation has been published here.
• All Kata versions prior to 1.11.1 and 1.10.5 are impacted. It is recommended to upgrade to the latest stable releases. The security fixes have been pushed to master as well.
• We tagged Kata Containers 2.0.0-alpha1 release last week. This release uses the rust agent as default and makes the switch to ttrpc from grpc as the communication protocol. We have also consolidated the agent and runtime repositories and moved them to kata-containers/kata-containers repository for better maintenance and release management.
• Now you can find the release information for 2.0.0-alpha1 here, and you can also find the features that we are planning for 2.0 here.

OpenStack: Open source software for creating private and public clouds

• The OpenStack community had a great virtual Project Teams Gathering. While we missed seeing each other in person, it was a productive event, putting the Victoria development cycle to a good start. You can still access all the etherpads for the event, and find summaries posted on the discuss mailing-list.
• Speaking of the Victoria cycle, the Technical Committee finally selected two community-wide goals around CI/CD for this cycle: switch legacy Zuul jobs to native, and migrate jobs to new Ubuntu 20.04 LTS. For more details, check out Ghanshyam Mann’s post on the mailing-list.
• Hot on the heels of the recent Ussuri release, Thomas Goirand announced the availability of packages for Debian sid, as well as the buster-ussuri.debian.net repositories. Peter Matulis announced the availability of the 20.05 OpenStack charms release, introducing support for OpenStack Ussuri on Ubuntu 18.04 LTS and 20.04 LTS. Amy Marrich announced the general availability of the RDO build for OpenStack Ussuri for RPM-based distributions, CentOS Linux and Red Hat Enterprise Linux.
• Following discussions at the PTG, the Technical Committee and the User Committee have started to move forward with merging into a single governance body for the OpenStack open source project, representing all contributors (developers, operators, and end users of the software). As a first step, the separate user-committee mailing-list was discontinued and future discussions will be held on the openstack-discuss mailing-list.

StarlingX: A fully featured cloud for the distributed edge

• StarlingX is now a confirmed top-level Open Infrastructure project supported by the OpenStack Foundation.
• The community is currently working on the 4.0 version of the platform that they are planning to release in July.
• You can check out this blog post to find out more about the community’s achievements since the project’s launch and their plans for the next release.

Zuul: Stop merging broken code

• Zuul 3.19.0 and Nodepool 3.13.0 are the last planned series 3 releases, incorporating a new Ansible 2.9 default, branch guessing for tags, ability to pause mergers, TLS encryption for Zookeeper connections, a new “serial” pipeline manager, a timezone selector for the dashboard, and more; work is underway for version 4 which sets the stage for distributed schedulers, stateful restarts, and high availability across all services.
• Zuul: A Wazo Platform Case Study
  • Learn why Wazo Platform, An open source software programmable telecommunication platform, leverages Zuul’s cross-repository dependencies for its repositories.
• Zuul: A T-Systems Case Study
  • Learn why global IT company T-Systems leverages Zuul’s ability to easily test workflows.

Check out these Open Infrastructure Community Events!

• 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 20-22, OpenDev – Hardware Automation
• July 29-30, Virtual Cloud Operator Day Tokyo
• August 16-17, Virtual OpenInfra Day China – contact Horace Li for more details
• August 17-20, KubeCon+CloudNativeCon Europe – OSF presentation by Kendall Nelson
• 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.

OpenStack Ironic operates in a curious world. Each release of Ironic introduces ever more inventive implementations of the abstractions of virtualisation. However, bare metal is wrapped up in hardware-defined concrete: devices and configurations that have no equivalent in software-defined cloud. To exist, Ironic must provide pure abstractions, but to succeed it must also offer real-world circumventions.

For decades the conventional role of an HPC system administrator has included deploying bare metal machines, sometimes at large scale. Automation becomes essential beyond trivial numbers of systems to ensure repeatability, scalability and efficiency. Thus far, that automation has evolved in domain-specific ways, loaded with simplifying assumptions that enable large-scale infrastructure to be provisioned and managed from a minimal service. Ironic is the first framework to define the provisioning of bare metal infrastructure in the paradigm of cloud.

So much for the theory: working with hardware has always been a little hairy, never as predictable or reliable as expected. Software-defined infrastructure, the method underpinning the modern mantra of agility, accelerates the interactions with hardware services by orders of magnitude. Ironic strives to deliver results in the face of unreliability (minimising the need to ask someone in the data centre to whack a machine with a large stick).

{
  "logical_disks": [
    {
      "raid_level": "1",
      "size_gb"   : 100,
      "controller": "software"
    },
    {
      "raid_level": "0",
      "size_gb"   : "800",
      "controller": "software"
    }
  ]
}

[{
  "interface": "raid",
  "step": "delete_configuration"
 },
 {
  "interface": "deploy",
  "step": "erase_devices_metadata"
 },
 {
  "interface": "raid",
  "step": "create_configuration"
 }]

virt-customize -a deployment_image.qcow2 --run-command 'dracut --regenerate-all -fv --mdadmconf --fstab --add=mdraid --add-driver="raid1 raid0"'

Open Source, Open Development

As an open source project, Ironic depends on a thriving user base contributing back to the project. Our experiences covered new ground: hardware not used before by the software RAID driver. Inevitably, new problems are found.

The first observation was that configuration of the RAID devices during cleaning would fail on about 25% of the nodes from a sample of 56. The nodes which failed logged the following message:

mdadm: super1.x cannot open /dev/sdXY: Device or resource busy

where X was either a or b and Y either 1 or 2, denoting the physical disk and partition number respectively. These nodes had previously been deployed with software RAID, either by Ironic or by other means.

Inspection of the kernel logs showed that in all cases, the device marked as busy had been ejected from the array by the kernel:

md: kicking non-fresh sdXY from array!

The device which had been ejected, which may or may not have been synchronised, appeared in /proc/mdstat as part of a RAID-1 array. The other drive, having been erased, was missing from the output. It was concluded that the ejected device had bypassed the cleaning steps designed to remove all previous configuration, and had later resurrected itself, thereby preventing the formation of the array during the create_configuration cleaning step.

For cleaning to succeed, a manual workaround of stopping this RAID-1 device and zeroing signatures in the superblocks was applied:

mdadm --zero-superblock /dev/sdXY

Removal of all pre-existing state greatly increased the reliability of software RAID device creation by Ironic. The remaining question was why some servers exhibited this issue and others did not. Further inspection showed that although many of the disks were old, there were no reported SMART failures, the disks passed self tests and although generally close, had not exceeded their mean time before failure (MTBF). No signs of failure were reported by the kernel in addition to the removal of a device from the array. Actively seeking errors, for example by running tools such as badblocks to exercise the entire disk media, showed that only a very small number of disks had issues. Benchmarking, burn-in and anomaly detection may have identified those devices sooner.

Further research may help us identify whether the disks that exhibit this behaviour are at fault in any other way. An additional line of investigation could be to increase thresholds such as retries and timeouts for the drives in the kernel. For now the details are noted in a bug report.

The second issue observed occurred when the nodes booted from the RAID-1 device. These nodes, running IPA and deploy images based on Centos 7.7.1908 with kernel version 3.10.0-1062, would show degraded RAID-1 arrays, with the same message seen during failed cleaning cycles:

md: kicking non-fresh sdXY from array!

A workaround for this issue was developed by running a Kayobe custom playbook against the nodes to add sdXY back into the array. In all cases the ejected device was observed to resync with the RAID device. The state of the RAID arrays is monitored using OpenStack Monasca, ingesting data from a recent release candidate of Prometheus Node Exporter containing some enhancements around MD/RAID monitoring. Software RAID status can be visualised using a simple dashboard:

Monasca MD/RAID Grafana dashboard using data scraped from Prometheus node exporter.

The plot in the top left shows the percentage of blocks synchronised on each RAID device. A single RAID-1 array can be seen recovering after a device was forcibly failed and added back to simulate the failure and replacement of a disk. Unfortunately it is not yet possible to differentiate between the RAID-0 and RAID-1 devices on each node since Ironic does not support the name field for software RAID. The names for the RAID-0 and RAID-1 arrays therefore alternate randomly between md126 and md127. Top right: The simulated failed device is visible within seconds. This is a good metric to generate an alert from. Bottom left: The device is marked as recovering whilst the array rebuilds. Bottom right: No manual re-sync was initiated. The device is seen as recovering by MD/RAID and does not show up in this figure.

The root cause of these two issues is not yet identified, but they are likely to be connected, and relate to an interaction between these disks and the kernel MD/RAID code.

Local European financial services companies rely on infrastructure that adheres to local regulatory requirements, often partnering with OpenStack cloud provider, City Network. A Gold Member of OSF, City Network provides public and private cloud environments, receiving the Superuser Award specifically for their research and development, professional services, education and engineering teams.

Keep reading to see how they’ve evolved since winning the Superuser Award at the Berlin Summit in 2018.

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

A lot! First, we are adamant about upgrading, so currently most locations run Train, but a few are still on older versions. Ideally, before summer, all of our locations and clouds will run Train. That in itself of course allows for more functionality and yet again improved stability.

In addition, we have looked to start engaging other projects we have not run before. So before going to Train, we activated Magnum as well as Barbican. Now with Train, we are also activating Designate and Manila. Manila is something many customers have wanted for a long time.

We also had a soft launch of our new cloud management system, written in React. It adds a bit of functionality that our public cloud requires.

What is the current size of City Network’s OpenStack environment?

We currently run well over 10,000 VMs in eight different locations from New York to Tokyo. Our focus is the European enterprise where many times regulatory challenges put a little extra work around how each workload is handled.

What version of OpenStack is City Network running?

Most locations are running Train, but we do have a few installations on Rocky as well. Those on Rocky will go to Train before summer.

What open source technologies does your team integrate with OpenStack?

As a whole, there are about 20 open source projects to make it all come together. OpenStack is of course the foundation to create a stack that can be fully automated. No doubt Kubernetes is something we also make sure our customers can run to orchestrate their containers. Magnum is a part of that container strategy. As with most container work loads, VMs are at the heart of those containers and we run it similarly. We are also looking into Kata Containers and are curious about the other OSF projects.

What workloads are you running on OpenStack?

With 1,200 customers in our public cloud we would say just about any and all types of workloads– from more traditional LAMP installations to modern container workloads with the latest CI/CD implementations pushing code at a fierce rate. As a company we focus on enterprise customers where anything from standard applications to the customer meeting is built out in our public cloud. In our Compliant Cloud, we run workloads mostly related to higher level regulatory challenges from banks to security companies. In Europe many of the leading digital ID companies run their workloads with City Network. So overall there is a very broad set of workloads.

How big is your OpenStack team?

We are about 25 people working with and around OpenStack.

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)?

Many years ago we started by contributing more by helping out in other ways than just technical– from hosting OpenStack Days to leading the public cloud group to being on the board, helping out in various committees. Another way was to become a gold member and thus support OSF financially as well. One part of this decision has been because we have felt we are not the programmers that can always jump in and add. However this is changing and we have for some time contributed smaller additions like reviews and some code when we find aspects that need corrections.

At this point we have a more aggressive vision of how we want to contribute technically and all around. We truly believe that we will become better operators if we know the code, as well as the people around the code. The more we engage the better we will become. So we have started to assign people in various parts of our engineering team that will start to contribute code. We just added 20% to Designate, and there are a few people that will work on OpenStack-Ansible for instance. From there we expect to get deeper into other projects as well.

What kind of challenges has your team overcome using OpenStack?

We simply would not be the company we are. By allowing our customers to fully automate the stack with the many projects of OpenStack we offer, we are a huge part of their digital transformation. We are on a journey made possible with OpenStack and of course a number of other open source projects. We do not think anybody can build what OpenStack offers unless you are a hyper scaler. For us, open source and the four opens of the OpenStack Foundation have formed us and how we like to see open infrastructure evolve.

That said, it has not always been easy. OpenStack was difficult to operate a few years back, and is still pretty complex. However, it has made huge strides towards being better in all ways including operation aspects. Today, a majority of our large-scale upgrades go by without incidents and no down time. Five years ago that was not always the case. It also allows for a ton more functionality, truly giving our customers all they need. Combining it with Kubernetes, there are next to no work loads we can not take on today in a dynamic way, allowing for that platform of innovation our customers require, whether a bank or a gaming company.

Another challenge is knowledge. We continue to educate internally but also love to see how the OpenStack Foundation is helping spread the word and trying to engage in educating more people. This will continue to be something we would love to see more of.

OpenStack continues to evolve at a rapid rate and just about all serious challenges are today dealt with and overcome. OpenStack has proven to work well with the most critical workloads and with significant volume. We are delighted to not only have OpenStack as our foundation but to also have joined one of the largest and fun open source communities in the world to work with.

Stay tuned for more updates from previous Superuser Award winners!

Cover Image: City Network

The post Where are they now? Superuser Awards: City Network appeared first on Superuser.

    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 will targeting Python 3.8 in the ‘‘Victoria’‘ development cycle.

    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 for python2.7 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 Tempest version or 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 python versions. This means that the OpenStack code was working or well-tested on both python versions 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 before 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.

It has been a week since the first virtual Project Teams Gathering (PTG)! While it was not the same experience as our traditional in-person PTGs, the community made the best of the current situation. We’ve been amazed by how many people have joined us online this year to collaborate across different time zones on the OSF projects. We not only had the highest attendance and gender diversity in this PTG, but also had 20 more countries represented than the Denver PTG last year. Thank you to all the community members who have worked together virtually in this unprecedented time to collaborate without boundaries. 

If you didn’t attend—or if you did and want a replay—we have collected the project announcements, community updates, and discussions you may have missed.

Airship:

The Airship community has participated in the June Virtual PTG and made progress on secrets, deployment configurations, and AirshipUI. The community saw higher participation than usually seen in person, and good cross-team collaboration with 3 other groups: StarlingX, Ironic, and the Edge Working Group. You can see the Airship project PTG agenda and recordings here.

Kata Containers:

The Kata Containers community had its first PTG event on June 2-3, 2020, including contributors and users from what felt like all of the timezones. The sun did not set on the discussion! 

Peng Tao from Ant Financial and Eric Ernst from Ampere facilitated several sessions covering a range of topics. While it didn’t involve as much hands-on-hacking as in past meetups, the community was able to take the time for more in depth discussions, and demonstrations of ongoing work. Check out the Kata Containers PTG update here.

OpenStack:

The OpenStack community had a great virtual PTG, and several teams have posted summaries on the mailing-list. Kendall Nelson from the OpenStack Technical Committee has summarized and posted the Victoria vPTG summaries and PTG OpenStack TC update: Victoria vPTG Summary of Conversations and Action Items on the OpenStack blog. If there is a particular action item you are interested in taking, please reply to the mailing list thread.

StarlingX: 

The StarlingX community participated in the first virtual PTG that was held online. At the virtual PTG on June 1-5, the StarlingX community spent almost ten hours discussing current technical challenges and new proposals as well as community-related topics. Check out the StarlingX PTG recap and learn about the discussion that happened at the event. 

In addition, you might also be interested in checking out the summary of the OSF Edge Computing Group sessions at the event.

*Attendees’ attendance might be counted twice in the same day if they are participating in multiple sessions

The post Project Teams Gathering (PTG) Recap appeared first on Superuser.

The first virtual Project Teams Gathering (PTG) was held on June 1-5 in all time zones around the globe providing the opportunity to anyone to join including contributors of the OSF Edge Computing Group (ECG).

The group had three sessions during the first three days of the week where we spent a total of seven hours to discuss topics relevant to edge computing use cases, technologies, and architectures. To take advantage of the virtual format, we also invited adjacent communities to participate like CNTT, OPNFV and the Kubernetes edge groups.

We started the sessions with the introduction of the work that the Edge Computing Group has been doing to define reference models and architectures that satisfy the requirements of most edge computing use cases and prepare for some common error cases. The main discussion point is the level of autonomy that an edge site requires which, among other things, affects the available functionality in case of losing the network connectivity towards the central data center. The two identified models are the Centralized Control Plane and the Distributed Control Plane.

The ECG has defined reference architectures to realize the above models with OpenStack services and started testing activities as well to verify and validate functionality. The purpose of the sessions at the PTG was to gather feedback about the models and to improve the reference architectures with adding new components and discuss the options to run all types of workloads at the edge.

We touched on TripleO’s Distributed Compute Node (DCN) architecture which is an example of the Centralized Control Plane model. Our discussions were circulating around challenges of edge deployments, such as latency: “100ms is a killer for distributed systems over WAN”; nodes getting out of sync can be a big issue. We also talked about improvements like Ceph being available since the OpenStack Train release compared to only ephemeral storage prior to that, and increased number of edge nodes that are running compute services and workloads.

We spent a longer amount of time discussing the Distributed Control Plane model which was in interest for the CNTT community as well therefore we discussed details about ways to implement this option. Some of the meeting participants have already been deploying OpenStack on edge sites which requires shrinking the footprint to prepare for limited hardware resources which is one of the common constraints of edge use cases. In case of running all the controller services at the edge, the resource usage can be a challenging factor, but it’s not an unsolved problem. Another popular option to discuss is the federated approach that is supported by components such as the OpenStack Identity Service (Keystone).

As an example to the distributed model, we had a short discussion about StarlingX and some of the design decisions the project has made to shape the project’s architecture. StarlingX is integrating well-known open source components such as OpenStack, Kubernetes, Ceph, etc into one platform along with services for software and hardware management that are developed by the community. During the PTG session, we discussed the Distributed Cloud feature in more details to understand how StarlingX manages the edge sites which can have full autonomy in case of network failures while still managed centrally. Discussion topics included understanding what is synchronized and shared between the nodes to ensure smooth operation in different scenarios and essential functionality for edge, such as zero touch provisioning.

StarlingX is running the majority of the platform services in containers and also provides the possibility to have edge sites with only container workloads in the architecture. The mention of containers lead the discussion towards better understanding the requirements towards container orchestration tools such as Kubernetes in edge infrastructure. We talked a bit about concepts such as Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Container as a Service (CaaS) and how the lines between these have started to disappear recently. The focus was on requirements on Kubernetes from a CaaS viewpoint while we also took a look at how it impacts the reference architectures. We need to understand storage and networking configurations as well as handling data crucial to run containers like quotas and certificates.

During the PTG sessions the participants took the opportunity to talk about storage which is an area that the ECG hasn’t gotten the chance yet to look into. We concentrated on object storage this time as the block storage strategies are a bit more straight forward. We agreed that the primary usage of object storage is to provide service for the applications, but it is useful for the platform too, like sharing images as a backend to the OpenStack Image Management (Glance) service. We had participants on the meeting from the OpenStack Object Storage (Swift) team to identify use cases and requirements for this component to take into account during the design and development process. The main use case we discussed was Content Delivery Networks (CDN) to leverage this functionality while online backup and gaming can also be considered. For design decisions we started to discuss architectural considerations and the effects of circumstances such as latency to the components of Swift.

As the PTG is a great opportunity to sync with project teams, we had joint sessions with the OpenStack Network Connectivity as a Service (Neutron) team and the OpenStack Accelerator (Cyborg) team. To also cover cross-community discussions, we had a session with the Airship project as well as KubeEdge from the CNCF community.

One of the ongoing discussions with Neutron is the handling of network segment ranges and to make sure they are defined and handled properly in the distributed environment in both architectural models. There is a feature request for Neutron that is already approved and has the potential to get priority during the Victoria release cycle. The first step is to put together a proof of concept deployment to test the planned configurations and changes. The Neutron team and ECG contributors will work on testing as a joint effort. A further relevant project is Neutron Interconnection which is mainly API definitions at this point as an effort to provide interconnection between OpenStack deployments and regions over WAN. Further networking related topics included functionality such as Precision Time Protocol that the StarlingX community is already working on along with Time Sensitive Networking (TSN).

The next cross-project session was the sync with the Cyborg team. This session was in big interest as the ability to use hardware accelerators is crucial for many edge use cases. During the session we were focusing on learning about the current activities within the project such as the implementation and next steps for the new v2 API. We also touched on device driver integration. Cyborg is concentrating on the ability of programming the acceleration devices made available to the applications and will not include low level device driver integration in the upstream code. The Cyborg team is working with Neutron, OpenStack Placement and OpenStack Compute (Nova) teams to ensure smooth integration and full functionality in these areas.

During the sync sessions we were also focusing on relevant topics such as lifecycle management of the platform services. One of the main challenges is to handle upgrades throughout the whole edge infrastructure which can be a big headache in massively distributed systems. In some use cases downtime is almost unacceptable which means that we need to prepare the edge site to have enough resources to keep services running while you are performing an upgrade. When it is not doable, we need to identify processes to minimize the time when the services are unavailable.

In connection to this theme we were talking to the Airship community as the project’s main mission is to address deployment and lifecycle management of software such as OpenStack and Kubernetes and therefore can be an option to address the aforementioned challenges. Airship is utilizing more and more components from the CNCF landscape as their concepts are using containers heavily for flexibility. For in place upgrades, Airship will use Cluster API and the concept of dual box deployment at edge sites which would ensure that there is always a replica of each service that provides availability during an upgrade process.

Our last session was with the KubeEdge project which is focusing on the usage of Kubernetes for edge computing use cases. It is built on top of Kubernetes with extensions such as application management, resource management and device management for IoT devices. Their main focus areas are IoT, CDN and Multi-access Edge Computing (MEC) scenarios. The project is releasing every three months and has an increased focus on IoT protocols. Their architectural model follows the Centralized Control Plane and running only worker nodes at the edge. As we had limited time during the PTG, we agreed to follow up with the collaboration after the event as well to work together on providing better solutions for edge computing use cases.

After the PTG we have a lot of action items to follow up on to evolve the architecture models as well as to help projects and adjacent communities with our learnings that they can use when they are working on their architecture solutions. We will keep looking closer into the object storage use cases and requirements to add that to our reference models and we are also working on setting up discussions with further Kubernetes groups such as the Kubernetes Edge and IoT group. We will also follow up on relevant implementation work and start testing activities when the software components are ready.

As a project highly relevant for edge, you might also be interested in checking out the StarlingX virtual PTG summary to learn about the community’s current activities and plans for the upcoming releases.

If you are interested in participating in the OSF Edge Computing Group, sign up to our mailing list and check out our weekly calls. You can find more information about the group’s activities on our wiki page. For a more cohesive summary of our work read the new white paper the group just published!

The post OSF Edge Computing Group PTG Overview appeared first on Superuser.

Wazo Platform is an An open source software programmable telecommunication platform. Wazo Platform allows you can pick and choose the components you need to build your infrastructures. Most of Wazo Platform’s 229 git repositories on GitHub use Zuul. Zuul allows Wazo Platforms to have cross repository dependencies in pull requests at the source code level, the Debian packaging level and at the container level. Similarly the nodes support their private OpenStack containers hosted in AWS CM Instance.

We got talking with Frederic Lepied to get some answers to why Wazo Platforms 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 had people coming into the organization with a lot of expertise in OpenStack so it was a natural move for us.

Describe how you’re using it:

Zuul is used with GitHub on most of our 229 git repositories at https://github.com/wazo-platform. The Zuul instance is hosted on AWS and is public at https://zuul.wazo.community/zuul/t/local/status. The nodes are VMs from our private OpenStack and containers hosted in AWS CM instance.

What is your current scale?

The scale in term of nodes is small (around 10) and big in term of repositories (229).

What benefits has your organization seen from using Zuul?

Zuul allows us to have cross repository dependencies in pull requests at the source code level, the Debian packaging level, and at the container level.

It also allows us to reuse job definitions among all the repository of the same type, which is very helpful.

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

Operations are difficult and we got a lot of help from the Software Factory team.

What are your future plans with Zuul?

We plan to continue to use Zuul for more tasks.

Are there specific features that drew you to Zuul?

Definitely the cross-repository dependencies.

The post Zuul: A Wazo Platform Case Study appeared first on Superuser.

Would you like to know about how you can get Virtual Machines, Bare Metal and Kubernetes in one environment? Download our white paper and get reading!  

Virtual Machines, Bare Metal and Kubernetes: All in One Environment!

Download White Paper

The post 4 Benefits of Going Serverless appeared first on VEXXHOST.

Codership is pleased to announce a new Generally Available (GA) release of the multi-master Galera Cluster for MySQL 5.6 and 5.7, consisting of MySQL-wsrep 5.6.48 (release notes, download) and MySQL-wsrep 5.7.30 (release notes, download) with a new Galera Replication library 3.30 (release notes, download), implementing wsrep API version 25. This release incorporates all changes to MySQL 5.6.48 and 5.7.30 respectively, making it a MySQL High Availability solution.

A highlight of this release is that with MySQL 5.7.30, you will now have access to using the Percona audit log plugin, which will help with monitoring and logging connection and query activity that has been performed on specific servers. This implementation is provided as an alternative to the MySQL Enterprise Audit Log Plugin.

The Galera Replication library 3.30 has an enhancement to ensure that upon GCache recovery, all available space will be reclaimed in the ring buffer. Frequent cluster configuration changes handling of errors are also improved.

MySQL-wsrep 5.6.48 is an updated rebase to the 5.6.48 release, but also includes improvements around crash recovery: when binary logs are enabled, there is a more consistent recovery. SSL initialization has seen improvements, and error handling of cluster wide conflicts have been improved when the cluster itself is acting as an asynchronous secondary to a MySQL primary.

MySQL-wsrep 5.7.30 is an updated rebase to the 5.7.30 release, and in addition to what is present in 5.6.48, there is also the audit log plugin as mentioned above. One important note is that for your Galera Cluster, ensure that InnoDB tablespaces are kept within the data directory (if kept outside, they may not be copied over during SST).

Across the board, there is now also support and packages for CentOS 8 and RHEL 8.

You can get the latest release of Galera Cluster from http://www.galeracluster.com. There are package repositories for Debian, Ubuntu, CentOS, RHEL, OpenSUSE and SLES. The latest versions are also available via the FreeBSD Ports Collection.

The OpenStack Ussuri release is now available! NetApp is proud to have contributed in the development of Cinder and Manila. The Ussuri release includes the following new features and feature enhancements that are supported by NetApp’s ONTAP and SolidFire storage platforms for your OpenStack deployment:  Ability to create shares from snapshots in aggregates and controllers other than the source share using Manila  Manila now efficiently creates shares from snapshots […]

The post My Name is Ussuri! appeared first on thePub.

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 Victoria Martinez de la Cruz from the OpenStack Manila project. She tells Superuser about how the Open Infrastructure community has helped her to grow and excel at her role in the community.

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

Currently, I’m mainly focused on contributing to feature development, code enhancements and bug fixing for the Shared Filesystems as a Service project for OpenStack (Manila). I also enjoy mentoring, so I’ve been helping with the mentoring efforts for the Outreachy program.

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

There are two factors that I think lead us to this situation: on one hand, I believe that people in tech tend to have the idea that some tasks are harder than others. For example, some people think that web development is easier than drivers development, something I believe is a mistake. Historically everything related to infrastructure administration has been considered a hard branch of computing. On the other hand, we know that there is a tendency for women to aspire to perfection and try to know everything before applying for a position or for taking the lead on a task. And, the harder the task is considered to be, the less women there are. Both things lead to the fact that not many women feel they can contribute to the projects we have in the OpenInfra community. I do believe there are women with the expertise and potential that we need, it’s just a matter of reaching them, and giving them opportunities. Some effort I think is being done by many companies in the community and also by other inclusion efforts such as Outreachy. We could do more though, for sure.

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

It gives them exposure, something that I think is critical in this market: exposure to real-world use cases to learn from, exposure to other people from different backgrounds, cultures and levels of expertise to work with, and exposure for them to become well known in the field, to expand their networks, and find which is the next step in their careers that challenges them and takes them to the next level.

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

Yes, there have been many efforts, that makes me very proud of my community. One of the initiatives that worked out very well has been Outreachy, and I think because it helped underrepresented individuals with no experience contributing to open source to their first steps. Guided by mentors, the interns learned how the processes in open source are and how they could contribute to. They also gained experience with the tools and technologies we use. Several good contributions have been made by our interns since they could contribute fresh perspectives and new ideas. Some of them continue to be involved with the community because they could connect with hiring companies and take a full-time role. This is something I’d love to see more. There are not so many remote entry level positions around for our interns to apply to, and I think that is a big loss, because we invest in people with high potential and then we let them go.

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

It’s definitely one of the biggest challenges we face. I believe that having an open and sharing community is key. It’s easier to keep up with things by sharing curated information between the collaborators than going ahead and reading all the material that is around. Material is good, but we are constantly being overloaded with details and stuff, which I think is good when you have the time or you actually want to focus on that specific topic. Otherwise, a summary by your peers is all that you need. That has been my strategy this last couple of years: I get updates from the community (either over IRC, reading the mailing list or watching presentations at conferences) and if I need to get a better understanding of something, I just go ahead and dig into the sea of articles and blog posts.

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

DO IT! No hesitation. I’m very grateful to everything that open source, and especially the Open Infrastructure community, has given to me: my colleagues, the technical experience I gained, my personal and professional growth. All experiences are different, for sure, but you need to go ahead and try. And the OpenInfra community? 10/10 would recommend to a friend.

I wish I had known how to organize my time better. I struggled a bit with that in the first couple of years. The amount of things happening at the same time was too much for me, and the context change used to kill my productivity. Plus, working remotely is not so straightforward as some people might think. Nowadays, taking the advice from several people from the community, I learned how to organize myself better and end my days feeling good about what I have accomplished.

The post Women of Open Infrastructure: Meet Victoria Martinez de la Cruz from the OpenStack Manila Project appeared first on Superuser.

We’re spotlighting previous Superuser winners who are on the front lines deploying OpenStack in their organizations to drive business success. These users are taking risks, contributing back to the community and working to secure the success of their organization in today’s software-defined economy.

China Mobile won the Superuser Award at the OpenStack Summit in Barcelona. As the world’s largest mobile phone operator with various OpenStack deployments, they are now not only building up the NFV network among world-leading operators based on OpenStack but also expanding the NFV platform to support 5G C in the near future. The following are their major OpenStack deployments.

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

We have carried out in-depth practice of OpenStack as the cloud infrastructure, especially in our Network Cloud, to build China Mobile’s NFV/SDN network. We believe it has directly promoted the maturity of the industry and the maturity of NFV/SDN solutions based on OpenStack, especially in a multi-vendor environment through our NFV/SDN pilot and NovoNet experimental network. China Mobile is now entered into the second year of NFV/SDN network construction since 2019. The network is about to commercialize in the second half of 2020.

What is the current size of your OpenStack environment?

The scale of China Mobile’s NFV/SDN network cloud is huge, in eight regions across the whole country.

We believe China Mobile is now building up the biggest NFV network among worlds leading operators based on OpenStack, the total number of servers in the network is more than 50,000 now. For each OpenStack instance, it has to manage 500 to 1,500 servers. The virtual network functions (VNFs) running on top of the virtualization includes IP Multimedia Subsystem (IMS), Evolved Packet Core (EPC) and value added services etc. and We will also expand the NFV platform to support 5G C in the near future.

What version of OpenStack are you running?

Mitaka + (with some enhancements of Pike/Queens version are absorbed)

What open source technologies does your team integrate with OpenStack?

Our team mainly researches NFV system integration. Now we build the CI/CD process to carry out automatic software integration and testing. Different virtual infrastructure manager (VIM) (OpenStack based platform), NFV orchestrator (NFVO) and VNF are automatically deployed and tested through a unified platform. Currently, the CI/CD platform uses Docker technology

What workloads are you running on OpenStack?

• 4G service, including 18 core network elements and service platforms, such as virtualized IMS, EPC, intelligent network and Short Message Service (SMS)/Multimedia Messaging Service (MMS) platform etc.
• 5G service.

How big is your OpenStack team?

It’s difficult to give the exact numbers, but we have different teams working on OpenStack, with one working on the additional telco requirements based on open source version, another team is to test the vendors’ product and make sure their commercial OpenStack software can support telco’s communication services. After deployment, there would be another team continuously working on the operational aspects of the OpenStack.

How is your team currently contributing back to the OpenStack project?

At present, in terms of Network Cloud, China Mobile is mainly acted as an OpenStack user. With the emergence of Edge Computing, we are also closely following and contributing other OpenStack projects, such as StarlingX.

What kind of challenges has your team overcome using OpenStack?

The feasibility of OpenStack carrying telecommunication service has been fully verified. At present, in the aspect of network operation and management, OpenStack still needs to be enhanced and improved to achieve “5 Nines” HA. In addition, more work needs to be done in the hyper-scale scenario to achieve high performance and high reliability of OpenStack.

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

The much anticipated release of Galera Cluster 4 for MySQL 8 is now Generally Available. Please join Codership, the developers of Galera Cluster, and learn how we improve MySQL High Availability with the new features in Galera Cluster 4, and how you can benefit from using them. We will also give you an idea of the Galera 4 short term road map, as well as an overview of Galera 4 in MariaDB, MySQL and Percona.

Learn about how you can load data faster with streaming replication, how to use the new system tables in the mysql database, how your application can benefit from the new synchronization functions, and how Galera Cluster is now so much more robust in handling a bad network for Geo-distributed Multi-master MySQL.

WATCH THE RECORDING 

The slides for the webinar can found here

WEBINAR SLIDES

Open Telekom Cloud is a major OpenStack-powered public cloud in Europe. It is operated for Deutsche Telekom Group by its subsidiary T-Systems International GmbH. 

Artem Goncharov, Open Telekom Cloud architect, shares why Open Telekom Cloud chose Zuul, the 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 the development of OpenStack client components like SDKs, CLIs, and other internal operational software components. After we managed to get some changes merged into Zuul, we deployed it productively as our continuous integration system. Today it is our CI system for the development of all open source tooling we offer to our clients. Furthermore, Zuul is currently used for monitoring our platform services quality. For that, we periodically execute a set of tests. It also includes monitoring permanently our RefStack compliance. 

We prepare Zuul as an internal service for other departments inside Deutsche Telekom apart from our own projects in the future. We run Zuul on our own public cloud, the Open Telekom Cloud, and also spawn the VMs there. We are all-in OpenStack!

Describe how you’re using Zuul

Currently, we have Zuul working on a public domain interacting with GitHub. Although the CI workflow with Gerrit is very powerful, we observed that some users struggle with its complexity. We thus made a decision to stay with GitHub to allow more people in our community to participate in the development of our projects. Nodepool spins up the virtual machines for the jobs facilitating an OpenStack driver.

What is your current scale?

We have a five-node zookeeper cluster and each one scheduler, a nodepool-builder, and a nodepool-launcher. At present two Zuul executors satisfy our needs. We have about ten projects managed by Zuul but plan to increase this number up to 50 soon. On average we do 50 builds a day.

What benefits has your organization seen from using Zuul?

We are now prepared for growth. Today, our projects are clearly laid out in size and complexity, but we expect the complexity to grow. Therefore we are relieved to have gating in place ensuring all software is tested and consistent all the time. That allows us to scale the number of projects we cover.

Second, we have better control over where and how the build and test processes take place. Since we are testing real-life cloud scenarios, there are credentials for and access to actual cloud resources involved. With Zuul and Nodepool we have better control over these virtual machines and the stored data.

Last, but not least we have a rather complex integration and deployment workflow. It is not just software that we build and package, but we also create other artifacts like documentation, PyPI packages, and a lot more that requires extra steps. We like the flexibility of having Ansible playbooks defining those workflows.

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

It is important for us to test all aspects of our public cloud. This functional testing obviously includes logging into domains, creating resources, and dealing with all aspects of credentials. Since this setup is connected to GitHub and thus indirectly accessible for the public, we felt a bit uneasy to run the Zuul setup on the same platform where we conducted the actual tests and builds. Eventually, we segregated those scopes by means of several dedicated OpenStack domains, where only Zuul is having API access to. So in the worst case should credentials should ever leak, we just have to clean up and reset one of our test domains, but the Zuul infrastructure itself remains unaffected from that. We facilitate the “project cleanup” feature of the OpenStack SDK for that, to which we also contributed.

We also experienced functional tests or verification of refstack often leave a lot of debris behind, which was not cleaned up by the code, sometimes even because of failing API calls of OpenStack itself. We leverage “project cleanup” also to mitigate this behavior.

Zuul publishes also a lot of information in log files to public readable Swift containers. Our security teams complain about that, even if most of the information is harmless. In some cases, we patched Zuul or its jobs so this data does not accumulate in the first place.

Both for operational and security reasons, we’d like to containerize all workloads as much as possible. Zuul comes with a set of Docker containers. Unfortunately, especially the Nodepool-builder needs a lot of privileges, which is hard to implement with plain old Docker. Our approach is to leverage Podman as an alternative for that.

What are your future plans with Zuul?

The Gerrit code review system implements a sophisticated role model, which enables users to do code reviews, promote revisions, or to authorize the eventual merges. It is a real challenge to implement these access control features just with GitHub. As a workaround for the time being we use “/merge” comments on the pull requests.

Even though Zuul’s prime directive is to automate, sometimes it’s nice to be able to manually intervene. Unfortunately, there’s currently not really a UI for administrative tasks like re-building some artifacts. That would come in handy to migrate even more Jenkins jobs.

The operation of Zuul is complex and we currently don’t have a dedicated ops team. We decrease the effort of operations by implementing Ansible playbooks for that, but this an ongoing effort.

We work on transforming Zuul into an internal offering for other Deutsche Telekom subsidiaries and projects, so they also start using it. We’re also very interested in enabling Kubernetes and OpenShift to act as an operations platform for Zuul. Here the challenge is inherited from multi-cloud issues that are required by high availability.

Are there specific Zuul features that drew you to Zuul?

Zuul fuels the development of OpenStack, which is a remarkable job and a considerable responsibility. We are impressed by how scalable and flexible it is and have even adapted its architecture to internal projects. We’re confident that there is more to come.

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

The Ubuntu OpenStack team at Canonical is pleased to announce the general availability of OpenStack Ussuri on Ubuntu 20.04 LTS and on Ubuntu 18.04 LTS via the Ubuntu Cloud Archive. Details of the Ussuri release can be found at:  https://www.openstack.org/software/ussuri

To get access to the Ubuntu Ussuri packages:

Ubuntu 20.04 LTS

OpenStack Ussuri is available by default for installation on Ubuntu 20.04.

Ubuntu 18.04 LTS

The Ubuntu Cloud Archive pocket for OpenStack Ussuri can be enabled on Ubuntu 18.04 by running the following commands:

sudo add-apt-repository cloud-archive:ussuri

The Ubuntu Cloud Archive for Ussuri includes updates for:

aodh, barbican, ceilometer, ceph octopus (15.2.1), cinder, designate, designate-dashboard, dpdk (19.11.1), glance, gnocchi, heat, heat-dashboard, horizon, ironic, keystone, libvirt (6.0.0), magnum, manila, manila-ui, mistral, murano, murano-dashboard, networking-arista, networking-bagpipe, networking-bgpvpn, networking-hyperv, networking-l2gw, networking-mlnx, networking-odl, networking-sfc, neutron, neutron-dynamic-routing, neutron-fwaas, neutron-fwaas-dashboard, neutron-vpnaas, nova, octavia, octavia-dashboard, openstack-trove, trove-dashboard, openvswitch (2.13.0), ovn (20.03.0), ovn-octavia-provider, panko, placement, qemu (4.2), sahara, sahara-dashboard, senlin, swift, trove-dashboard, vmware-nsx, watcher, watcher-dashboard, and zaqar.

For a full list of packages and versions, please refer to:

http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/ussuri_versions.html

Branch package builds

If you would like to try out the latest updates to branches, we deliver continuously integrated packages on each upstream commit via the following PPA’s:

sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka
sudo add-apt-repository ppa:openstack-ubuntu-testing/queens
sudo add-apt-repository ppa:openstack-ubuntu-testing/rocky
sudo add-apt-repository ppa:openstack-ubuntu-testing/stein
sudo add-apt-repository ppa:openstack-ubuntu-testing/train
sudo add-apt-repository ppa:openstack-ubuntu-testing/ussuri

Reporting bugs

If you have any issues please report bugs using the ‘ubuntu-bug’ tool to ensure that bugs get logged in the right place in Launchpad:

sudo ubuntu-bug nova-conductor

Thank you to everyone who contributed to OpenStack Ussuri. Enjoy and see you in Victoria!

Corey

(on behalf of the Ubuntu OpenStack Engineering team)

Would you like to know about OpenStack Cloud? So download our white paper and get reading!

Conquer the Competition with OpenStack Cloud

Download White paper

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.

Would you like to know about Private Cloud and what it can do for you? So download our white paper and get reading!

Fighting Off Certain Death with OpenStack Private Cloud

Download White Paper

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.

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

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.

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.

Would you like to know about OpenStack Cloud? So download our white paper and get reading!

Conquer the Competition with OpenStack Cloud

Download White paper

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

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.

OpenStack HIIT: OpenStack in Six Sessions

With a nod to the intensity of OpenStack's infamous learning curve, we've called our new workshop format OpenStack HIIT.

OpenStack HIIT is a remote workshop, delivered by video conference. The workshop is organised into six sessions. Session topics include:

1. Step-by-step deployment of an OpenStack control plane into a virtualised lab environment.
2. A deep dive into the control plane to understand how it fits together and how it works.
3. Operations and Site Reliability Engineering (SRE) principles. Best practices for operating cloud infrastructure.
4. Monitoring and logging for OpenStack infrastructure and workloads.
5. Deploying platforms and applications to OpenStack infrastructure.
6. OpenStack software-defined networking deep dive.
7. Ceph storage and OpenStack.
8. Contributing to a self-sustaining open source community.
9. Deploying Kubernetes using OpenStack Magnum.

Each session is led by a Senior Tech Lead from StackHPC's team. The workshop is designed to be interactive and up to six attendees can be supported.

Because it is remotely delivered, the sessions can be spread out, enabling attendees to read around the subject, practice content learned and prepare ahead for the next session.

The interactive sessions use lab infrastructure provided as part of the workshop. In some circumstances a client's own infrastructure can be used, which gives a client the opportunity to retain the lab environment and to use it between sessions. Additional provision for qualification of a client environment is required in this case.

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.

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).

Would you like to know about OpenStack Cloud? So download our white paper and get reading!

Conquer the Competition with OpenStack Cloud

Download White paper

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

Would you like to know about OpenStack Cloud? So download our white paper and get reading!

Conquer the Competition with OpenStack Cloud

Download White paper

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.

Photo by Florian Krumm on Unsplash

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/

Would you like to know about OpenStack Cloud? So download our white paper and get reading!

Conquer the Competition with OpenStack Cloud

Download White paper

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