opensource.google.com

Menu

Posts from January 2023

Configure your private clouds using the Google Cloud VMware Engine IaC Foundations repository

Tuesday, January 31, 2023

Introduction

Google Cloud VMware Engine is a Google-managed VMware platform that customers can use to run their VMware workloads on Google Cloud. VMware Engine private clouds consist of VMware ESXi clusters that are managed by Google. Customers manage the virtual infrastructure of private clouds using VMware vCenter and VMware NSX-T for software-defined networking. The GCVE IaC Foundations code guides customers to automate the configuration of several layers of the infrastructure and virtualization stack, using infrastructure as code. This includes the integration of platform logging and monitoring with the Google Cloud Operations Suite, configurations such as VM folders, permissions and VM deployments in vCenter and network configurations in NSX-T, including subnets, firewalls, and load balancers.

The use of infrastructure as code for a VMware Engine Private Cloud offers multiple benefits, including:

  1. Providing consistent and repeatable deployment templates which can be reused across SDLC environments to reduce human error and shorten configuration times.
  2. Enabling continuous integration using GitOps workflows to improve collaboration between engineers and increase reliability in the release process.
  3. Offering version control of configuration templates to track changes in the infrastructure and a simple method to revert changes to a previous configuration.

Technical Details

The Google Cloud VMware Engine IaC Foundations Github repository contains Terraform modules and sample code for maintaining VMware Engine, vCenter and NSX-T configurations using infrastructure as code. The repository is structured as follows:

├── examples
│   ├── nsxt-gateway-firewall
│   ├── nsxt-load-balancer-pool
│   ├── nsxt-load-balancer-service
│   ├── ...
├── modules
│   ├── nsxt-gateway-firewall
│   ├── nsxt-load-balancer-pool
│   ├── nsxt-load-balancer-service
│   ├── ...
└── stages
    ├── 01-privatecloud
    ├── 02a-nsxt
    ├── 02b-vcenter
    ├── 03-vms
    └── 04-load-balancing

The modules directory contains the Terraform IaC modules for GCVE (vCenter & NSX-T) resource types. Each module has a corresponding example in the examples directory. Modules and examples are meant to be discrete and function as the building blocks for managing GCVE at scale.

The stages directory contains sample deployments composed from modules for each of the different stages of the foundational deployment. These stages should be executed in the order they are listed. Stages may also be delegated to different teams within an organization depending on organizational roles and responsibilities. As an example, there may be a team that manages vCenter, while a Networking team manages NSX-T and each team has their own code repository for configuration management.

The individual stages deploy the following components:

Stage

Deployed sample Component(s)

01-privatecloud

  • Google Cloud Monitoring & Logging integration for GCVE

02a-nsxt

  • Virtual machine network segment

  • North / south firewall (gateway firewall)

  • East / west firewall (distributed firewall)

02b-vcenter

  • vCenter resource pools & folders

  • vCenter role assignments

03-vms

  • Virtual machines

04-load-balancing

  • NSX-T Load balancing

Deployment Walkthrough

To deploy the sample stages you will need to clone the gcve-iac-foundations repository and have Terraform 1.3.x or later installed.

To deploy the stages proceed in order in the stages directory from 01-privatecloud until 04-load-balancing. In each directory perform the following:

  • Copy terraform.tfvars.example to terraform.tfvars and customize any values as necessary
  • Run `terraform init`, `terraform plan` and `terraform apply`

Each of the stages and examples contain reference terraform.tfvars files which can be used in the initial stages to test deployment and later customized to meet specific requirements.

As an example, the following Terraform configuration can be used to configure the NSX-T distributed firewall:

dfw_policies = [
  {
    display_name    = "dfw_allow_policy"
    sequence_number = 1
    rules = [
      {
        action             = "ALLOW"
        destination_groups = ["10.123.1.0/24"]
        source_groups      = []
        direction          = "IN_OUT"
        display_name       = "dfw-allow-ssh"
        logged             = false
        services           = ["SSH"]
      },
      {
        action             = "ALLOW"
        destination_groups = ["10.123.2.0/23"]
        source_groups      = ["10.200.1.0-10.200.1.128"]
        direction          = "IN_OUT"
        display_name       = "dfw-allow-dns"
        logged             = false
        services           = ["DNS"]
      },
    ]
  },
<…snip…>
]

