Open Mic Spotlight, 4th Birthday Edition: Kashyap Chamarthy

kashyapThis post is part of the OpenStack Open Mic series to spotlight the people who have helped make OpenStack successful. Each week, a new contributor will step up to the mic and answer five questions about OpenStack, cloud, careers and what they do for fun. For the month of July, we’re focusing on Q&A specific to OpenStack’s 4th birthday. If you’re interested in being featured, please choose five questions from this form and submit!

Kashyap currently works for Red Hat on most things related to open source virtualization/cloud related projects (OpenStack). He works remotely, from India. Kashyap enjoys reading, traveling, and learning to be conscious to live minimally and in an ecologically sustainable way.

1. Where were you when you first heard of OpenStack? What were you doing?

It was in 2012 in Brussels, Belgium. I was there to participate in the (no-nonsense) FOSDEM conference. For most of the second (and the last) day of the conference I was hanging out in the “Virtualization Dev” room and attended the final session of the day: an OpenStack community panel discussion moderated by Thierry Carrez (current OpenStack release manager) & co. Most of the debates in that session were around evolving project governance, roles of linux distributions, release process and plenty their related topics. That’s when I learned about OpenStack.

2. What drew you to OpenStack?

I got involved in OpenStack around 2013 through RDO project (a community OpenStack distribution that stays close to upstream trunk, started by Red Hat). I’d say it’s the sheer range of areas one can contribute to in many useful ways. By the time I was starting with OpenStack, it clearly helped to have been closely familiar with some of the under-the-hood open source virtualization technologies (like libvirt, QEMU, KVM and a ton of tooling around it) that OpenStack relies on. I feel it’s a nice progression to work on a higher-level project like OpenStack that already takes advantage of these and connects them all together in a meaningful way (and not some afterthought bolt-on).

Others factors would be OpenStack’s commitment towards technical meritocracy, its fair (walking the walk style) approach in governance and community interactions, and flat out fun in participating in such a large community-based software project.

3. What does “open source” mean to you?

To me, it’s the strong belief that it is the most sensible approach to develop software. Secondly, the realization that “hey, I get to benefit immensely from the work of scores of open source communities (at the tap of a keystroke — thanks to innovations like GPL, Creative Commons and the likes), so it’s just fair to contribute back to those communities on whose labour I’m building my existing work.”

4. Which OpenStack debate gets you the most fired up? Why?

Hmm, off the top of my head I can’t single out something. But there are a lot of interesting technical/community related debates on the very high-traffic upstream openstack-dev mailing list. It’s a great experience for a new person to learn the community culture by following discussions (with some good mail filters), getting a sense of tone on the lists, what kind of topics to bring up (and how) and many more things — just by plain old observation.

I don’t mean to imply that everything is rainbows and butterflies. Sure, there are (open/closed) conflicts too – like any massive project with a lot of moving parts, but the civilized manner in which most of them are resolved is heartening to see.

5. What is your favorite memory from am OpenStack summit?

I haven’t been to an OpenStack summit, yet. But I was at an OpenStack meetup (“OpenStack in Action 4″ by eNovance, last November in Paris). In the conference lobby, I noticed Mark McClain (current Neutron project PTL) passed by – I walked up, politely introduced my self and had a brief conversation. Before I left him alone, I asked him to share a piece of wisdom that can help one wrap his/her head around the complexity of Neutron (OpenStack Networking project) and its associated open source plugins. “Read ‘iproute2′ man pages, read carefully and experiment more, it’s full of useful details,” Mark said. And I still haven’t gotten to
it. So, by saying it out loud here, hopefully I’ll get my act together and spend some quality time with it. :-)


OpenStack Swift 2.0 Released and Storage Policies Have Arrived

This blog post was first featured on the SwiftStack Blog, and you can find the original post here.

Today I’m happy to announce the release of OpenStack Swift 2.0.0. This release includes storage policies – the culmination of a year of work from many members of the Swift contributor community. Storage policies are the biggest thing to happen in Swift since it was open-sourced four years ago. Storage policies allow you to tailor your storage infrastructure to exactly match your use case. This release marks a significant milestone in the life of the project that will lead to further adoption and community growth.

You can get Swift 2.0 from As always, you can upgrade to this version without any client downtime.

Storage Policies

What are storage policies, and why are they so important? Storage policies allow deployers to specifically configure their Swift cluster to support the different needs of data stored in the cluster.

