<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Cloud Foundry on mcclain.sh</title><link>http://mcclain.sh/tags/cloud-foundry/</link><description>Recent content in Cloud Foundry on mcclain.sh</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 12 May 2014 00:00:00 +0000</lastBuildDate><atom:link href="http://mcclain.sh/tags/cloud-foundry/index.xml" rel="self" type="application/rss+xml"/><item><title>Hacking on Cloud Foundry's Gorouter</title><link>http://mcclain.sh/posts/hacking-on-cloud-foundrys-gorouter/</link><pubDate>Mon, 12 May 2014 00:00:00 +0000</pubDate><guid>http://mcclain.sh/posts/hacking-on-cloud-foundrys-gorouter/</guid><description>&lt;p&gt;Late last week, a couple colleagues and myself discovered a small bug in Cloud Foundry&amp;rsquo;s &lt;a href="https://github.com/cloudfoundry/gorouter" target="_blank" rel="noopener noreffer "&gt;gorouter&lt;/a&gt; in which a websocket upgrade was not completed if a comma-separated list of values in the Connection header was provided. A &lt;a href="https://github.com/cloudfoundry/gorouter/pull/39" target="_blank" rel="noopener noreffer "&gt;pull request&lt;/a&gt; was pieced together, submitted and is currently being looked at by Pivotal. However, I figured, why let the learning stop there?&lt;/p&gt;
&lt;p&gt;There were several things that I was unfamiliar with:&lt;/p&gt;</description></item><item><title>Cloud Foundry the API Way</title><link>http://mcclain.sh/posts/cloud-foundry-the-api-way/</link><pubDate>Thu, 05 Sep 2013 00:00:00 +0000</pubDate><guid>http://mcclain.sh/posts/cloud-foundry-the-api-way/</guid><description>&lt;p&gt;This is a topic I&amp;rsquo;ve seen come up a couple times in the last few weeks. It started with &lt;a href="https://twitter.com/drnic" target="_blank" rel="noopener noreffer "&gt;Dr. Nic Williams&lt;/a&gt; when we were discussing &lt;a href="https://github.com/cloudfoundry-community/share-my-cloudfoundry" target="_blank" rel="noopener noreffer "&gt;share-my-cloudfoundry&lt;/a&gt; when he wanted to provide compatibility with Cloud Foundry v1 and v2 in the same application. This situation came up again with a personal project that I will detail later.&lt;/p&gt;
&lt;p&gt;It required a bit of &lt;a href="https://groups.google.com/a/cloudfoundry.org/forum/?fromgroups#!topic/vcap-dev/5G3mWs2e0u4" target="_blank" rel="noopener noreffer "&gt;discussion&lt;/a&gt;, but I finally tracked down the answers. Although the &lt;a href="https://github.com/cloudfoundry/cfoundry" target="_blank" rel="noopener noreffer "&gt;cfoundry gem&lt;/a&gt; states that it is compatible with Cloud Foundry v1 and v2, after some digging, it looks like it&amp;rsquo;s only compatible with v2. To make things a bit more complicated, even though the old cfoundry library was moved to a separate repository, it retained the &amp;ldquo;cfoundry&amp;rdquo; gem name, meaning I could not include both gems in a single Gemfile.&lt;/p&gt;</description></item><item><title>Cloud Foundry v2: What's New?</title><link>http://mcclain.sh/posts/cloud-foundry-v2-whats-new/</link><pubDate>Fri, 14 Jun 2013 00:00:00 +0000</pubDate><guid>http://mcclain.sh/posts/cloud-foundry-v2-whats-new/</guid><description>&lt;p&gt;I&amp;rsquo;ve mentioned Cloud Foundry v2 a few times before (&lt;a href="http://mcclain.sh/posts/buildpacks-in-cloud-foundry-v2/" rel=""&gt;here&lt;/a&gt;, &lt;a href="http://mcclain.sh/posts/nise-bosh-a-new-way-to-bosh" rel=""&gt;here&lt;/a&gt;, &lt;a href="http://mcclain.sh/posts/introducing-nise-bosh-vagrant" rel=""&gt;and here&lt;/a&gt;), but I wanted to really get my hands dirty with the new bits and pieces before I wrote about it. &lt;a href="https://twitter.com/andypiper" target="_blank" rel="noopener noreffer "&gt;Andy Piper&lt;/a&gt; wrote about CFv2 a bit on his &lt;a href="http://andypiper.co.uk/2013/06/07/busy-times-but-lets-talk-cloud-foundry" target="_blank" rel="noopener noreffer "&gt;blog&lt;/a&gt;, in which he outlines the major features to users of CF. I wanted to dig a bit deeper into the major changes in some of the components that make up CFv2.&lt;/p&gt;</description></item><item><title>Buildpacks in Cloud Foundry v2</title><link>http://mcclain.sh/posts/buildpacks-in-cloud-foundry-v2/</link><pubDate>Thu, 16 May 2013 00:00:00 +0000</pubDate><guid>http://mcclain.sh/posts/buildpacks-in-cloud-foundry-v2/</guid><description>&lt;p&gt;NOTE: The referenced tweet has since been deleted&lt;/p&gt;
&lt;p&gt;The above tweet summarizes a very productive and exciting lunch I had today, in which after getting CF v2 working last night thanks to &lt;a href="https://github.com/nttlabs/nise_bosh" target="_blank" rel="noopener noreffer "&gt;nise_bosh&lt;/a&gt;, I started reading about buildpacks.&lt;/p&gt;
&lt;p&gt;To summarize buildpacks, taken straight from the &lt;a href="http://docs.cloudfoundry.com/docs/using/deploying-apps/custom/" target="_blank" rel="noopener noreffer "&gt;Cloud Foundry documentation&lt;/a&gt;&amp;hellip;&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;Buildpacks are a convenient way of packaging framework and/or runtime support for your application. For example, Cloud Foundry doesn&amp;rsquo;t support Django or Python by default. Using a buildpack for Python and Django would allow you to add support for these at the deployment stage.&lt;/p&gt;</description></item></channel></rss>