Showing posts with label Summit. Show all posts

OpenStack Paris Summit Session Voting

We are down to the wire – last two days to vote for the sessions you would like see at the upcoming OpenStack Summit in Paris.

image

There are a large number of categories that you can choose from as you can see below:

categories

You will need an account to cast your vote.

It is quite interesting to see that some of the sessions are targeted at how you can migrate your workloads away from VMware and onto OpenStack, something that I think people will be looking into a lot more in the near future.

I also have a few sessions that you can cast your vote – if you so choose..

OpenStack Design Guide Panel

In July, 2014 The OpenStack Foundation brought twelve members of the OpenStack community together at VMware HQ in Palo Alto, California to produce the OpenStack Design Guide in just 5 days.  This panel brings many of these authors together for an open discussion about how to architecture an OpenStack cloud.

Bring your real-world questions and be prepared to talk OpenStack architecture with a panel of experts from across multiple disciplines and companies. We'll be drawing on real architecture and design problems taken from real-world experiences working with, and developing solutions, built on OpenStack. Following a brief introduction, panelists are ready to field questions from both the moderator and audience members and provide ongoing discussion the design process for architecting cloud solutions based on OpenStack.


Cisco's Media Solutions journey to the cloud with OpenStack

This session will go over how the Video Service provider group has added focus to deployment of its platform to support OpenStack. How this has evolved over the past year, the challenges that came up along the way and how these challenges were addressed - and solved.


Moving from a VMware Centric Architect to an OpenStack Architect

I have been designing VMware clouds and architectures for the past 4 years, and have now moved my focus to OpenStack. The change was not a simple one. There are terminology differences, architectural differences, differences in use cases. Differences in considerations regarding storage design, networking, automation, deployment - across almost every single aspect of the solution.

In this session you will learn what kind of change in mindset is needed, how to adapt to different architectural constraints, requirements and technical decisions.


Automated Deployment of OpenStack on Cisco UCS and Nexus

The Cisco OpenStack Installer provides automated deployment of OpenStack core components, as well as monitoring, storage, and high availability components. The release schedule of Cisco OSI parallels the community release. Where possible, Cisco OSI provides unmodified OpenStack code. Every new release of Cisco OSI follows the latest community stable release; however, in some cases Cisco might provide more recent patches that have been accepted into the OpenStack stable branches, but have not yet become part of an OpenStack stable release.

The Cisco OSI code update policy is to contribute code upstream to the OpenStack project and absorb patches into Cisco OpenStack Installer after they have been accepted upstream. Cisco deviates from this policy only when patches are unlikely to be reviewed and accepted upstream in time for a release or for a customer deadline (in such cases Cisco applies the patches to the repositories, submits them upstream, and replaces the local change with the upstream version when it is becomes accepted). Cisco also uses and contributes to modules from other upstream sources including Puppet Labs on StackForge.

In this hands on lab you will learn how to deploy OpenStack with the the Cisco OSI - knowledge that you will be able to take back with you to your organization and utilize for your own deployments.


Bringing Operators, Users and Developers closer together

This session proposal came as a result of a conversation on a blog post with Stefano Maffulli with regards to the acceptance of non-developers into the OpenStack world.

What tools are needed to interact with the developers - and the "developly challenged" people who are now starting to interact with wider OpenStack community. Because of the plethora of tools and the substantial on-ramp and learning curve in order to adapt - non-devs are finding it hard to contribute-voice their concerns or help.

This session will go over the tools used today, which tools should be used and when - and what we can expect in the future

Vote!

Remember – you are the one who decides what content you want to see – your vote counts!
Read More

OpenStack Summit - It’s all about the Developers

This one has been sitting in the drafts for a while.

What pushed me to publish and finish this post was an article posted by Brian Gracely,
Will Paris be the last OpenStack Summit?

The Openstack Summit is actually two separate tracks – one for users, and a second for developers. It is just by “chance” (not really) that they are held at the same location – at the same time – because they are catered for two very different audiences.

This is very apparent – even in the logo for the summits.

openstack-cloud-summit

It is even confusing sometimes in regards to what the name of the summit is? Will this be the Juno summit (if you ask an Operator/User – yes it will) or is it the Kilo summit (Developers with give you a thumbs up here).

How the event works?

5 days. the first 3 are the Main conference, and the last 4 is the Design Summit.

schedule

And of course from the mouth of babes..

The Design Summit sessions are collaborative working sessions where the community of OpenStack developers come together twice annually to discuss the requirements for the next software release and connect with other community members. It is not a classic track with speakers and presentations. (The Design Summit is not the right place to get started or learn the basics of OpenStack.)

Steve Ballmer – you remember him? He loved his developers….

Developers, Developers, Developers

The OpenStack Foundation treats the OpenStack Developers – differently. They are the people who create the product. Therefore they receive special treatment.

And by special treatment I mean:

  • The Design Summit is called a Summit, the rest of it is called the Main Conference
    (see above)
  • A completely different part of the conference only for developers – this includes:
    • Separate rooms
    • Separate schedule
    • Separate website for schedule
    • Separate submission process and voting for Design sessions
  • Constant refreshments and treats (M&M’s and Snicker bars galore, drinks, fruit)
  • Brainstorming area outside the discussion rooms
  • Multiple power outlets in every single room and everywhere
  • Every single ATC (Active Technical Contributor) receives a free pass to the summit.

    Individual Members who committed a change to a repository under any of the official OpenStack programs (as defined above) over the last two 6-month release cycles are automatically considered ATC.