Apply the Terraform configuration from a terminal using

terraform init // initialize the provider and modules
terraform plan // validate the expected Terraform configuration on the console
terraform apply // deploy the configuration in NSX-T

Try it yourself

Whether you consider using VMware Engine for your VMware workloads or you actively use the service already, give it a try and clone the repository into your environment and go through the provided deployment examples and stages of the repository. Review if you can automate any processes that you perform manually today using infrastructure-as-code and improve your VMware operations using the content from the foundations repository.

We would like to get your feedback! If you encounter any issues or you have any feedback or suggestions for improvement, create an issue directly on the repository on Github. We would also like to encourage you to create pull requests to the main branch if you like to become an active contributor. To get started, review how to contribute on Github.

By Konrad Schieban and Jason Steenblik – Google Cloud

Acknowledgments:

Thank you to the following team members who made this solution possible: Kumari Renuka, Ashwin Naik, Leandro Carracedo, Eric Danan, and Umesh Kumhar from Google Cloud.

Mentor organization applications are open for Google Summer of Code 2023!

Monday, January 23, 2023


We are excited to announce that open source projects and organizations can now apply to participate as mentor organizations in the 2023 Google Summer of Code (GSoC) program. Applications for organizations will close on February 7, 2023 at 18:00 UTC.

As 2023 begins, so does our 19th year of Google Summer of Code! Last year, we had a few updates to the program that will continue for the 2023 program year. Our most noted change coming in 2023 is that we are expanding the program to be open to students and to beginners in open source software development. We are also continuing our increased flexibility in the length of the projects—offering 175 and 350-hour projects—and the ability to extend the program from the standard 12 weeks up to 22 weeks.

Does your open source project want to learn more about becoming a mentor organization? Visit the program site and read the mentor guide to learn what it means to be a mentor organization and how to prepare your community (hint: have plenty of excited, dedicated mentors and well thought out project ideas!).

We welcome all types of organizations and are very eager to involve first-timers with a 2023 goal of welcoming 30+ new orgs into GSoC. We encourage new organizations to get a referral from experienced organizations that think they would be a good fit to participate in GSoC.

The open source projects that participate in GSoC as mentor organizations do all kinds of interesting work in security, cloud, development tools, science, medicine, data, media, and more! Projects can range from being relatively new (about 2 years old) to well established projects that started over 20 years ago. We welcome open source projects big, small, and everything in between.

One thing to remember is that open source projects wishing to apply need to have a solid community; the goal of GSoC is to bring new contributors into established and welcoming communities. While you don’t have to have 50+ community members, the project also can’t have as few as three people.

You can apply to be a mentor organization for GSoC starting today on the program site. The deadline to apply is February 7, 2023 at 18:00 UTC. We will publicly announce the organizations chosen for GSoC 2023 on February 22nd.

Please visit the program site for more information on how to apply and review the detailed timeline for important deadlines. We also encourage you to check out the Mentor Guide, our new ‘Intro to Google Summer of Code’ video, and our short video on why open source projects are excited to be a part of the GSoC program.

Good luck to all open source mentor organization applicants!

By Stephanie Taylor, Program Manager – Google Open Source Programs Office

Announcing Google Season of Docs 2023!

Wednesday, January 18, 2023



Google Season of Docs provides support for open source projects to improve their documentation and gives professional technical writers an opportunity to gain experience in open source. Together we raise awareness of open source, of docs, and of technical writing.

How does GSoD work?

Google Season of Docs allows open source organizations to apply for a grant based on their documentation needs. If selected, the open source organizations use their grant to directly hire a technical writer to complete their documentation project. Organizations have up to six months to complete their documentation project. At the end of the program, organizations complete their final case study which outlines the problem the documentation project was intended to solve, what metrics were used to judge the effectiveness of the documentation, and what the organization learned for the future. All project case studies are published on the Season of Docs site at the end of the program.