Use case examples

Once the storage policies are configured, users can create a container with a particular policy, and all objects stored in that container will be stored according to that container’s storage policy.

Let’s explore two use cases enabled by storage policies: a reduced redundancy storage policy and a geographically-specific storage policy.


We normally recommend 3x replication in Swift clusters. It provides a good balance between durability and overhead for most data. However, some data is trivially re-creatable and doesn’t require the same durability. A very good example of this is image thumbnails. If the original resolution image is stored with 3x replication, then a resampled image can be stored with 2x replication. This saves 33% on storage costs, and any data loss is mitigated by the ability to recreate the resized image from the original.

When used at scale to store and serve on-demand user-generated content, as Swift is used today, a “reduced redundancy” storage policy can save significant hard drive space, thus lowering costs. Storage policies can be created to enable different replication factors to be used in the same cluster, depending on the type of data that needs to be stored.

Another example is using different storage policies to geographically distinguish data sets. Suppose your company has a central office in Dallas, a branch office in New York, and a branch office in San Francisco. The data stored and used in one branch office doesn’t need to be shared with the other branch office, but the central office should have a copy of everything. With Swift 2.0, you can create a policy that references the storage capacity in Dallas and New York and another policy that references the storage capacity in San Francisco and Dallas. Now, anything stored in the “New York” policy will be stored in New York and locally available for fast lookup. It is the same with the “San Francisco” policy. But also the central Dallas office has a copy of everything that is being stored in the branch offices.

The central office can easily manage offsite archives and has very good visibility into each branch’s data consumption. Storage policies in Swift 2.0 augment Swift’s existing global cluster capabilities and allows finer-grained control over where the data resides.

Deployer Impact of Storage Policies

Conceptually, storage policies are pretty simple: where a Swift cluster used to support only one object ring, now it can take advantage of many object rings. Each ring in Swift describes a set of storage volumes (i.e. drives), and it includes information necessary for data placement and failure handling. With storage policies, deployers can configure their Swift cluster to support the different needs of data stored in the cluster.

It is safe for deployers to upgrade their existing clusters to use storage policies. And clusters can still be downgraded, at least until you define a second storage policy. If you have multiple policies configured and you revert to pre-storage policy code, any data in the new storage policies will be inaccessible, since older Swift versions do not know how to access it.

Storage policies are defined in the swift.conf configuration file. Existing clusters are treated as having a default “policy zero”. This means existing clusters can take advantage of the new code without needing to immediately begin supporting additional policies. New policies can be configured in that same config file and are then made available for clients. Each storage policy has a new ring.


The developer docs for storage policies include quite a bit more information, including details about the on-disk data layout, deprecating policies, and changes to background consistency processes.

Client Impact of Storage Policies

Storage policies expand the Swift API in just one small way. When creating a container, a client can now send the X-Storage-Policy header to set the policy for that container. The value of the header is the name of the storage policy. And the name of the available storage policies is available from the result of a call to the cluster’s /info endpoint.

Existing Swift clients will still completely work with this new version of Swift. If a client sends a container create request and doesn’t also explicitly send the X-Storage-Policy value, the new container will be created with the cluster’s default policy. This means that existing Swift client applications will not stop working, and aside from setting a policy on a container, will be able to still take advantage of all Swift has to offer.

Storage polices can only be set on a container at the time of container creation. If you need to change a policy, you first must delete all data in the container, delete the container, then recreate the container with the new storage policy. However, since Swift places no limits on how many containers you can have, it’s normally easier to simply create a new container.

Community Participation

Storage policies in Swift would not be possible without the participation of the entire contributing community. In particular, Paul Luse (Intel), Clay Gerrard (SwiftStack), and Sam Merritt (SwiftStack) have been instrumental by providing tremendous focus, dedication, awesome ideas, and leadership to getting this feature designed, written, and merged.

Together with Paul Luse, I gave a talk on storage policies at the OpenStack Juno summit in Atlanta. You can watch it here.

Looking Forward to Erasure Codes

We began working on storage policies in Swift almost exactly one year ago. Last July, we wrote about adding erasure code support to Swift. Erasure codes are great because for some data sets they can offer tremendous savings in storage media while still providing very high durability. But to add erasure code support into Swift, we first needed to add storage policies.

