Interview with Mark McClain, OpenStack Networking Project Leader
We present the first of a series of interviews with technical leaders of the OpenStack project in the Mirantis blog. Our goal is to educate the wider technical community and help people understand how they can contribute to and benefit from the OpenStack project. Naturally, below is the point of view of the interviewee, not of Mirantis. The interview is published with bills in connection with the restriction of the length of the article.
Our first interview was with Mark McClain, the newly elected technical project manager for OpenStack Networking (formerly known as “Quantum”).
Mirantis: Tell us about yourself and how you started working with OpenStack.
')
Mark McClain: I’m a senior cloud application developer at DreamHost and I’m working on a cloud development team. DreamHost hired me specifically to work on OpenStack. This happened in the middle of the Essex development cycle, and the great thing about working on OpenStack, and especially on OpenStack networking projects, is that this project combines two of my favorite topics: networking and Python.
Q: What are your responsibilities? What do you do every day, as part of your routine work?
A: When preparing the Grizzly release, I mainly focused on improving the functionality of the metadata service when using intersecting IP networks. I also worked on data migration so that those who deploy OpenStack can easily switch from Folsom to Grizzly. When preparing the Grizzly release, I also led several groups, including L3 groups, a database, and error sorting.
Now, as a technical project manager, I have a much broader view of the project. I am responsible for holding the weekly team meeting and organizing the Network branch at the development guide meeting. Every day, I’ll keep in touch with the developer community, coordinate with team leaders, view code updates and error sorting, and view project diagrams. I also communicate with other members of the Foundation and Technical Committee on inter-project issues.
Q: What is special about the OpenStack Networking project? Why is this project so important?
A: With Nova services, you can create virtual machines with basic networking capabilities. But, if you want to use more advanced technologies, for example, tunneling to isolate network users or VXLAN, you will not be able to achieve this fully with the network capabilities of the Nova. These services limit you to building a VLAN or flat network. New technologies make it possible to maximize the benefits of networking in OpenStack, providing user isolation scaling.
Q: What has the community of network projects OpenStack reached now, what are your plans for the release of Havana?
A: The OpenStack Networking community was originally created at the Diablo summit. This project was in its infancy during the work on Essex and was built into Folsom. While working on Essex and Folsom, the community spent a lot of time aligning the functionality and embedding L2 and L3 features in OpenStack Networking.
As part of the Grizzly project, we were able to shift the focus to adding new services, as well as reducing the gap in functionality with Nova network services. As part of the Grizzly development cycle, we added overlapping metadata services, migration, and security groups. Another breakthrough Grizzly functionality is load balancing.
In fact, it was Mirantis employees who helped implement the load balancing service. It was a large joint project, in which many developers from different companies participated. Together, they created an API and framework for a load balancing service.
In the Havana project, we plan to expand the load balancing service and add more features. Looking ahead, there are developers in the community who are working on the development of OpenStack Networking, adding VPN support, commercial grade ACL support, and IPv6 support. IPv6 basic functionality is now available, and developers want to add higher-level services on top of it. Also, some companies and community members are working on hardware support, full support for node distribution, provision of high availability on a smaller scale than support for several nodes in Nova ... also some community members have teamed up to work on other user functions.
Q: Is there something unique in OpenStack Networking or is it just a publicly available version of an existing “Networking as a Service”?
A: I think that the most unique thing in OpenStack Networking compared to other solutions “Networking as a Service” is a very lively participation of the company community. During the Grizzly development cycle, we added five new plugins from various companies . This is one of the unique features in OpenStack Networking. She also demonstrates the initiative of suppliers, because most suppliers have decided to invest their efforts in the development of OpenStack.
If you compare this with other cloud networking solutions, they have one or two options, if they are lucky. Thus, you only get the network functionality of the package.
Q: What usage examples show the special value of OpenStack Networking?
A: In multi-user environments that require isolation and security, you can quickly pick up and run systems and provide services to users, whether it is a public or private cloud, and you can start services at an appropriate scale quickly enough.
For smaller deployments, the OpenStack Networking infrastructure can simply be configured to support smaller private clouds using open tools. Small companies with limited resources can take advantage of many of the features that are available in large installations.
Q: When you say “fast enough”, can you give accurate data?
A: For a small company, following the OpenStack guidelines — if you are familiar with OpenStack, it will take half a day. If you are not familiar with OpenStack, maybe one or two days. The guides will guide you through the installation and help you get through the installation, which is suitable for most cases.
This task can be performed with a minimum number of employees on ordinary equipment. You do not need special switches or servers. If you are trying to experiment to see if an OpenStack or OpenStack Networking solution is right for you, you can use the existing test environment.
Q: What technologies do you need to know to run OpenStack Networking?
A: This is the same set of knowledge that your network engineer or even an IT specialist would have. You need a general introduction to the principles of IP network deployment.
Thus, no special skills are required, because much of what plug-in authors have implemented - both in open source and commercial plug-ins - does not require in-depth knowledge of how certain protocols work. As a result, the developer can focus on exploring the API.
Q: Are there any misconceptions about OpenStack Networking?
A: We are not particularly struggling with misconceptions about OpenStack Networking. I think most people are right about how it works. Some will still prefer to deploy Nova network services for new installations, because they have doubts about the complexity, availability or stability of OpenStack Networking.
Now there was a successful installation support materials, and in the process of deployment there were options for building OpenStack, so these questions were removed. For new deployments, we recommend using OpenStack Networking from the very beginning and using the services capabilities rather than starting with Nova-network with migration to OpenStack Networking, since such migration is nontrivial.
During the development of Havana, OpenStack Networking and Nova will discuss how to narrow this gap and how OpenStack Networking can become the default network infrastructure provider for Nova.
Q: How about the scalability of OpenStack Networking?
A: There are several large installations in which the OpenStack Networking network infrastructure is running. Some of them use the Folsom version, while others use the current code (trunk), which is very interesting because it speaks of the maturity of the source code.
Q: Does the OpenStack Networking project still have any “childhood diseases”?
A: We at Grizzly spent a lot of time working on isolated metadata services. Among the questions in technical support and error messages that we received after the release of Folsom, there was often a question: “how does the metadata service work?”. Therefore, we spent a lot of time to make the metadata service easier to set up or ready to work for a number of deployments. This is probably the most serious “disease” that we got rid of in Grizzly.
Q: Who would you like to see as a member of the OpenStack Network Project?
A: We are very lucky in this regard. Representatives of such reputable companies as Arista, BigSwitch, Brocade, Cisco, HP, IBM, NEC, Nicira, Juniper, Midokura, Plumgrid and VMware participate in the project. During the Grizzly cycle, we added even more companies and start-up projects that offer their solutions, thereby attracting innovation to the community.
As for the perfect member ... this is someone who is passionate about networking issues and wants to participate in the OpenStack community, and is willing to share ideas with other members in order to benefit in the end for the community as a whole.
Q: What opportunities are available for those who want to create something outstanding in the OpenStack Network Project?
A: In the Havana project there will be a significant promotion of VPN-as-Services in several deployment modes. In addition, we will actively work on load balancing. At Grizzly, we have taken small steps to implement this feature and now several suppliers are trying to use this API. IPv6 support will also be greatly enhanced. More and more Internet service providers are offering v6 services for commercial installations. It is also very important to ensure that the OpenStack Network Project project works for different IPv6 deployment modes.
We also welcome OpenStack Networking hardware and device management on a larger scale: “If I am a hardware provider, how can I integrate my hardware into the infrastructure of an OpenStack network?” In addition, we are working on topics that are interesting for deployment: how Can I provide different levels of service?
Q: What would you recommend to people who want to join the developers of OpenStack Networking? What steps should they take?
A: The first step is to join the OpenStack developer mailing list . From it, you can understand which topics are being discussed by the OpenStack Networking developers.
The OpenStack Networking team also maintains a Wiki page for answering popular beginner questions . On this page, we track links to code reviews for the server and client sides of OpenStack Networking. As error messages appear, we mark the simplest ones as an opportunity to join the project for new developers and other contributors.
This means that those who sort the errors can say this: “This is not a very difficult question and you can use it to familiarize yourself with the OpenStack Networking code base.” We also maintain a list of community projects from which it is convenient to start. As a member of the OpenStack Networking mailing list, you can engage other community members to collaborate. Thus, trust between members of the community increases, so that those who checked your code can now work with you. It enhances mutual understanding.
Q: Thanks a lot Mark!
A: Please!
Our first interview was with Mark McClain, the newly elected technical project manager for OpenStack Networking (formerly known as “Quantum”).
Mirantis: Tell us about yourself and how you started working with OpenStack.
')
Mark McClain: I’m a senior cloud application developer at DreamHost and I’m working on a cloud development team. DreamHost hired me specifically to work on OpenStack. This happened in the middle of the Essex development cycle, and the great thing about working on OpenStack, and especially on OpenStack networking projects, is that this project combines two of my favorite topics: networking and Python.
Q: What are your responsibilities? What do you do every day, as part of your routine work?
A: When preparing the Grizzly release, I mainly focused on improving the functionality of the metadata service when using intersecting IP networks. I also worked on data migration so that those who deploy OpenStack can easily switch from Folsom to Grizzly. When preparing the Grizzly release, I also led several groups, including L3 groups, a database, and error sorting.
Now, as a technical project manager, I have a much broader view of the project. I am responsible for holding the weekly team meeting and organizing the Network branch at the development guide meeting. Every day, I’ll keep in touch with the developer community, coordinate with team leaders, view code updates and error sorting, and view project diagrams. I also communicate with other members of the Foundation and Technical Committee on inter-project issues.
Q: What is special about the OpenStack Networking project? Why is this project so important?
A: With Nova services, you can create virtual machines with basic networking capabilities. But, if you want to use more advanced technologies, for example, tunneling to isolate network users or VXLAN, you will not be able to achieve this fully with the network capabilities of the Nova. These services limit you to building a VLAN or flat network. New technologies make it possible to maximize the benefits of networking in OpenStack, providing user isolation scaling.
Q: What has the community of network projects OpenStack reached now, what are your plans for the release of Havana?
A: The OpenStack Networking community was originally created at the Diablo summit. This project was in its infancy during the work on Essex and was built into Folsom. While working on Essex and Folsom, the community spent a lot of time aligning the functionality and embedding L2 and L3 features in OpenStack Networking.
As part of the Grizzly project, we were able to shift the focus to adding new services, as well as reducing the gap in functionality with Nova network services. As part of the Grizzly development cycle, we added overlapping metadata services, migration, and security groups. Another breakthrough Grizzly functionality is load balancing.
In fact, it was Mirantis employees who helped implement the load balancing service. It was a large joint project, in which many developers from different companies participated. Together, they created an API and framework for a load balancing service.
In the Havana project, we plan to expand the load balancing service and add more features. Looking ahead, there are developers in the community who are working on the development of OpenStack Networking, adding VPN support, commercial grade ACL support, and IPv6 support. IPv6 basic functionality is now available, and developers want to add higher-level services on top of it. Also, some companies and community members are working on hardware support, full support for node distribution, provision of high availability on a smaller scale than support for several nodes in Nova ... also some community members have teamed up to work on other user functions.
Q: Is there something unique in OpenStack Networking or is it just a publicly available version of an existing “Networking as a Service”?
A: I think that the most unique thing in OpenStack Networking compared to other solutions “Networking as a Service” is a very lively participation of the company community. During the Grizzly development cycle, we added five new plugins from various companies . This is one of the unique features in OpenStack Networking. She also demonstrates the initiative of suppliers, because most suppliers have decided to invest their efforts in the development of OpenStack.
If you compare this with other cloud networking solutions, they have one or two options, if they are lucky. Thus, you only get the network functionality of the package.
Q: What usage examples show the special value of OpenStack Networking?
A: In multi-user environments that require isolation and security, you can quickly pick up and run systems and provide services to users, whether it is a public or private cloud, and you can start services at an appropriate scale quickly enough.
For smaller deployments, the OpenStack Networking infrastructure can simply be configured to support smaller private clouds using open tools. Small companies with limited resources can take advantage of many of the features that are available in large installations.
Q: When you say “fast enough”, can you give accurate data?
A: For a small company, following the OpenStack guidelines — if you are familiar with OpenStack, it will take half a day. If you are not familiar with OpenStack, maybe one or two days. The guides will guide you through the installation and help you get through the installation, which is suitable for most cases.
This task can be performed with a minimum number of employees on ordinary equipment. You do not need special switches or servers. If you are trying to experiment to see if an OpenStack or OpenStack Networking solution is right for you, you can use the existing test environment.
Q: What technologies do you need to know to run OpenStack Networking?
A: This is the same set of knowledge that your network engineer or even an IT specialist would have. You need a general introduction to the principles of IP network deployment.
Thus, no special skills are required, because much of what plug-in authors have implemented - both in open source and commercial plug-ins - does not require in-depth knowledge of how certain protocols work. As a result, the developer can focus on exploring the API.
Q: Are there any misconceptions about OpenStack Networking?
A: We are not particularly struggling with misconceptions about OpenStack Networking. I think most people are right about how it works. Some will still prefer to deploy Nova network services for new installations, because they have doubts about the complexity, availability or stability of OpenStack Networking.
Now there was a successful installation support materials, and in the process of deployment there were options for building OpenStack, so these questions were removed. For new deployments, we recommend using OpenStack Networking from the very beginning and using the services capabilities rather than starting with Nova-network with migration to OpenStack Networking, since such migration is nontrivial.
During the development of Havana, OpenStack Networking and Nova will discuss how to narrow this gap and how OpenStack Networking can become the default network infrastructure provider for Nova.
Q: How about the scalability of OpenStack Networking?
A: There are several large installations in which the OpenStack Networking network infrastructure is running. Some of them use the Folsom version, while others use the current code (trunk), which is very interesting because it speaks of the maturity of the source code.
Q: Does the OpenStack Networking project still have any “childhood diseases”?
A: We at Grizzly spent a lot of time working on isolated metadata services. Among the questions in technical support and error messages that we received after the release of Folsom, there was often a question: “how does the metadata service work?”. Therefore, we spent a lot of time to make the metadata service easier to set up or ready to work for a number of deployments. This is probably the most serious “disease” that we got rid of in Grizzly.
Q: Who would you like to see as a member of the OpenStack Network Project?
A: We are very lucky in this regard. Representatives of such reputable companies as Arista, BigSwitch, Brocade, Cisco, HP, IBM, NEC, Nicira, Juniper, Midokura, Plumgrid and VMware participate in the project. During the Grizzly cycle, we added even more companies and start-up projects that offer their solutions, thereby attracting innovation to the community.
As for the perfect member ... this is someone who is passionate about networking issues and wants to participate in the OpenStack community, and is willing to share ideas with other members in order to benefit in the end for the community as a whole.
Q: What opportunities are available for those who want to create something outstanding in the OpenStack Network Project?
A: In the Havana project there will be a significant promotion of VPN-as-Services in several deployment modes. In addition, we will actively work on load balancing. At Grizzly, we have taken small steps to implement this feature and now several suppliers are trying to use this API. IPv6 support will also be greatly enhanced. More and more Internet service providers are offering v6 services for commercial installations. It is also very important to ensure that the OpenStack Network Project project works for different IPv6 deployment modes.
We also welcome OpenStack Networking hardware and device management on a larger scale: “If I am a hardware provider, how can I integrate my hardware into the infrastructure of an OpenStack network?” In addition, we are working on topics that are interesting for deployment: how Can I provide different levels of service?
Q: What would you recommend to people who want to join the developers of OpenStack Networking? What steps should they take?
A: The first step is to join the OpenStack developer mailing list . From it, you can understand which topics are being discussed by the OpenStack Networking developers.
The OpenStack Networking team also maintains a Wiki page for answering popular beginner questions . On this page, we track links to code reviews for the server and client sides of OpenStack Networking. As error messages appear, we mark the simplest ones as an opportunity to join the project for new developers and other contributors.
This means that those who sort the errors can say this: “This is not a very difficult question and you can use it to familiarize yourself with the OpenStack Networking code base.” We also maintain a list of community projects from which it is convenient to start. As a member of the OpenStack Networking mailing list, you can engage other community members to collaborate. Thus, trust between members of the community increases, so that those who checked your code can now work with you. It enhances mutual understanding.
Q: Thanks a lot Mark!
A: Please!
Source: https://habr.com/ru/post/182578/
All Articles