Uncategorized

I’m looking for someone to join my team and work on OpenStack networking and service function chaining

I lead a globally distributed engineering team at Red Hat, working on OpenStack’s networking projects. I’m looking for someone to be a part of the team with a focus on the SFC project. The candidate will:

  • Become the subject matter expert on all matters SFC
  • Review code
  • Participate in upstream development
  • Resolve bugs
  • Draft design documents
  • Implement features
  • Lead and participate in design discussions
  • Attend conferences
  • Improve the project’s testing infrastructure
  • Own the project’s RPM packaging
  • Resolve customer issues

If you want to do open source, Red Hat is objectively where it’s at. We have an institutional culture of open source at all levels and this has a ripple effect on your day to day and your career at the company. You will work with a talented, autonomous, empowered and passionate team of people with a healthy work/life balance.

The ideal candidate is familiar with cloud, networking, Linux, Python, open source, or some combination of the above. You may work from home or from one of our offices listed here: redhat.com/en/jobs/locations.

Please email me CVs at assaf@redhat.com.

Standard
Uncategorized

“But I’m not a networking person!”

I hear that a lot, as if networking is this insurmountable mountain you could not possibly claim. Here’s how you become a networking person: You go to bed after a full day of work, overworked and frustrated with networking lingo. You have the craziest dream! It’s filled with streams of binary numbers, but you’re somehow able to convert them to ASCII instantly. You suddenly not only know that the first half of a MAC address designates the vendor of the NIC, you somehow also know that Qumranet‘s is 00:1A:4A. The seven layer model appears before you, every layer stacked upon the one before it like some perfectly formed Jenga tower from Cisco’s version of hell. Just as you’re breaking a sweat (This is getting too weird, you think), you wake up. Suddenly, Richard M. Stallman comes back from wherever it is he’s hanging around these days, networking cable in hand. He lays it on your shoulder, and then the other, like some sort of perverted Knighthood ceremony. You wake up from this dream within a dream and whisper: “I know networking.”

That’s how it usually works, anyway. Other people are not so lucky and have to learn the basics like they learn anything else: Read a book, then another one. Meet with some people, ask some questions. Practice it, learn it on the job, wing it. It’ll be alright.

Standard
OpenStack

New Neutron testing guidelines!

Yesterday we merged https://review.openstack.org/#/c/245984/ which adds content to the Neutron testing guidelines:

http://docs.openstack.org/developer/neutron/devref/development.environment.html#testing-neutron

The document details Neutron’s different testing infrastructures:

  • Unit
  • Functional
  • Fullstack (Integration testing with services deployed by the testing infra itself)
  • In-tree Tempest

The new documentation provides:

  • Advantages and use cases for each testing framework
  • Examples
  • Do’s and don’ts
  • Good and bad usage of mock
  • The anatomy of a good unit test

It’s short – I encourage developers to go through it. Reviewers may save time by linking to it when testing anti-patterns pop up.

Enjoy, I hope you’ll find it useful.

Standard
OpenStack

Neutron in-tree integration tests

It’s time for OpenStack projects to take ownership of their quality. Introducing in-tree, whitebox multinode simulated integration testing. A lot of work went in over the last few months by a lot of people to make it happen.

http://docs.openstack.org/developer/neutron/devref/fullstack_testing.html

We plan on adding integration tests for many of the more evolved Neutron features over the coming months.

Standard