Now that storage policies are available in Swift 2.0, the developer community is refocusing on building the necessary pieces to support an erasure code storage policy in Swift. Policies are the foundation upon which we are building erasure code support into Swift, and this will be a major focus of the Swift contributor community for the remainder of this year.


Deploying Swift with SwiftStack

SwiftStack offers the easiest and fastest way to get up and running with a production Swift cluster. For more information on SwifStack, email [email protected], check out our online demo or signup for a personalized demo.

Wrapping up the Travel Support Program – Juno

The OpenStack Foundation brought 21 people to Atlanta for the Summit in May, thanks to the grants offered by the Travel Support Program, sponsored by VMware. The Travel Support Program is based on the promise of Open Design and its aim is to facilitate participation of key contributors to the OpenStack Design Summit. The program aims at covering costs for travel and accommodation for key contributors to the OpenStack project to join the community at the Summits.

We had 21 people accepted in the program from 8 countries and all around the world. Five people traveled from India, seven from Europe, three from Africa and the rest were from North America and South-East Asia. Of the selected recipients, two were unable to attend due to VISA timing issues, but we were excited to welcome the 21 attendees who were able to make the trip.


The Foundation spent a total of $33,376 for flights and $7,751 for flights for a total cost for the Foundation of more than $40,000 USD including the costs of 10 access passes granted to non-ATCs (Active Technical Contributors).

The Travel Support Application for the November Summit in Paris is NOW OPEN! You can apply for the Travel Support Program, including costs for travel and accommodation.

The final deadline to submit applications is August 18th, so apply now!


OpenStack Community Weekly Newsletter (June 27 – July 4)

OpenStack Turns 4 – It’s Time to Celebrate the Community!

OpenStack celebrates its 4th birthday July 19, and we’re celebrating with the entire OpenStack community during July!  User maturity, software maturity and a focus on cloud software operations are rapidly emerging for OpenStack and none of it would be possible without the quickly growing OpenStack community. There are now more than 70 global user groups and 17,000 community members across 139 countries, spanning more than 370 organizations. This calls for a big toast to the OpenStack community members and our users.

OpenStack Technical Committee Update (July 1)

This week the TC held a special meeting entirely focused on clarifying some points around DefCore and providing some responses to the questions DefCore posed to the TC. A must-read.

We need to start uncovering OpenStack’s Hidden Influencers

