Earlier today the Cloud Foundry Advisory Board met to discuss the Cloud Foundry project. Attendees, in no particular order, were present from IBM, Altoros, Pivotal, ActiveState, CenturyLink/Tier3, Intel, Ubuntu, Cloud Credo, Stark & Wayne, NTT and Piston.
What follows is overview of the meeting, information that was shared and decisions that were made.
Agenda
Welcome - Chris Ferris
Agenda bashing - all
Update from Pivotal - James Bayer
Community Services - Catherine Spence
Incubator proposals - Chris & James
Diego - Mark Kropf
BOSH Stem cells - James Bayer
Setting fixed CAB schedule - Chris Ferris
cloudfoundry.org update - Chris Ferris
Other topics?
Business Time!
Chris Ferris kicked off the meeting with a run down of the agenda and a call out for attendees to raise any issues, mention things we would all like to be working on and for everyone to generally share ideas.
A New CLI Written In Go
There is a new command-line client, which is written in Go, called just “cli”. This is works on Windows, Mac and Linux as a simple binary executable.
Nic Williams (Dr Nic) mentioned the pain of getting customers to install the current Ruby “cf” command-line client with its dependencies and requiring Ruby to be on the system.
Loggregator
Logging is getting better in core Cloud Foundry due to loggregator. This creates a log stream to make one single source for all logs.
Starting and stopping of applications is now represented in the log stream.
All components should eventually support syslog draining. Currently all Cloud Foundry jobs support syslog draining by convention.
Health Manager 9000
Health Manager 9000 addresses the single-point-of-failure of the current Health Manager, if one availability zone goes down.
It was encouraged that everyone switch-over to this at some point in the near future.
The old Health Manager will be removed from Cloud Foundry release, since Health Manager 9000 is much easier to debug, troubleshoot and see what is happening.
DEA Zones
IBM have contributed code for DEA Zones. This is a rough equivalent of Amazon EC2 availability zones.
Elastic Runtimes
Another IBM pull request for “elastic runtimes”. This helps with buildpack management. It makes it easier to add buildpacks to the system and helps with the priority of buildpacks.
Usage Events For Apps
Usage events for applications have been added and there is a new API endpoint for it. This can be used for billing.
Service usage events have also been requested, but have not yet been implemented.
In fact, there are no major services updates.
BOSH Stemcells
There was talk of BOSH stemcells. Particularly CentOS and Redhat compatible BOSH stem cells, which are in development.
NTT and a University in China are collaborating on Apache CloudStack CPI (Cloud Provider Interface) for BOSH.
There is also a Google Compute Engine CPI prototype in the works that Pivotal has been experimenting with.
Generally Warden is the hardest part when developing stem cells for platforms such as CentOS. Matt Kocher noted that Warden on CentOS has been prototyped.
Trackers
New public trackers linked from the community wiki (see the right hand column under “Pivotal Trackers”).
There are links to CF Services, CF Java Buildpack and others.
Pivotal’s Dojo Program
IBM are sending people to Pivotal’s open dojo, which they have found to be a valuable experience.
Community Services
Catherine Spence from Intel did want to talk about community services, but unfortunately her microphone was not working. Chris was able to go over his understanding of the issues.
v1 community services have not been updated since the service broker API was updated in v2. These services moved from the Cloud Foundry core project into the community and are now getting "pretty stale". The question was what the plan was for these services now.
James Watters from Pivotal indicated that one service, MySQL, was chosen as the exemplar, but it was not feasible for them to keep all the services up to a good level of quality. He called for community support for these services moving forward.
David Stevenson from Pivotal said that, from a technical perspective, he would like to see each service in its own repository. Repositories with 50 services is too heavy.
There was discussion of setting up a separate GitHub org for services.
David suggested vendors, such as Basho with Riak, might write relevant services, in which case they will want to host their own services in their own organizations. Therefore, a wiki was decided as a better option, where all services can be brought together.
IBM said they do not want to have to burden developers with needing the full license (eg. MongoDB) for them to be able to work with services. “We should work together on this”.
On the point of whether open-source and commercial services should both be listed on the community wiki, Jeff Hobbs from ActiveState made the point that "It's very healthy for an ecosystem to show that it has that kind of a community".
Backups In v2 API
There was a question as to whether backups will be added to the v2 API? David Stevenson said that it is not currently, but it was designed to be added later. He is not sure when though.
Asynchronous Service Provisioning
Nic Williams asked when the next round of API updates for services will be?
David Stevenson said asynchronous provisioning for services is planned. This resolves problems with services that take longer than 60 seconds to provision.
SSO
David told us that SSO is coming up next for single sign-on via your GUI.
James Bayer, from Pivotal, said that Shannon Coen (their Product Manager for Services) is taking feedback from all the stakeholders.
People want backups. People want binding to services.
This is being discussed on the vcap-dev mailing list.
The Services tracker shows the priorities list for tasks related to services.
API Revisions
David Stevenson from Pivotal talked about “rev'ing the API”. We have already gone from 2.0 to 2.1. Asynchronous service provisioning will probably be 2.2 and 2.3 will probably be backups of services. This assumes that these things can actually be added.
David asked to let them know via the mailing list what you want next.
Multiple Service Nodes
There was a question about having multiple [MySQL] nodes for a single gateway.
There was doubts about how to implement multi-node brokers, due to the desire to keep the brokers stateless. It is not clear how to create multi-node brokers without them becoming stateful and it is not clear how to make a stateful broker where the storage system is reliable.
Eclipse Tooling
IBM and Pivotal has been talking offline about the Eclipse tooling. IBM is very integrated in the Eclipse community. Ryan Morgan, who manages the Eclipse tooling, talked about moving them from the Spring repositories into Cloud Foundry GitHub organization or the Cloud Foundry Incubator and relicensing them from Eclipse Public license to the Apache license.
.NET And IronFoundry Support
Brian Button from CenturyLink/Tier3 talked about .NET and IronFoundry support. How does .NET would fit in? He has talked with James Watters about Tier3 and Pivotal collaboration to get .NET support into Cloud Foundry?
Currently, it is not easy to change Cloud Foundry to run .NET apps. They need to sub-class some of the Cloud Foundry Ruby classes. This makes it very hard for the Iron Foundry project to keep up with changes Cloud Foundry.
They plan to break apart pieces of Cloud Foundry code to reduce constant breakage and make it a more manageable ongoing process.
Downstream Breakage
Need contracts in place for the API to that downstream extensions do not break with CF changes. eg. .NET and Docker
More knowledge via CI to know that upstream changes are breaking things downstream.
David:
Marco from Swisscom is interested in contributing a persistent filesystem service. Will need to be integrated with the DEA. He referred others that already do this with ssh-fs and fuse, of which Stackato is one.
The contracts mentioned above could also be applicable here.
Diego Project
Mark Kropf from Pivotal talked about a newly incubating project called Diego (pronounced "D.E.A.Go"). This is a rewrite of the DEA in Go.
Fixing the DEA code-base is currently very hard. The DEA is too broad in what it does and has become very complex over time. It needs to be easier to maintain the code-base.
This involves looking at the containers, DEA, the CC and the relation between them.
NATS usage is becoming unwieldy at scale.
Service Discovery With Etcd
Matthew Kocher from Pivotal interjected here to say that they are seeing a move towards a ZooKeeper / etcd model. This is because it gives a consistent picture of the world. NATS relies on "I'm still here, I'm still here, I'm still here".
The DEA will add "I'm running this app" to Etcd. If the DEA dies then timeouts will do clean-up.
More on Diego
Diego will be a big change. They are hoping to first replace staging with Diego in the new code-base.
Have talked a lot with Tier3 about to support Windows in Diego.
The team working on Diego are hoping to have something to show in 3 months, but say that it will not be done in 3 months.
Ubuntu BOSH Stem Cells
Matthew Kocher from Pivotal said that BOSH stem cells are in the backlog. No time-line. They are looking at jumping straight to 14.04 and skipping 12.04. Although some people in the community are working on 12.04.
Nic Williams asked if NTT’s 12.04 stem cell was available anywhere? Yudai from NTT said it was designed for working on CloudStack, but should work with OpenStack.
cloudfoundry.org update
Chris Ferris provided an update on the cloudfoundry.org website. The hope is that within a few weeks time a new structure will be in place that will allow for pull requests to be used to make modifications to the website.
Community Docs - Coming Soon!
Pivotal is currently working on what will be the community documentation in a private repository, but will publicly open up this repository to the community soon. It will be static pages with a little bit of styling.
BOSH World Domination
Nic Williams wanted to talk about “BOSH world domination!”.
Major news here was that BOSH has its own homepage.
Nic is planning an onboarding guide to BOSH via BOSH-lite.
The Vote
At the end there was a vote about the timing of future meetings. It was unanimous for last Wednesday of the month every month at 11am Eastern Time.
Conclusion
It was great meeting and we look forward to the next one on 26th February.