Is this unfair – perhaps – but then again – these are the people who are creating the product – so it is in the Foundation’s best interest to keep them engaged, comfortable, happy and available to continue to contribute to the community and the products.

Back to Brian Gracely’s post. Because of the developers there will always be a OpenStack summit. Will it be the same as the past and upcoming summit – I do not know. But it is in the best interest of the Foundation to have the people developing the products, developing the projects to come together, talk, schmooze and also get the details hacked out of what will happen in the upcoming 6 months and the future directions of the product.

So in response to Brian – I still think that the Foundation will hold a summit – and it will always be its central event. The same way that all the major vendors have their own big Conference (Cisco Live, Redhat Summit, VMworld, etc.) every single year, but on the other hand they will make sure they have booths at all the other conferences as well (as a sponsor) it will be the same for OpenStack.

I think that the summit will continue to be here next year in 2015 and beyond.
Read More

Recording of my Presentation at OpenStack Israel 2014

Embedded below you can find the recording of my session
"OpenStack in the Enterprise - Are you Ready?"

You are welcome to go over the blog post I wrote about the event.

The full playlist of all the sessions can be viewed here

I have already submitted a few sessions for the upcoming summit in Paris.

Read More

Back from the OpenStack Cloud Summit

This is a re-post of my article, originally published on The Ravello Blog.

Last month I attended the OpenStack Cloud Summit in Atlanta. It was a very interesting experience. I learned a lot of things from the people there, from the organization, and how the OpenStack cloud community works.

Without a doubt, the people who are writing the code are extremely talented. They are doing unbelievable work writing things that make something out of nothing – with just a few lines of code transform your whole system into a cloud that allows you do a huge number of things. It is absolutely amazing.


Not just for developers

Unfortunately, they don’t always understand that clouds have not really been used or built only for developers to write the code or for users to consume the cloud resources. There is a need to recognize the existence of a third party in the equation – the people who operate and manage the cloud, including the infrastructure. As a result, there are issues that have not yet been addressed but need to be considered and integrated into the system.

An operator is not a developer, and a developer is not an operator. No matter how much people talk about DevOps, there is still some kind of disconnect between the two groups. I could see a huge difference between the two groups at the conference. I had expected to see a more integrated community and was surprised by the extent of the divide.

Enterprises are definitely looking to OpenStack for the purpose of deploying cloud infrastructure in their organizations. There are a number of very large providers that are looking to deploy OpenStack as a service that they will resell to customers. The majority of those looking to OpenStack are looking to use it to deploy their own internal clouds.


Obstacles to adoption


There are a number of obstacles that are slowing down the adoption of OpenStack cloud.

The upgrade process and migration process between versions is problematic, and any kind of change to the infrastructure affects the underlying workloads. One of the most frequently heard requests from the enterprise point of view is to make the upgrade possible with zero downtime for underlying workloads.
Yes, they have taken huge steps in that direction. But they aren’t there yet. It will take time. Until then people need to understand and make their decisions accordingly. The enterprise can build infrastructure and processes around these limitations, and the need to have downtime for upgrades, or wait until features are available in the regular code.

Another thing that I noticed is that there are a number of “distributions” of OpenStack. I don’t think the use of the term “distribution” is apt here. There is only one OpenStack software. Yes, you have Redhat, which deploys Redhat OpenStack one way, and Ubuntu, RackSpace and others that deploy OpenStack in other ways, but the software in essence is the same.

The software takes the same code from the OpenStack foundation. These are not different distributions, they are different deployment methods. Even in those cases where additional pieces are added to the system package, in essence the software is the same. The problem is that these distributed solutions are not interchangeable. The solutions can be good for one thing and not so great for another. You cannot easily mix and match solutions, particularly with different operating systems.

There are currently no simple solutions for backing up your OpenStack cloud. Some maintain that you don’t need to provide such a solution, but this is the kind of thing that the enterprise may want, or provide as an added benefit to their customers.


OpenStack as a disrupting technology


OpenStack is a disrupting technology. It is making people think differently and work differently. It is making IT work differently. One of the contentions raised at the Summit addressed the need to fix the features without disrupting things. For example, there are features with problems from four versions ago that have not been completely resolved. In the interim, there have been some 17 other products introduced into the OpenStack product and surrounding infrastructure. Meanwhile those original features have not been fixed. People want to see OpenStack fix what’s there before investing effort in making the product even brighter and shinier.


Emergence of OpenStack ecosystem


There is an ecosystem evolving around OpenStack. For now it is a very small ecosystem. For example, there are people who provide monitoring solutions or deployment solutions based on OpenStack. This ecosystem is limited, though I expect it to continue to grow. (The ecosystem around VMware, for example, is much larger. It includes security, compliance, replication, backup , disaster recovery, and automation solutions.)

I praise the OpenStack Foundation for trying to commit to providing better solutions for operators. A half day of sessions was devoted to topics of interest to operators. The ensuing discussions were enlightening. Not everybody agreed about everything. But in my opinion, this was definitely a step in the right direction. The Summit was a great learning experience for me, and would definitely plan to attend future OpenStack events.
Read More
Subscribe to: Posts (Atom)