After the summit (#afterstack), a few people compared notes and found a common theme in an under served but critical part of the OpenStack community. Sean Roberts, Allison Randall, and Rob Hirschfeld are expanding the discussion to the broader community in a series of blog posts.

Call for Speakers now OPEN – November Summit in Paris

The Call for Speakers is OPEN for the November OpenStack Summit in Paris! Submit your talks here: submit your talks now. Don’t wait! The Call for Speakers will close on July 28 at 11:59pm CDT.

Reports from Previous Events

Security Advisories and Notices

Tips ‘n Tricks

Upcoming Events

Other News

Got Answers?

Ask OpenStack is the go-to destination for OpenStack users. Interesting questions waiting for answers:

Welcome New Reviewers and Developers

Jeegn Chen Richard Jones
Ciaran O Tuathail Mateusz Blaszkowski
Amit Prakash Pandey EliQiao
Melissa Wong warewang
Gael Chamoulaud Rakesh H S
François Magimel Maurice Leeflang
Tomáš Nováčik Markus Zoeller
Theron Voran Christopher Dearborn
Suthan Venkataramanaiah joanne
Jason Baker Tardis Xu
Harry Rybacki Rui Zang
Anthony Lee Ivo Vasev
Angela Smith Ian Cordasco
Anastasia Martynova stephen
Rikimaru Honjo
Alexander Maretskiy
Alex Weeks
Tim Hinrichs
Mike Bayer
Julia Kreger

Latest Activity In Projects

Do you want to see at a glance the bugs filed and solved this week? Latest patches submitted for review? Check out the individual project pages on OpenStack Activity Board – Insights.

OpenStack Reactions


Getting nitpicked on code reviews

The weekly newsletter is a way for the community to learn about all the various activities occurring on a weekly basis. If you would like to add content to a weekly update or have an idea about this newsletter, please leave a comment.


Open Mic Spotlight: Claudiu Belu

claudiu_openstackThis post is part of the OpenStack Open Mic series to spotlight the people who have helped make OpenStack successful. Each week, a new contributor will step up to the mic and answer five questions about OpenStack, cloud, careers and what they do for fun. If you’re interested in being featured, please choose five questions from this form and submit!

Claudiu Belu is 23 years old, and a cloud engineer at Cloudbase Solutions. Currently living in Timișoara, Romania, he’s generally a curious person, trying to expand his knowledge and experience as much as he can making use of them on the job, contests or other personal projects. Looking for something new and challenging, he had his first contact with OpenStack about one year ago. The way the community was working on bringing it to new heights and their dedication got his attention and he wanted to bring his skills to the mix as well. Follow him on Twitter @ClaudiuBelu

1. How would you explain your job to your grandmother?

What am I doing at my job?

Well grandma, basically, I’m helping by expanding this new resource called “The Cloud”, by adding and integrating new parts and features to it, making it bigger, work better and be of more use to people. 

What? No grandma,it’s not going to help your crops by making it rain more often.

Then what does it do?

Well, it can do a lot of things, almost anything anyone can imagine and need, from data processing and/or mining to offering complex services over the internet.

2. Get creative — create an original OpenStack gif or haiku!

An OpenStack core reviewer’s daughter goes to her father and asks:
Daughter: Dad, could I go out tonight with my friends to a party? Mom told me to ask you.
Core reviewer: Hmmm… +2‏

3. What new OpenStack projects do you think will have a significant impact on the cloud market in the next year?

Ease of deployment is going to be key for wide adoption in the enterprise world. In this sense, I believe that our work at Cloudbase in integrating our Windows based components with Ubuntu Juju and MaaS will bring a great value to the OpenStack ecosystem.

4. How did you learn to code? Are you self-taught or did you learn in college? On-the-job?

I first started in highschool with Adobe Flash’s ActionScript, but nothing serious. I only took programming more seriously in college, developing my skills and knowledge at an exponential rate through many ways. Those main ways are: mandatory group projects, IT-related conferences and meetups, internships and trainings, and courses, coding contests, being a trainer myself and of course, through work experience.

What really captivated me about programming is that you basically have a personal butler doing whatever you want and coding was the way to tell it what to do. :)

5. What does “open source” mean to you?

Open source is a great way to share your ideas and contribute to other great ones. By doing so, you can achieve so much more as a large, open group rather than a small one or even alone.
I think what makes open source so great is that anyone can get involved and also the people that get involved are really interested in the projects and their contribution far outweighs the work done in a normal corporation.


OpenStack Technical Committee Update (July 1)

The last TC update discussed the DefCore effort being led by the OpenStack Foundation Board. The DefCore subcommittee had made some requests for input from the TC. This week we held a special meeting entirely focused on clarifying some points around DefCore and providing some responses to the questions given to us.

It’s also worth noting that prior to the meeting, Jonathan Bryce posted a very comprehensive review of the existing framework that governs OpenStack trademark usage. This thread is absolutely worth reading for a good understanding of this topic.

Scope of DefCore

The first point on the agenda was to clarify the scope of DefCore. Specifically, we wanted to clarify which uses of the trademark this effort was applicable to. There were some important points of clarification reached during the meeting on this topic. DefCore is only about the commercial uses of the trademark. Currently, this only includes the “Powered by OpenStack” trademark license program. We also understand that the board has left open the option of an “OpenStack Compatible” trademark program in the future that may have a different set of requirements than what we are discussing right now.

Jonathan clarified this very well during the meeting (at 20:25:56):

The license agreement in question is called OpenStack Powered and is intended for use with products and services that are built using OpenStack software. for instance a public cloud “FooTron Compute Powered By OpenStack”, an appliance “FooTron Appliance Powered by OpenStack”, a distribution “FooTron OpenStack”. All of those different products would be held to the same standard. in other words, they would all be required to expose the same capabilities (testable over the APIs) and include the same actual community-developed software bits (designated sections).

DefCore Capabilities

The DefCore subcommittee has been working to define a set of capabilities with associated tests that would be used as a part of the process to determine if a given OpenStack product or service was allowed to use the OpenStack mark under the “Powered by OpenStack” trademark program. They have been using a scoring system to determine which capabilities should be required. Part of the input into this scoring is “technical direction”. They do not want to include a required capability that the technical community does not view as something we want to keep around long term. The TC was asked to provide input on some capabilities where the future was unclear. We have been working on clarifying all of these points in two reviews to the OpenStack technical governance repository. We are close to reaching a final conclusion on these points.

