The Cloud Foundry Community Advisory Board started the session focussing on the Cloud Foundry Summit held in San Francisco earlier this month. Overall, the feedback about the conference was very positive. Cornelia Davis summed it up best, "The conference was really great...the energy was tremendous. The tidal wave that you could feel from the momentum around Cloud Foundry and the Cloud foundry community was palpable there." A big thank you to everyone who organized the event!
Other items discussed in the meeting included voting on various projects to be moved to/from the incubator, an update on the activities of the different open source project teams, Diego and the next Cloud Foundry release.
Cloud Foundry Summit 2014
The CAB meeting opened a discussion around the summit and in obtaining feedback about what could be improved for next next time. Overall, everyone felt that it was a great conference with more than 900 people in attendance over the three days. This was a bigger number than last year's and is a testament to the growing interest in the Cloud Foundry ecosystem.
While most liked the two track format, the general feedback was that the conference had too many keynotes. There was a conflict of promising sponsors a keynote, and then having so many sponsors. Suggestions for the next conference include converting some of the keynotes into lightning talks or having the sponsors present in one of the tracks.
The conference attracted people from a variety of roles - both technical and business. Each group wanted a bit more detail on their different perspective and would have liked to have more time to discuss issues relevant to them.
It was also suggested that an unconference should be included at the next Cloud Foundry Summit. Chris Ferris from IBM considered this to be the best part of the Cloud Foundry conference that was held in September 2013 because it allowed people to engage each other and have discussions on various topics related to Cloud Foundry. "There was just so much really good interaction in the unconference."
At the Cloud Foundry conference in 2013, a half-day was reserved for an unconference. These are events where you build agenda topics on-the-fly and then people pick which topic they want to discuss in more detail. They then go off into different rooms or areas in the venue to discuss them further. There were examples at the conference where the talks were great, but could have turned into more of a dialog and discussion in which members of the community could provide input on the topic. For example, there was a presentation on Diego that was awesome, but it created more questions. People would have benefited from having this breakout session where they could discuss the topic in more detail. "Unconferences are becoming the better part of conferences."
Cloud Foundry 101
It was also suggested that more beginner content could be included at Cloud Foundry Summit because there were a number of people who attended did not have extensive knowledge about Cloud Foundry. A suggestion was made to have a beginners day or a "Cloud Foundry 101" that would describe what it is and how it fits in an organization. These types of presentation are oftentimes held before the conference (e.g. bootcamp) so the conference then becomes more meaningful to these attendees.
Another suggestion was having an emcee for the tracks; someone neutral to let the speaker know that the session is running over the allotted time and they need to wrap up their presentation. At the Summit one track got very off schedule. Having an emcee would be helpful for the attendees who have scheduled their time to attend certain talks. It's important to keep things on time so they can see the sessions that they want.
In addition, another suggestion made was to have more transition time (5 or 10 minutes) between the tracks.
Cornelia Davis provided feedback on Hack Night. She felt that there was some confusion around Hack Night and the results were mixed. There were over 100 people, so it was difficult to organize that many in an ad hoc way. The biggest issue was that it needed more structure. There was an expectation that people would self-organize, and they would come with impassioned topics and want to hack on something in particular.
There were some logistical things that were problematic. While the stage worked in that it provided the opportunity for people to stand up and say "I'm going to show you how to do bosh-lite and then we'll meet at this table here," there were some issues in that there were too many discussions at the various tables. When the presenter was on stage it was difficult because so many other discussions were happening at the same time that it was challenging for the speaker and the audience.
One instance where Hack Night worked well was when Matthew Kocher from Pivotal moved over to a table after he spoke about bosh-lite and had about eight people who were working on getting bosh-lite installed. Unfortunately, this scenario didn't happen as much throughout the event. Despite the issues, the conclusion was to do Hack Night again, but with a more structured agenda. In the first hour there could be lightning talks that could be the basis for sub-sessions.. Maybe even doing a call for papers for Hack Night so there is enough structure. A suggestion was also made to utilize the Best Known Methods for hackathons to improve Hack Night at the next conference, and another suggestion was made to run Hack Day parallel to Cloud Foundry 101 presentations.
Organization Inside Venue
In the CAB meeting one final bit of feedback about the conference was the organization inside the venue with respect to the booths/food and keynote stage. Generally, people found that having the booths "open for business" during the keynotes were distracting. It was seen as inconsiderate for the speakers.There was agreement that the expo/food/conversations should be separate from the presentations.
The Next Cloud Foundry Summit?.
They would like the next summit to be hosted by the Cloud Foundry foundation. They will need to pick a time and venue, but it really depends on getting the foundation stood up by the end of the year and hiring an executive director. A vote in chat asked if they would like it be held outside of California next time.
Stark & Wayne has created TryCF. To use TryCF, users enter their AWS credentials and email address. In the background it spins up a worker and creates an all-in-one Cloud Foundry on their AWS account.
TryCF was developed because people wanted to try Cloud Foundry and stand it up on AWS, but they were having issues. TryCF was developed to address this problem. It is easy to install (15 min or less) and users will have an all-in-one Cloud Foundry box that they can play with and use the CLI to push to. It sends them their SSH key-pair that is generated so they can SSH into their instance. Now users can have a more detailed view of Cloud Foundry ("what's running on it, what are the subsystems, how is it put together, what is all this stuff."). They can start playing around with CF with low overhead to start, and on their own account nuke the VM when they are done.
They would like everyone to help spread the word of TryCF, so we get more adoption of Cloud Foundry. Adoption is faster when people can play with software. Typically if people start playing with it and can't get it up and running, they have a low tolerance and move on to doing other things. With TryCF the goal is that more people can get onboard and start using Cloud Foundry as fast as possible.. When trying to kick the tires and play, TryCF is a better option. The site uses bosh-lite's mcf and AWS AMI.
This is a great service and anyone who has tried it, should comment and let them know how great it was.
Voting on Projects
The CAB voted on a variety of projects to bring into the incubator or move to the core Cloud Foundry. The items included adding notifications, buildpacks and RiakCS.
Add Notifications to Incubator
Based on feedback from the community, the team would like to add a component to Cloud Foundry that allows other components of Cloud Foundry to send notifications to end users. It's slightly more complicated because Cloud Foundry has collective ownership. If you want to notify that the app is down or the service is not ready, it needs to notify a group of people (and this group changes dynamically over time). The proposal is to make a notification service with two simple API end-points that allow you effectively send an email to an end user or a space.
It would be a component of Cloud Foundry, but optional. The plan is to make it a simple open source implementation that just connects to emails (basically an email gateway). This will allow all of the components of Cloud Foundry--all open-source services, proprietary services, login servers, anyone who makes a GUI on top of Cloud Foundry--to notify users. Since all of these items need to send emails to users, it would be annoying to have to duplicate that work. There are already a couple of components sending emails differently from each other, so standardization makes sense.
They just have an API proposal, but people are ready to start working on this today. This is not actually a service in that you can't bind it to applications, but they might add a service broker later. The vote was YES and the project was moved to the incubator.
Move php and Python buildpacks From Incubator to Core
Both the php and Python buildpacks will be available in the Cloud Foundry release and they are available as offline buildpacks for anyone who may not have access to the internet. A vote was held, and these buildpacks will be promoted from the incubator to Cloud Foundry release.
Like the other buildpacks already in Cloud Foundry, these were started from a Heroku fork and have been used for while now. The buildpack team in NY has made them work offline and smoothed out the rough edges.The team has updated the buildpacks to work better on Cloud Foundry. People have been using these buildpacks as custom buildpacks for quite some time now.
A question about who will be maintaining these buildpacks came up. Currently they have two pairs working on buildpacks as long as there is work to move this project forward, but this probably won't be necessary forever. However, they will make sure that they are kept up to date.
Essentially, with these buildpacks, what's being asked is 'Should core Cloud Foundry support these languages easily or do users need to do an add-on to get this to work?' Wayne Seguin from Stark & Wayne felt that the more language buildpacks available in the core will enable more communities to use Cloud Foundry out-of-the-box with a smoother user experience.
Another vote was taken about moving the RiakCS service release into the Cloud Foundry core from the incubator. Almost everyone voted yes to move this from the incubator.
David Stevenson from Pivtoal stated that there are two kinds of important core services to any application--including Cloud Foundry itself--a blobstore and a database. The core Cloud Foundry should have a fully functional blobstore and a fully functional database as part of its open source package. The goal is to eventually use these services to actually host the core data of Cloud Foundry as well. Right now it is a PostgreSQL database, but the team would like to use MySQL and also potentially replace the NFS server with RiakCS. Once we know that RiakCS is going to be available as a service then we'll be able to store Cloud Foundry internal data with it as well. These changes were seen as a good architectural direction for Cloud Foundry to take.
Some reference links for RiakCS
Riak repositories: https://github.com/cloudfoundry-incubator?query=riak
Riak CS service broker https://github.com/cloudfoundry-incubator/cf-riak-cs-broker
Building and deploying the broker https://github.com/cloudfoundry-incubator/cf-riak-cs-release
Open Source Update
Buildpack team is in NY. As voted on earlier in the meeting, the PHP and Python buildpacks will be in the Cloud Foundry release and available as offline buildpacks. Cloud Foundry now has five buildpacks for offline availability and that is the first milestone for that team (reached earlier this week).
The services team has been very busy:
- RiakCS being promoted to Cloud Foundry (just voted on minutes ago)
- Recently wrapped up service usage events. A new endpoint on the Cloud Controller that operates a lot like app usage events. This functionality will hopefully be useful for those wanting usage metrics or billing around service usage.
- As well as the service API doc has been wrapped up. All services end-points are documented as well.
- Service audit events. From the CLI, the CF events command will show users audit events for services actions. If a user tries to create a service or bind a service, all of those will start showing up in CF events.
- A durable MySQL release. In its first wave, it will be just about durability, and then they will work on it being highly available (more than one node respond to the user request). This will be an update to dev MySQL that's already out there.
- Updating service plans. Trying to extend the services API to allow end users to change plans. It's an extension of the cloud controller api and service broker api.
The CLI team has been busy working on
- Application security groups. A new feature of Cloud Foundry to enable firewall rules per container via space or as a global default across the organization.
- Work for plug-in support for CLI that will be starting soon.
- Internationalization work is wrapped up and thanks to IBM for the help on that.
- For bosh, the team has been busy working on a Trusty Tahr (Ubuntu Server 14.04) stem cell. A number of teams out of SF are working on adopting that stem cell. Runtime hopefully will be getting to that stem cell in the short term.
- Wrapped up release versioning.
- Many of the products are now adopting the Go agent. There has been feedback going into the work that's been done.
Also focussing efforts on metric generation of the router. The runtime team will be pairing on this effort. Most of the work is complete and now it's just integration into the Cloud Foundry release. Runtime team is working on Trusty option for the stem cell, Go agent adoption, and about to restart OpenStack CI track so there is a CI environment to test all of the commits to Cloud Foundry release on OpenStack.
The Runtime team is working on application security groups. This is the new feature in which a CC operator can define at runtime a security group (looks like AWS/OpenStack security group). The security group allows the operator to allow traffic outbound from a container to different targets. It's possible to create a prod database application security group, assign it to the prod space, and only those with access to that space can get to that database at a network firewall level, not just permission to bind. As well as different types of constraints for dev and test.
Question was asked about when Diego would be ready. Hoping within the next 3 months, but not promising anything. And there were will be transition period encouraging people to move over. It will be opt-in, so people can choose to use it or not. The benchmark will be when they can stop all work on the old DEA code and rip out support for it from the Cloud Controller.
Matt will prepare a document about Diego for the next CAB call so that everyone has some release notes around it. There will be minor changes compared with the current runtime.. Buildpacks changing from git URLs. This will be easy for people to change and make implementation easier. The goal is to completely switch over, but they want to collect feedback on the things they are thinking of changing. Will have the old DEA and Diego running at the same time. They could delay Diego, but would rather get it out as soon as possible so everyone can start using it.
A comment was made about introducing too much change all at once. If there is a way to support forward compatibility then users could be prepared, backward compatibility is even better.
This will be discussed in the next CAB call. They are open to getting feedback and this is just more of a notice that it's coming.
Watch the Cloud Foundry Summit talk on Diego.
Next Cloud Foundry Release
ETA for next Cloud Foundry release: They have made a tremendous amount of progress on the Cloud Controller test and will post an update to the community. They have caught up on most of the pull requests against the cloud controller and as of last night pipeline was green. Looking to cut a release as soon as they can.
No release notes for v72/v173, but they are currently going to cut a v174 this week that will have release notes. v172/173 will be backfilled.
|This blog post was originally published by Kathy Thomas on June 26, 2014 at ActiveState blog.|