rbenv

So you need to develop in Ruby.

I am working now with a couple of different environment:
- ManageIQ needs Ruby 2.2.3
- Openshift.com, where I am developing an application (PaaS is nice), needs to use 2.0.0p645.

So I started to have a look at how is the best way to do it.  In RubyonRails.org it is recommended to use rbenv, so I did give it a try.

I followed the instructions to set up the environment, compiled a new ruby, installed it for my application... and did a bundler install.... "ERROR"

Those things of installing with git clone. Dependencies where not there. It took me a while to search the web and see that I need to install cmake, and some libraries for development that were needed to compile the gems (mariadb-devel, etc).

After that
$ gem update --system
$ gem update
$ gem pristine --all
$ gem install

And then
$sudo dnf install npm  #for node.js needed to run jscript and rails generate with it

made the day.

Second sprint

We have closed the second sprint.

Wow! Things are more complex than we expected. This sprint we have focused on upgrading what is already there:
 - Change how rates are defined. Now we can define a tariff in different units (i.e. 1€/KHz/month or 10€/MHz/month, etc)
- Tiered rates. Now we can define tiers for rating (1-2 CPU 5€/mont, 3-4 CPU 9€/mont, etc)
- Currency management, we have starting adding definition for currencies.

And then we came to Rails... Coding an enterprise grade application is complex, and there is a bunch of controllers that we need to understand... and we couldn't.

So we have closed the sprint a little too soon and we will need to continue working on this. We needed to take the decission of whether to delay the sprint for a week or close it as it is... and we decided to close it. No demo to be shown, a lot of things learned.

Now we need to define the next sprint.

Cloud

What is a cloud?

And can we make a cloud out of things that are not cloud-oriented? Short answer: it depends, but mostly the answer is no.

One shoud be aware of the definitions already there for the cloud. In particular, the National Institute of Standards and Technology (NIST), has released a definition of Cloud that is the basis for many other definitions and clarifications worldwide. The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls).

Five characteristics define a cloud:

• On demand self-service. .
• Broad network access.
• Resource pooling.
• Rapid elasticity.
• Measured service

Reference: http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf
 So the questions remains. Can I get a cloud with whatever infrastructure I have. And I believe the answer is twofold:

• Yes. As you can provide those characteristics with any virtualization, if you can provide Internet access and create and destroy VM automatically, based on measures. That is basically what many traditional virtualization are selling. "Use our virtualization with a management layer and you will get a cloud.
• No. A big no here. A cloud is about applications, not about infrastructure, so creating a management layer on top of your infrastructure will look like a cloud, will behave like a cloud, but won't be a cloud, because your application won't be cloud ready and you won't benefit from the new paradigms.

And that is what I believe is the big wrong thing on cloud. You should be expecting to have improvements because you use a cloud. Those improvements are both in performance, and in TCO for the solution, and in order to get them you need several things, all together:

1.  A management layer. Something that can provide and manage automatically, the generation and access to your workloads, both internally and externally, and provide measures and elasticity.
2. A lifecycle management tool. Because your workloads won't be static, you need to configure, update and depoly content to them.
3. A cloud workload. Elasticity comes with a price, you need to have VM that are ready to join a cluster of other VM, automatically. And that means changes in your development, getting away from HA to cluster-apps. Perhaps a PaaS.
4. An infrastructure that is aligned with the previous points.

The only thing is that you don't need to implement all of them at the same time. Of course you can get a "cloud" on any infrastructure, including physical and/or traditional virtualization, using traditional apps, and you will have most of the features defined by NIST. But you just miss many of the improvements of using a real cloud.

Because the value is in the application! So using a lifecycle management tool, or a management tool, will help you automate your workloads, and thus increase productivity and TCO - we have been doing that for years- but you won't be using a full cloud, because your application won't be there yet. PaaS, SaaS, are already helping you to go that way.

Just change the way you develop and deploy applications, over an infrastructure optimized for cloud, and then you will see the benefit. Increased utilization of hardware, rapid adaptation to the workloads, and thus CI/CD and everything that leads to innovation.

And of course, remember that we are not here to rebuild you datacenter tomorrow, so be prepared to have an hybrid cloud, with different workloads over different infrastructures, for many years.

So, coming back to earth: you really need OpenStack, and containers, and a Cloud Management Platform, and automation, but it is quite possible that the reasons you need them are not those that you are thinking of.

So let's not get confused. A Cloud Management Platform is a great tool, a needed tool, any automation is good, but be careful and know where your limits are.

And test, test, test, do proof of concepts, refactor, and test, test, test. You will need it.

Sprint 1

Sprint 1 is all about infrastructure (it will finish in two days time).

We have the laptops to program.
We are using a virtualization platform (Red Hat Enterprise Virtualization), ready to go.

Our environment is quite simple: a couple of hypervisors, connected to a synology NAS that provides NFS and iSCSI, with a self-hosted-engine manager.
We have created a group on github to hold the code and for ManageIQ.
https://github.com/rhus

What is needed to do the rest:

• A continous integration server. We have evaluated travis-ci, but the version for open source software works in a IaaS/PaaS mode. We need to be able to deploy inside our environment. It is a pity, because ManageIQ code already is prepared to use Travis and have the configuration working. We will need to go with another wide used tool like Jenkins
• We are using BDD/TDD, so we need a test bench. We are using Rspec, as it is integrated with Ruby, and it is the one chosen by ManageIQ.
• Did I mention github?

And we were so lucky to get some time of greggt, that allowed us to go through the code... amazing how a quick 60 minutes can reduce your self-study time several days.

Any ideas on how to solve the travis-ci issue? We don't want to reinvent the wheel.

This Friday, first demo day, and preparation for the sprint 2... where we actually will code. Exciting :D