DefCore capabilities are currently defined in a JSON file as a mapping to a set of tests. One recommendation that the TC provided was that a 1 or 2 sentence description for each capability would help provide easier understanding of the intended coverage of a capability. Otherwise, interested parties must go read each test to understand exactly what it’s attempting to verify. While this would be helpful, we all agreed that this does not actually block progress. It would just make things easier.

The final point discussed in this section of the meeting was the intersection of capabilities and designated sections of code. Generally you have to implement designated section code and deliver core capabilities, but it was clarified that designated sections of code would only be required if there is a corresponding capability that is deemed required. If a project has no required capabilities, then the use or distribution of that project is not required.

Designated Sections

This was the most controversial part of the meeting. The DefCore committee had requested that the TC provide a proposed set of designated sections of code. This input would then be used as the basis for what code is required under the “Powered by OpenStack” trademark license program. After much discussion, the TC was able to reach consensus on this topic and a response was provided in this meeting.

One of the primary responsibilities of the TC is to define the OpenStack integrated release which is released every 6 months. This is the set of things that we vouch for. We have a defined process with a set of requirements projects must satisfy to apply for incubation and potentially eventually graduate to be a part of this integrated release. Defining a subset of the integrated release would make the TC appear to endorse or encourage replacing part of their work with proprietary alternatives. The TC is an elected representation of the contributors to the project and as such it does not feel it should declare a subset of the integrated release less important than the rest.

We do value that the Apache license provides the option of replacing part of the code with alternative solutions, and we respect that it’s the board prerogatives to determine trademark use policy. So we would like to clearly recognize that it’s the board’s right to define the subset of the integrated release required by commercial trademark license agreements (such as the “OpenStack Powered” trademark program), and therefore they should have final say on “designated sections”. A process to achieve that was suggested by Mark McLoughlin on the Defcore list, where the Board would propose designated sections and ask the wider community for comments on it, then make the final calls based on that feedback.


OpenStack – A Global Perspective: Five Things we Learned at OpenStack Events Across Europe and Israel

We say the words “global community” and “collaboration” so often they can start to lose their meaning. It’s easy to lose sight of the bigger picture, and the scale of our community far beyond name-brand users from the US or the number of Summit attendees. A few weeks ago, members of the OpenStack community organized a series of events across Europe and Israel, including Budapest, Paris, Milan, Tel-Aviv and London.I was fortunate enough to attend several events, and my goals were two-fold: to do some learning as we prepare for the November Summit in Paris, including getting a pulse on the issues and topics resonating most in the region and identifying new users we could feature; and second, of course, to start promoting the Paris Summit (shameless plug, happening November 3-7) by getting sponsors, press and potential attendees on board.


But what I really took away from the trip was a reminder that our greatest strength truly is the diversity and size of our global community. They aren’t just words that we throw around, but the hundreds of people we met and stories we heard in just a few short days. Reflecting on my conversations and a few interviews with the user group leaders, I wanted to pass along my five takeaways from the trip:

Businesses everywhere just want to move faster. Full disclosure, my original plan for this blog post was to interview the user group leader at each event and ask about the unique drivers in their region for OpenStack (or cloud and general). I suppose I shouldn’t have been surprised when they gave me essentially the same answers. The themes we discussed at the Atlanta Summit, including the Software-Defined Economy and needing to move faster than emerging competitors, resonated with everyone (unprompted!). Sure, there may be different regulatory environments or more financial services organizations in the UK and startups in Budapest, but at the end of the day they still want the same thing: the speed and agility to compete. The beauty of OpenStack is that there are many different ways to consume it, whether you’re a small business in Italy using Enter’s public cloud services, or building scale-out infrastructure for researchers to store and analyze data at CERN in Switzerland.

One of those user group leaders was Mariano Cunetti of Enter IT, based in Milan. According to Mariano, “the idea of team and company is changing. It has not been a painless process, but moving to the cloud is not only a matter of infrastructure. It’s not just a matter of how you develop your tools, it’s changing your processes. It’s being more agile and quick. In the next few years, the difference between companies adopting cloud compared to the ones who are not adopting cloud will be the difference of surviving and not.  Time to market will be so fast, that you need to keep the pace. You choose the pace you want to run to.”


