OpenStack

"The benefit we see is the ease of integration with other projects," says Melvin Hillsman who works at Huawei on OpenLab. The post How OpenLab is using Zuul appeared first on Superuser.

The first week has passed and in this post I will cover what I did to get my first contribution during application phase and some follow up reading afterwards. Here I will focus on general tools used in OpenStack development workflow. In next post I ... [More] will write about the project I'm working on. It was easy to start developing for OpenStack projects and almost everything I needed to know is well documented in one long page[1]. The page contains some links to follow for more detailed information. One of such pages that I find useful is about commit messages[2] that not only writes about messages themselves, but about splitting commits in smaller patches where split is reasonable and somewhat isolated rather than creating one large patch which is harder to review for everyone involved. Also commit messages should be self-contained and hold enough information to understand what's being done and why without accessing other systems like issue/bug tracker. This also says that commit message bodies should be wrapped at 72 characters. The main page[1] only mentions commit message headers that should be 50 characters. Then there are specific OpenStack code style guidelines for Python[3] that also references the general Python style guide, PEP 8[4]. Here I'm relying on tox to catch any violations. To write some code, I cloned the necessary projects, branched, and made some changes. There were some tools missing from my development environment that I installed as I went by, and I did not encounter any setup related issues when running projects. Once the changes are done, the next step is to submit it for code review. Gerrit is used for code review, it used to be written in Python, but was rewritten in Java. Wikipedia says[5] that it was done to make it easier to run on different Linux systems, but it does not give any reference to source and a quick search online did not help me to find any historical discussions, but this is not so important here, was just curious. More about Gerrit it is written at [6]. Gerrit distinguishes between core reviewers and regular reviewers, something that I have not seen in other tools where coders enforce it manually. In such cases, it is not like they try to bypass core reviewer requirement (as system does not enforce it), but it makes hard to identify open code reviews that are missing core reviewers, so it is nice that Gerrit has this built-in. There is a handy tool git-review[7] to make work with Gerrit easier - to submit code review just run git review instead of following instructions in Gerrit's quick intro[6]. Once code review submitted Zuul[8] gets involved. Don't have to interact with this much, but Zuul will be the one who will tell if there are tests failing and PEP 8 guidelines violated. This should have been checked locally before submitting code review, but there are always more integrations to run and other issues that might not show up in local environment. As there are many patches submitted within the same time frame, Zuul will queue them and test queued patches together according to their place in queue to catch any conflicts between patches before they get merged to master. Then when code review is done and usually it requires 2 core code reviewers to approve, the Zuul will merge the changes to master. That's all for now, if I encounter something new or something I misunderstood in relation to workflow and tools, will share it in further posts. [1] OpenStack development manual - https://docs.openstack.org/infra/manual/developers.html [2] Git messages guidelines - https://wiki.openstack.org/wiki/GitCommitMessages [3] OpenStack Python style guidelines - https://docs.openstack.org/hacking/latest/user/hacking.html [4] Python style guidelines - https://www.python.org/dev/peps/pep-0008/ [5] Gerrit History in Wikipedia - https://en.wikipedia.org/wiki/Gerrit_(software)#History [6] Gerrit quick intro - https://review.openstack.org/Documentation/intro-quick.html [7] git-review tool - https://docs.openstack.org/infra/git-review/ [8] Zuul documentation - https://docs.openstack.org/infra/zuul/ [Less]

I spent some time today figuring out how the new mechanism for inventory plugins for Ansible 2.5 works, and also spent quite a bit of time scratching my head at an error I encountered when executing a test playbook against Rackspace Public Cloud. ... [More] Inventory Plugin for OpenStack The inventory plugin system was introduced into Ansible 2.4. The old dynamic inventory mechanism still works, so until now I’ve never tried to use the new system. The documentation is a little confusing and I found the inventory samples by Alan Rominger very useful to get me on the right track. The minimal requirement to make the OpenStack inventory plugin work is to put a file named openstack.yml or openstack.yaml in your inventory folder. For example, I have the following in ansible.cfg: [defaults] inventory = inventory And the contents of inventory/openstack.yml is: plugin: openstack fail_on_errors: yes This assumes that you already have a clouds.yaml file in your ~/.config folder, and have the shade library installed into the same python environment as Ansible. That’s it! Thanks to the default auto inventory plugin being enabled, it will find the openstack.yml file and enable the OpenStack inventory plugin. Using the Ansible os_server module against Rackspace Public Cloud When trying to use the os_server module against Rackspace Public Cloud I got this error: TASK [Create/delete OpenStack Instance] ************************************************************************************************************************ fatal: [localhost]: FAILED! => changed=false extra_data: null msg: 'Unavailable feature: security groups' This is odd, because the same playbook works just fine in Ansible 2.3. I spent quite a bit of time trying to hunt down what changed to precipitate this problem but was unsuccessful. I did manage to find a way to make it work though - just provide an empty list for the security_groups argument. - name: Create/delete OpenStack Instance os_server: name: "setup-instance-test1" flavor: "general1-1" state: "present" cloud: "rackspace" region_name: "IAD" image: "Ubuntu 18.04 LTS (Bionic Beaver) (PVHVM)" key_name: superduper security_groups: [] config_drive: yes meta: build_config: core wait: yes timeout: 900 The default value the module has is [ 'default' ] and the module therefore tries to implement this when building the instance. However it seems that this capability is not available for Rackspace Public Cloud, and it fails the task. I hope that figuring this out will help someone else save some time. [Less]

I am happy to share with you the publishing of the second document of the FlexPod SolidFire with Red Hat OpenStack Platform 10 – Cisco Validated Design (CVD) solution. Paired with its partner Design Guide, this CVD enables an enterprise-grade ... [More] OpenStack deployment, in an accelerated fashion, with little risk. Deployment Guide (NEW) – is a ... Read more The post NetApp, Cisco and Red Hat announce OpenStack on FlexPod SolidFire! appeared first on thePub. [Less]

Hear experts from Cisco, Red Hat, Suse and more. The post Inside public cloud: Must-see sessions at the Vancouver Summit appeared first on Superuser.

After launching in 2017, the OpenDev Conference is now an annual event. At the inaugural event last September, the conference focus was on edge computing. This year's event, taking place May 22-23, will be focused on Continuous Integration/Continuous Deployment (CI/CD) and will be co-located with the OpenStack Summit in Vancouver.

The post What is Open Networking? appeared first on Aptira.

We've added improvements to all three tiers of MCP, the DriveTrain CD layer, the cloud platform itself, which includes Kubernetes and OpenStack Pike, and the StackLight monitoring layer.

Yih Leong Sun on multi-cloud, upcoming challenges for users and how you can get involved. The post Meeting the challenges of next-generation workloads: The OpenStack User Committee appeared first on Superuser.