Organizations: apply to be part of GSoD!

The applications for Google Season of Docs open February 15 for the 2023 cycle. We strongly suggest that organizations take the time to complete the steps in the exploration phase before the application process begins, including:
  • Creating a project page to gauge community and technical writer participant interest (see our project ideas page for examples).
  • Publicizing your interest in participating in GSoD through your project channels and adding your project to our list of interested projects on GitHub.
  • Lining up community members who are interested in mentoring or helping onboard technical writers to your project.
  • Brainstorming requirements for technical writers to work on your project (Will they need to be able to test code, work with video, or have prior experience with your project or related technologies?).
  • Reading through the case studies from previous Season of Docs participants.

Organizations: create your project page

Every Google Season of Docs project begins with a project page, which is a publicly visible page that serves as an overview of your documentation project. A good project page includes:
  • A statement of the problem your project needs to solve (“users on Windows don’t have clear guidance of how to install our project”).
  • The documentation that might solve this problem (“We want to create a quickstart doc and installation guide for Windows users”).
  • How you’ll measure the success of your documentation (“With a good quickstart, we expect to see 50% fewer issues opened about Windows installation problems.”).
  • What skills your technical writer would need (break down into “must have” and “nice to have” categories. “Must have: access Windows machine to test instructions”).
  • What volunteer help is needed from community members (“need help onboarding technical writers to our discussion groups”) and links to where the community can discuss the proposal.
  • Most importantly, include a way for interested technical writers to reach you and ask questions!

Technical writers: reach out to organizations early!

Technical writers do not submit a formal application through Google Season of Docs but those interested in working with accepted open source organizations can share their contact information now via the Google Season of Docs GitHub repository; or they may submit proposals directly to the organizations using the contact information shared on the organization project page. Check out our technical writer guide for more information. We suggest that interested technical writers read through the case studies from the previous Season of Docs participants to get an idea of the kinds of projects that have been accepted and what organizations have learned from working with technical writers.

General timeline

February 15 - March 24 Open source organizations apply to take part in Google Season of Docs

March 31

Google publishes the list of accepted organizations, along with their project proposals and doc development can begin.
May 10

Technical writer hiring deadline
June 14

Organization administrators begin to submit monthly evaluations to report on the status of their project.
November 6 - 21

Organization administrators submit their case study and final project evaluation.
December 5

Google publishes the 2023 case studies and aggregate project data.

May 1, 2024 Organizations begin to participate in post-program followup surveys.
See the full program timeline for more details.

Join us

Explore the Google Season of Docs website at g.co/seasonofdocs to learn more about participating in the program. Use our logo and other promotional resources to spread the word. Check out the timeline and FAQ, and get ready to apply!

By Romina Vicente and Erin McKean – Google Open Source Programs Office

More voices = More Bazel

Wednesday, January 11, 2023

Takeaways from the BazelCon DEI lunch panel

In front of a standing-room-only lunch panel, Google’s head of Developer X strategy Minu Puranik asks us, “If there is one thing you want to change [about Bazel’s DEI culture], what would it be and why?”

We’d spent the last hour on three main themes: community culture, fostering trust, and growing our next generation of leaders. Moderated by Minu, our panel brought together a slate of brilliant people from underrepresented groups to give a platform to our experiences and ideas. Together with representatives and allies in the community, we explored methods for building inclusivity and sought a better understanding of the institutional and systemic barriers to increasing diversity.

Culture defines how we act, which informs who feels welcome to contribute. Studies show that diverse contributor backgrounds yield more and better results, so how do we create a culture where everyone feels safe to share, ask questions, and contribute? Helen Altshuler, co-founder and CEO of EngFlow, relayed her experience regarding some best practices:

“Having people that can have your back is important to get past the initial push to submit something and feeling like it’s ok. You don’t need to respond to everything in one go. Last year, Cynthia Coah and I gave a talk on how to make contributions to the Bazel community. Best practices: better beginners’ documentation, classifying GitHub issues as ‘good first issue,’ and having Slack channels where code owners can play a more active role.”

                    Helen Altshuler, co-founder and CEO of EngFlow