Data sovereignty and national services create a different landscape in Europe, especially in industries like telco. I am familiar with the concept of data sovereignty and implications for our users, but one interesting thing we learned on the trip is that likely this year an update is coming to the EU-wide Data Protection Act Directive established in 1995. The new regulation, called the General Data Protection Regulation, is expected to take into account globalization and technological developments like cloud computing. As I mentioned, we’ve been talking about data sovereignty for some time — and it’s been a pretty significant driver of adoption among mid-size service providers across Europe and Australia — but debate and discussion around the new EU regulations, as well as court cases like Microsoft’s Dublin datacenter will be very timely for the OpenStack Summit in Paris, where we expect to discuss such issues with leading telcos, enterprises and technology vendors.


We’ve moved from “what” to “how.” Attending many of these same events a year ago, what really struck me is how the conversation has changed in tone. We’ve moved beyond the question of “what is OpenStack?” or “why OpenStack” to how it’s being used and more advanced topics. Attendees seemed eager for more technical deep dives and workshops. At the Paris event, Andrew Mitry from Comcast presented their user story, and had the most engagement and questions from audience members who were planning or operating their own deployments. In a short video interview, Nati Shalom, CTO of GigaSpaces and organizer of the OpenStack Israel Day, said: “When they were getting started, there was a lot of questions about whether OpenStack was the right thing. Is it going to happen? Is it going to be successful? Is it something that I should bet on? Even until last year that was the main discussion, but this year it’s more about how do I get started, how do I actually implement things, and how do I move fast with OpenStack.”

Budapest Check-in_2

Márton Kiss, who co-organized OpenStack CEE Day in Budapest, told me, “the major driving force behind this interest is that people started to trust the open source technology. The startups are definitive end-users of cloud technology, they know and use agile development, continuous integration / deployment, the entire devops culture, and OpenStack fits here as an alternative platform to Amazon. Larger enterprises here still have a conservative attitude, but telecom and financial sector are doing pilot projects. The structure of enterprises is a bit different in this Eastern European region, because most companies don’t have HQs here, but there are a lot of software development / technology center located here.”


Contribution pays off. One of the most exciting things to see is the companies who have been contributing — both code and community activities like organizing these events — have been making a name for themselves, and building their brand as OpenStack experts in the global community. They’ve gained knowledge and relationships that are translating into real business opportunities. We met some very large users who are choosing to work with smaller, focused companies in the OpenStack ecosystem because they know contributions equate to knowledge and influence. Companies who are consistently contributing are also openly attracting talent, because many of the OpenStack experts want to work in an environment where they know their efforts are going to have a broader impact. As one example, I was going to report on how impressive it has been to see eNovance grow and expand globally, because we had the chance to tour their new — OpenStack themed! — offices in Paris, but they’ve since been acquired!


Need more focus on operations and end users. This isn’t so much a lesson learned on this trip, as it was reinforced by these events. The makeup of attendees has evolved from primarily vendors looking to productize OpenStack and contributing developers to infrastructure teams within larger enterprises and research organizations who are using the software. The content has also evolved, but there’s more we can do to focus on cloud operators and app developers. One thought is for the Foundation to help recruit and sponsor more users like Andrew Mitry to travel and speak at these events, because hearing case studies and having the chance to ask/answer questions first hand is incredibly valuable.Please feel free to weigh in, whether or not you attended the events, I’d love to get your perspective.

Thank you to all of the organizers who put significant time into these events: Márton Kiss and Gergely Szalay in Budapest; Annie Potvin and the eNovance (now Red Hat) team in Paris; Martina Casani, Mariano Cunietti and the Enter team in Milan; Avner Algom, Nati Shalom, Sharone Zitzman and the GigaSpaces team in Tel-Aviv; and Mark Baker, Cezzaine Zaher and the Canonical team in London.

I’m energized as we head to Paris in November, and hope to see you there.

OpenStack Global Community: Interviews from OpenStack Days in Italy & Israel

Mariano Cunietti & Martina Casani, Enter IT

