Hello, Stackers! To recognize Murano as a separate community project with a specific agenda — despite occasional intersection with the agenda of the Community App Catalog — we’ve decided to launch a new monthly digest covering the agenda of the Murano project. Please enjoy our first issue.
What’s up in the Community?
Let’s start by looking at the community itself.
Murano staff news
Because OpenStack is about people let’s start by announcing changes to Murano’s core team.
First of all, let us welcome new core people on board. We are happy to celebrate Zhu Rong from 99Cloud. Did you know that Zhurong, according to ancient Chinese mythology, is a name of the God of Fire? If the god is one of us, is it a good moment to say: “In Code We Trust”?
Also, Alexander Tivelkov from Mirantis has now joined the core because of his work on the scalable framework architecture, which is one of the most notable features scheduled for the Newton release.
Finally, Steve McLellan has been removed from Murano core team. Steve has been part of Murano from the very early stages. However, his focus has since shifted, and we all appreciate Steve for his contributions and would like to express hope to see him back on the project in the future.
Murano technical news
Now let’s move to the tech news, and the two main points to note. The first one is that all of Murano is now Python 3.4-compliant. The second and most important news is about Igor Marnat’s initiative, which we described in App Catalog Review #5. He described a number of improvements for the process of developing OpenStack apps and distributing them via the Community App Catalog. (You can find more details on this in the Etherpad.)
The Murano team has made a huge step forward since then. Sergey Kraynev wrote a letter to describe it in detail. The key change is that the Murano core team has agreed to give up control of the repositories with the source code for Murano applications as the first step in separating Murano applications from the actual Murano core project itself. We’ll keep you updated, including a full story related to this topic in the second issue of the Murano Review.
If you want to join Murano meetings, please remember that we have weekly meetups in #openstack-meeting-alt on Tuesdays at 17:00 UTC. The Wiki provides more details.
Flashback: Everything you need to know about Murano discussions in Austin
We’re currently awaiting voting on Barcelona summit proposals, but meanwhile let’s catch up on what happened at the last one, in Austin.
A quick OpenStack Summit summary from Kirill Zaytsev
“During the Murano Fishbowl, the team presented an overview of features implemented in Mitaka, went through priorities for Newton, and had an opportunity to gather some user feedback from Murano users and contributors.
During the Newton cycle, the team is going to manage Murano’s community involvement with the help of Etherpad, making priorities more transparent and enabling easier collaboration from external contributors. The team also received valuable feedback on certain aspects of the Murano user experience.
During Murano’s first work session, the team discussed the future of the murano-apps ecosystem and agreed to push the CI/CD Murano app toolchain into a separate repo (as mentioned in the previous section) and then use those CI/CD tools as the starting point for the centralized CI/CD pipeline in which Murano apps can be developed, tested, and published to apps.openstack.org.
During the second work session, we discussed the current state of the Scalable App Framework.
We also had an interesting discussion with the interoperability/defcore team. They’re currently considering vertical certification programs. If we would ever want to have a certification program for OpenStack Application Catalog-compatible cloud, it could be implemented as one of such interop programs. The other way is to get support for inclusion into regular openstack certification programs by increasing adoption.
We also attended several sessions of the Stable Branch Maintenance team, which gave an overall positive fresh take on how we could view backports. The Neutron team, for example, treats any Closes-Bug commit as a potential backport and has certain toolsets for backporting/validating such bugs. One practice we should definitely pick up from other projects is leaving 5-10 empty migrations for backports after a stable branch is cut. A proposal suggested EOLing branches at 24 months instead of 18 months. The main problem is the manpower needed to support those, so at least for Kilo, the next release is going to be final. So, yes, OpenStack is about people.”
Murano-related talks in Austin
If you missed the summit — or if you just didn’t have time to get to them — you can also view videos of the Murano-related talks:
- Magnum or Murano? OpenStack Options for Container Environment Creation and Management
- Orchestrating Cross-cloud Applications with Murano
- Developing Cloud Apps: HOT, TOSCA and MuranoPL
Deep dive from Alexander: three Murano design summit sessions
Murano had three design summit sessions — separate from the main conference — two of them with some good attendance and useful outcomes.
The “What’s new” fishbowl got some wide audience participation, and Kirill started it off with gathering the feedback from the contributors and the adopters. The feedback was quite constructive, including a set of specific technical issues. Most of them we already knew of and had presented in Murano’s backlog, but the feedback helped us understand the proper prioritization for these issues.
The second session was dedicated to two topics related to the murano-apps repo and the applications that currently live there, as Sergey Kraynev briefly mentioned above. We discussed:
1) What we should do with our murano-apps project/repository and
2) What should the governance (repo and infra location, project group, etc.) be for the upcoming murano-CI/CD application stack being developed by Sergey and his team.
For the first topic, the group agreed that the apps supported by the core Murano team (wherever they are located) should be just the demo applications showing various features and capabilities of Murano and demonstrating the best coding guidelines and design principles. Because of that, the current set of applications should be reduced since most of the apps in the murano-apps project duplicate each other in terms of Murano features being used (e.g. there is no sense in having both Apache and Tomcat applications which differ only in the set of VM-side config scripts).
Also we’ve agreed to consider moving these demo apps into the main Murano repository and use them for testing Murano in its check and gate jobs. Meanwhile the “production grade” Murano applications (of which the most well-known in the murano-apps repo is the Kubernetes app) should be moved away into their own repos so they may have their dedicated development/reviewing teams, bug trackers, release cycles, tags, branches, and so on. Eventually, we plan to deprecate the murano-apps repository.
Regarding the second topic, the group agreed to move this stack of applications into a standalone project/repo under the OpenStack umbrella (say, openstack/murano-ci-cd-pipeline). At the beginning, that project will contain all four of the related Murano apps (Jenkins, Gerrit, OpenLDAP, DNS app), but when they are mature enough, we may consider splitting them into their own independent projects.
The third Murano session didn’t work out: due to low attendance, the demo of the scalable framework prototype which was planned for this session didn’t happen.
The last day was reserved for contributors’ meetups: informal gatherings of the upstream contributors where they could discuss various kinds of open questions and have some generic conversations and other social activities. The Murano team didn’t request a meetup room on this summit because we had completed all our discussions with the contributors during the first four days of the event, so we had no specific agenda for the last day. However, there were some other important sessions besides the meetup, and that’s where we played a significant role.
The most interesting one was the Enterprise Working Group work session, the gathering of people who work on helping enterprises to adopt their technologies for using the cloud. The attendance was quite large, and we discussed how to properly understand and address the needs of large business for the clouds, how to educate them, and how to help move their apps to the cloud.
The particular interest for us was an initiative to create a reference architecture of the workloads to be run on the clouds. Right now, the working group is finalizing the reference architectures for the 3-tier app, eCommerce solution, and a Big Data processing solution. Soon these description will be published at the openstack.org/marketplace or somewhere else.
The Murano team has volunteered to take part in this process: as soon as the design for these reference architecture patterns is ready, we will implement them as a set of Murano applications and publish them on the apps.openstack.org. We’ll keep you updated on this process.
Please, feel free to provide us with some feedback. For example, let us know what topics related to Murano you are interested in. Also, if you do have some user experience with Murano, you are more than welcome to share it with us. Frankly speaking, that’s our dream—to make a part of this digest based on real-use cases. And we’ll do all our best to make this dream real.