Diving further, we discussed the need to make sure new contributors get positive, actionable feedback to reward them with context and resources, and encourage them to take the risk of contributing to the codebase. This encouragement of new contributors feeds directly into the next generation of technical influencers and leaders. Eva Howe, co-founder and Legal Counsel for Aspect, addressed the current lack of diversity in the community pipeline.

“I’d like to see more trainings like the Bazel Community Day. Trainings serve two purposes:

1. You can blend in, start talking to someone in the background, and form connections.
2. We can give a good first educational experience. It needs to be a welcoming space.”

                     Eva Howe, Legal Counsel – Aspect Dev

In addition to industry trainings, the audience and panel brought up bootcamps and university classes as rich sources to find and promote diversity, though they cautioned that it takes active, ongoing effort to maintain an environment that diverse candidates are willing to stay in. There are fewer opportunities to take risks as part of a historically excluded group, and the feeling that you have to succeed for everyone who looks like you creates a high-pressure environment that is worse for learning outcomes.

To bypass this pipeline problem, we can recruit promising candidates and sponsor them through getting the necessary experience on the job. Lyra Levin, Bazel’s internal technical writer at Google, spoke to this process of incentivizing and recognizing contributions outside the codebase, as a way to both encourage necessary glue work, and pull people into tech from parallel careers more hospitable to underrepresented candidates. And Sophia Vargas, Program Manager in Google’s OSPO (Open Source Programs Office), also offered insight regarding contributions.

“If someone gives you an introduction to another person, recognize that. Knowing a system of people is work. Knowing where to find answers is work. Saying I’m going to be available and responding to emails is work. If you see a conversation where someone is getting unhelpful pushback, jump in and moderate it. Reward those who contribute by creating a space that can be collaborative and supportive.”

                     Lyra Levin, Technical Writer

“Create ways to recognize non-code contributions. One example is a markdown file describing other forms of contribution, especially in cases that do not generate activity attached to a name on GitHub.”

An audience member agreed that for the few PRs a positive experience is critical for community trust building: And indeed, open source is all about building trust. So how do we go about building trust? What should we do differently? Radhika Advani, Bazel’s product manager at Google, suggests that the key is to:

“Make some amazing allies. Be kind and engage with empathy. Take your chances—there are lots of good people out there. You have to come from a place of vulnerability.”

                    - Radhika Advani, Bazel Product Manager

Vargas also added some ideas for how to be an “amazing ally” and sponsor the careers of those around you, such as creating safe spaces to have these conversations because not everyone is bold enough to speak up or to ask for support since raising issues in a public forum can be intimidating. Making yourself accessible and providing anonymous forms for suggestions or feedback can serve as opportunities to educate yourself and to increase awareness of diverging opinions.

An audience member stated that recognizing an action that is alienating to a member of your group—even just acknowledging their experience or saying something to the room—can be very powerful to create a sense of safety and belonging. And another said that those in leadership positions being forthright about the limits of their knowledge, gives people the freedom to not know everything.

So to Minu’s question, what should we do to improve Bazel’s culture?

Helen: Create a governance group on Slack to ensure posts are complying with the community code of conduct guidelines. Review how this is managed for other OSS communities.

Sophia: Institutionalize mentorship; have someone else review what you’ve done and give you the confidence to push a change. Nurture people. We need to connect new and established members of the community.

Lyra: Recruit people in parallel careers paths with higher representation. Give them sponsorship to transition to tech.

Radhika: Be more inclusive. All the jargon can get overwhelming, so let’s consider how we can make things simpler, including with non-technical metaphors.

Eva: Consider what each of us can do to make the experience for people onboarding better.

There are more ways to be a Bazel contributor than raising PRs. Being courageous, vulnerable and open contributes to the culture that creates the code. Maintainers: practice empathy and remember the human on the other side of the screen. Be a coach and a mentor, knowing that you are opening the door for more people to build the product you love, with you. Developers: be brave and see the opportunities to accept sponsorship into the space. Bazel is for everyone.

By Lyra Levin, Minu Puranik, Keerthana Kumar, Radhika Advani, and Sophia Vargas – Bazel Panel

.