We recently had a chance to catch up with OpenStack community members Mariano Cunietti, CTO, and Martina Casani, Marketing Manager, at Enter IT.  Mariano got involved in OpenStack around the Folsom release and first attended the San Diego Summit in October 2012. He helped establish the Italy OpenStack User Group upon return from San Diego, which has since grown to more than 300 participants. They hosted the first OpenStack Day Italy at their offices in Milan, Italy, May 30th.Enter’s office space in Milan is truly unique. As part of the company’s process and culture transformation, and after touring several co-working spaces in the San Francisco / Bay Area, they decided last year to turn their own offices into a co-working space. Mariano explains in the video how co-working spaces are a great representation of cloud infrastructure physically, a true multi-tenant environment with shared infrastructure for the different teams and people they host. What you aren’t able to see in the video is that the office is entirely configurable and made of low-cost materials where possible. All of the desks are on wheels, and even the hanging outlets can be swung along tracks to different locations. They were easily able to clear out a large meeting space where they hosted more than 125 attendees for the OpenStack Day. And more important than the physical setup, the biggest benefit to them has been the exchange of ideas, meeting new and interesting people with which they are now collaborating, for example companies working in security, communications, drones and 3D printers.

Enter is an ISP funded in 1996 with expertise is datacenter services and connectivity. When it came to OpenStack, they were searching for a technology to bring their virtual private server product to market. Mariano says VPS is popular in the Italian market because 95% of companies are small businesses who don’t need large, scale-out architectures. Now with OpenStack, they have a real public cloud, Enter Cloud Suite, and are also actively pursuing hybrid cloud services so users can run OpenStack in house and then scale on the public service as they need. OpenStack is core to Enter’s infrastructure, and they are continuing to build a suite of services around it, such as hadoop, CDN and email.

Mariano says that engaging with the global OpenStack community dramatically changed the way Enter approaches work.  Where they used to wear suits, they are now more casual, and they’ve traded in tools like Microsoft Exchange for new ones. They have changed their internal processes, and are much smarter and more efficient than they were.  According to Mariano, “the idea of team and company is changing. It has not been a painless process, but moving to the cloud is not only a matter of infrastructure. It’s not just how you develop your tools, it’s changing your processes. It’s being more agile and quick. In the next year, the difference between companies adopting cloud compared to the ones who are not adopting cloud will be the difference of surviving and not.  Ttime to market will be so fast, that you need to keep the pace. You choose the pace you want to run to.”

Nati Shalom, CTO & Founder of GigaSpaces

Nati Shalom, CTO & Founder at GigaSpaces, got involved with OpenStack when the community was just being formed. He has since been instrumental in building the OpenStack user group in Israel, and we caught up with him at the 5th OpenStack Day Israel, June 2nd.  It was the biggest and most successful event the group has hosted yet with more than 500 attendees. The crowd is a mix of major users like LivePerson, technologists from global IT companies with R&D offices in Tel-Aviv and startups who are building web scale applications or products around OpenStack.

Over the past few years, Nati has seen a significant shift in the conversation at these events. Even last year, there were still questions about about whether OpenStack was the right thing. “Is it going to happen? Is it going to be successful? Is it something that I should bet on?” This year he’s seen it tip over to questions like “How do I get started? How do I actually implement things? How do I move faster with OpenStack?” That shift was also evident to him at the latest Summit in Atlanta. People are no longer standing at the fence and looking at how OpenStack is shaping up. They are moving to execution and sharing their user stories and best practices. It reminds Nati of the Java community 10 years ago, where a big, revolutionary shift in technology brings together business people, users and developers in a very collaborative fashion.

In this quick interview, Nati discusses the unique business landscape in Israel with an atmosphere of entrepreneurship. He calls Israel a startup nation. One reason being that Israel is small and there are not many natural resources, so the ability to export ideas and innovation is very important. There is a strong tech startup and R&D community that is always working on the next big thing, so emerging technologies are very well received. OpenStack plays well into the scene, and we met many Israeli companies like GigaSpaces, Mellanox, LivePerson and Cloudyn that are actively involved in the community.

One thing that Nati values highly is the transparency and availability of information from the community. We did not discuss it in this video, but during his presentation at the event, Nati talked about the differences between working in an open source community and with a proprietary software platform in terms of transparency and ability to influence the roadmap. He gave an example of the user survey conducted by the user committee every six months, the results of which are shared broadly with our technical community and ecosystem. The ability to have real data and insight into user adoption and tools being used has a huge impact on his product strategy. Proprietary vendors might push their partners in one direction based on their roadmap and plans, but they rarely expose the raw data required to make your own analysis.