summaryrefslogtreecommitdiff
path: root/src
diff options
context:
space:
mode:
authorMonty Taylor <mordred@inaugust.com>2015-08-01 02:11:52 +1000
committerMonty Taylor <mordred@inaugust.com>2015-08-01 02:11:52 +1000
commit23a91cae672fb9f8b208b474efbfa01bf5d66f26 (patch)
tree33ed93ea03dfdfd0875ea712b615d1522cbd5aca /src
parent69d66321015064c63ef6377ccff5f6d35560fb19 (diff)
Get blog posts on there
Diffstat (limited to 'src')
-rw-r--r--src/css/mordred.css55
-rw-r--r--src/index.hbs74
-rw-r--r--src/index.html79
-rw-r--r--src/posts/big-tent.html249
-rw-r--r--src/resume.html301
5 files changed, 679 insertions, 79 deletions
diff --git a/src/css/mordred.css b/src/css/mordred.css
index 23674ee..dc050c2 100644
--- a/src/css/mordred.css
+++ b/src/css/mordred.css
@@ -63,6 +63,17 @@ body {
63 margin-top: 28px; 63 margin-top: 28px;
64 } 64 }
65 65
66@media print {
67
68.footer {
69 display: none;
70}
71.breadcrumbs {
72 display: none;
73}
74
75}
76
66/* Responsive: Portrait tablets and up */ 77/* Responsive: Portrait tablets and up */
67@media screen and (min-width: 768px) { 78@media screen and (min-width: 768px) {
68 .container { 79 .container {
@@ -82,3 +93,47 @@ body {
82 margin-bottom: 10px; 93 margin-bottom: 10px;
83 } 94 }
84} 95}
96
97h3.resumesection {
98 background-color: #999999;
99 font-family: Geneva, Arial, Helvetica, sans-serif;
100 color: #FFFFFF;
101 font-size: 12px;
102 letter-spacing: 12px;
103 text-align: center;
104 margin-bottom: 6px;
105
106}
107.job ul li {
108 line-height: 12pt;
109
110 font-size: 10pt;
111}
112 #porthead {
113 padding-left: 8px;
114 padding-top: 6px;
115
116}
117.titletitle {
118 padding-left: 6px;
119}
120.techskills {
121 padding-left: 6px;
122 line-height: 10pt;
123 font-size: 12pt;
124}
125.job {
126 font-size:12pt;
127 padding-left: 6px;
128}
129.jobskillslist {
130 font-size: 6pt;
131 font-style: italic;
132 margin-top: -12px; padding-top: 0px;
133 margin-bottom: 10px;
134 margin-left: 10px;
135}
136
137.lead ul li {
138 display: inline;
139}
diff --git a/src/index.hbs b/src/index.hbs
new file mode 100644
index 0000000..2004305
--- /dev/null
+++ b/src/index.hbs
@@ -0,0 +1,74 @@
1<!doctype html>
2<html lang="en">
3
4<head>
5 <meta charset="utf-8">
6 <title>Monty Taylor</title>
7 <link rel="stylesheet"
8 href="/css/bootstrap.css">
9 <meta name="description"
10 content="{{author.name}}'s Website">
11 <meta name="author" content="{{author.name}}">
12 <meta name="viewport"
13 content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no, minimal-ui">
14</head>
15
16<body style="margin-top: 70px; margin-bottom: 70px">
17<nav class="navbar navbar-default navbar-fixed-top"
18 xmlns:dct="http://purl.org/dc/terms/"
19 href="http://purl.org/dc/dcmitype/InteractiveResource"
20 property="dct:title"
21 rel="dct:type">
22 <div class="container-fluid">
23 <span class="navbar-brand">Things you may or may not care or not care about.</span>
24 </div>
25</nav>
26<div class="container-fluid">
27 <div class="row">
28 <div class="col-xs-12">
29 <a href='talks'>Slides for Talks I've Given</a>
30 </div>
31 </div>
32 <div class="row">
33 <div class="col-xs-12">
34 <br/>
35 <table class="table table-striped table-hover">
36 <thead>
37 <tr>
38 <th>Post Title</th>
39 </tr>
40 </thead>
41 <tbody>
42 {{#each posts}}
43 <tr>
44 <td>
45 <a href="{{path}}" target="_blank">
46 {{title}}
47 </a>
48 </td>
49 </tr>
50 {{/each}}
51 </tbody>
52 </table>
53 </div>
54 </div>
55</div>
56<nav class="navbar navbar-default navbar-fixed-bottom">
57 <div class="container-fluid">
58 <p class="navbar-text">
59 <a rel="license" href="http://creativecommons.org/licenses/by/4.0/">
60 <img alt="Creative Commons License"
61 src="https://i.creativecommons.org/l/by/4.0/88x31.png"/>
62 </a>
63 This work by <span xmlns:cc="http://creativecommons.org/ns#"
64 property="cc:attributionName">{{author.name}}</span>
65 is licensed under a <a rel="license"
66 href="http://creativecommons.org/licenses/by/4.0/">Creative
67 Commons Attribution 4.0 International License</a>.
68 </p>
69 <br />
70 Website source code available at <a href='http://git.inaugust.com/cgit/inaugust.com'>http://git.inaugust.com/cgit/inaugust.com</a>
71 </div>
72</nav>
73</body>
74</html>
diff --git a/src/index.html b/src/index.html
deleted file mode 100644
index 340aab5..0000000
--- a/src/index.html
+++ /dev/null
@@ -1,79 +0,0 @@
1<!doctype html>
2<html class="no-js">
3 <head>
4 <meta charset="utf-8">
5 <title>In August Productions</title>
6 <meta name="description" content="">
7 <meta name="viewport" content="width=device-width">
8 <link rel="shortcut icon" href="/favicon.ico">
9 <link rel="stylesheet"
10 href="/css/bootstrap.css">
11 <link rel="stylesheet"
12 href="/css/modernizr.css">
13 <link rel="stylesheet"
14 href="/css/mordred.css">
15
16 </head>
17 <body>
18 <!--[if lt IE 10]>
19 <p class="browsehappy">You are using an <strong>outdated</strong> browser. Please <a href="http://browsehappy.com/">upgrade your browser</a> to improve your experience.</p>
20 <![endif]-->
21
22
23 <!--
24 <nav class="navbar navbar-inverse navbar-fixed-top">
25 <div class="container">
26 <div class="header">
27 <ul class="nav nav-pills pull-right">
28 <li class="active"><a href="/">Home</a></li>
29 </ul>
30 <h3 class="text-muted"><a href="/">inaugust.com</a></h3>
31 </div>
32 </div>
33 </nav>
34 -->
35
36 <!-- Main jumbotron for a primary marketing message or call to action -->
37 <div class="jumbotron"
38 xmlns:dct="http://purl.org/dc/terms/"
39 href="http://purl.org/dc/dcmitype/InteractiveResource"
40 property="dct:title"
41 rel="dct:type">
42 <div class="container">
43 <p class="lead">Things you may or may not care or not care about.</p>
44 </div>
45 </div>
46
47 <div class="container">
48 <div class="row">
49 <h3><a href='talks'>Slides for Talks I've Given</a></h3>
50 </div>
51 <div class="row">
52 <h3><a href='big-tent.html'>The Big Tent</a></h3>
53 </div>
54
55 <div class="footer">
56 <p>&copy;
57 <span xmlns:cc="http://creativecommons.org/ns#"
58 property="cc:attributionName">Monty Taylor</span>
59 2015
60 </p>
61
62 <a rel="license" href="http://creativecommons.org/licenses/by/4.0/">
63 <img alt="Creative Commons License"
64 style="border-width:0"
65 src="https://i.creativecommons.org/l/by/4.0/88x31.png" />
66 </a><br />
67 <a xmlns:cc="http://creativecommons.org/ns#"
68 rel="cc:attributionURL"
69 href='http://inaugust.com'>http://inaugust.com</a> is licensed under a
70 <a rel="license"
71 href="http://creativecommons.org/licenses/by/4.0/">
72 Creative Commons Attribution 4.0 International License
73 </a>.
74 <br />
75 Website source code available at <a href='https://github.com/emonty/inaugust.com'>https://github.com/emonty/inaugust.com</a>
76 </div>
77
78</body>
79</html>
diff --git a/src/posts/big-tent.html b/src/posts/big-tent.html
new file mode 100644
index 0000000..f45e5f9
--- /dev/null
+++ b/src/posts/big-tent.html
@@ -0,0 +1,249 @@
1<!doctype html>
2<html class="no-js">
3 <head>
4 <meta charset="utf-8">
5 <title>The Big Tent</title>
6 <link rel="stylesheet"
7 href="/css/bootstrap.css">
8 <meta name="author" content="{{author.name}}">
9 <meta name="viewport"
10 content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no, minimal-ui">
11 <meta name="description" content="OpenStack as Layers but also tents but also cats">
12 <meta name="viewport" content="width=device-width">
13 <link rel="shortcut icon" href="/favicon.ico">
14
15 </head>
16 <body>
17 <!--[if lt IE 10]>
18 <p class="browsehappy">You are using an <strong>outdated</strong> browser. Please <a href="http://browsehappy.com/">upgrade your browser</a> to improve your experience.</p>
19 <![endif]-->
20
21<nav class="navbar navbar-default navbar-fixed-top">
22 <div class="container-fluid">
23 <span class="navbar-brand"><a href="/">
24 Things you may or may not care or not care about.</a></span>
25 </div>
26</nav>
27
28 <!-- Main jumbotron for a primary marketing message or call to action -->
29 <div class="jumbotron">
30 <div class="container">
31 <h1>
32 <span xmlns:dct="http://purl.org/dc/terms/"
33 href="http://purl.org/dc/dcmitype/InteractiveResource"
34 property="dct:title"
35 rel="dct:type">
36 The Big Tent
37 </h1>
38 <p class="lead">OpenStack as Layers but also tents but also cats</p>
39 </div>
40 </div>
41
42 <div class="container">
43 <p>I'd like to build on the ideas in <a href="https://dague.net/2014/08/26/openstack-as-layers/">Sean's Layers</a>. I've been noodling on it for a while and have had a several interesting conversations with people. Before I tell you how I've taxonomied things in my head, I want to spend a second on why.</p>
44 <h3 id="why-do-we-care">Why do we care?</h3>
45 <p>Our choices in organizing our work effect a few different unrelated things:</p>
46 <ul>
47 <li>Who we are and what we all work on</li>
48 <li>What we release that we kinda expect people to ship</li>
49 <li>What an end user can count on</li>
50 <li>What an end user might find that would make life better for them</li>
51 </ul>
52 <p>Amazingly, we've been trying to define all of those with one word. I'm pretty sure that's bananas.</p>
53 <h3 id="who-cares">Who cares?</h3>
54 <p>As much as there are different reasons we care about this, there are different people who care about different aspects of the answer to this.</p>
55 <ul>
56 <li>OpenStack Developers - us, the people who actually hack on OpenStack itself</li>
57 <li>Distributors - people who redestribute packaged versions of OpenStack software</li>
58 <li>Deployers - people who deploy and run OpenStack Clouds</li>
59 <li>End users - people who use deployed OpenStack Clouds</li>
60 </ul>
61 <p>Even though I put &quot;end users&quot; last, I actually care about them a lot - but I'm going to speak to developers' concerns first, since that's who we all are.</p>
62 <h4 id="who-we-are-and-what-we-all-work-on">Who we are and what we all work on</h4>
63 <p>(This section is very OpenStack-developer centric. I cannot imagine that an end user or really even a deployer or distributor cares at all.)</p>
64 <p>Amongst other things, the OpenStack project is a community of people working on the common goal of &quot;Open Source Cloud&quot;. If you're one of us, you should be able to vote in our elections and you should absolutely be granted entry for free into our design summits or any other meetings we have. I say &quot;if you're one of us&quot; because the interaction, collaboration and participation aspects are important to us. It's a sliding scale, so you can definitely be more in or less in. Some examples of community that we care about: being on stackforge rather than github; having a PTL who you elect rather than a BDFL; having meetings on IRC. &quot;Do any of the people who hack on the project also hack on any other existing OpenStack projects, or are the people completely unconnected?&quot; is a potential social touchstone as well.</p>
65 <p>All in all, meeting the requirements for &quot;being one of us&quot; is not particularly hard, nor should it be. We're not aiming to keep people out, we're a big friendly tent, but there also exist in the world people of ill repute who are trying to sell snake oil and fool's gold. While we want to grow our culture, we also need some sort of way to define what that is and keep detractors out.</p>
66 <p>This is OpenStack as a big tent - we want you here - we just want to check at the door that you're being honest, as it were.</p>
67 <h4 id="what-we-release-that-we-kinda-expect-people-to-ship">What we release that we kinda expect people to ship</h4>
68 <p>(Distributors obviously care about this, as do deployers. End users, again, could not care less.)</p>
69 <p>Just because you're one of us doesn't mean that everything you do is something that might be included in a collection of software called &quot;OpenStack&quot;. I don't think it will be controversial to say that, CLEARLY, any work hacking on zuul is work that is part of our community, and also that CLEARLY zuul is not an element of the collection of software called &quot;OpenStack.&quot; I pick an obvious and non-controversial extreme example to show that I'm not splitting hairs.</p>
70 <p>Now, &quot;what is OpenStack&quot; is a much large question as trademarks and defcore get involved, and is not at all what I'm attempting to even think about - but from our point of view as the people who release things, we have a clear stake in putting our name on the software we release that we think has some quality of OpenStack-ness.</p>
71 <p>Inclusion in this can actually have both positive and negative responses from folks that aren't us. &quot;Oh cool! OpenStack has DNS now!&quot; and &quot;Oh crap! I had a thing that did DNS and now OpenStack has one!&quot; are both are valid emotions. Nothing I can say here will prevent or invalidate some people having each of those emotions for each new thing we add to OpenStack.</p>
72 <p>There is another aspect, which Tim Bell brings up frequently: quality. Our current systems tells you only that a project has been integrated with our development and release cycle. It does NOT tell you in any way if that project is any good.</p>
73 <h4 id="what-an-end-user-can-count-on">What an end user can count on</h4>
74 <p>(This is the first time we find a subject an end user cares about.)</p>
75 <p>There is a set of things which OpenStack just has to have, or else calling that thing &quot;OpenStack&quot; is just being silly. Branding and trademark and product discussions aside, there is, deep down, some set of things without which the cloud in question is absurdly useless.</p>
76 <p>This is also important because it shapes how much logic and discovery an end user has to have in order to accomplish their task.</p>
77 <h4 id="what-an-end-user-might-find-that-would-make-life-better-for-them">What an end user might find that would make life better for them</h4>
78 <p>As an end user, I can tell you that, crazy as it might sound, I have the ability to look at things and make some decisions. I know, as a user, if there is a feature in my cloud, and I can choose to use it or not. If I'm an advanced user like Infra spanning multiple clouds, I might care immensely if a feature is ubiquitous. But for other users, using an advanced thing might be awesome and ubiquity is not interesting.</p>
79 <h3 id="base-level-touchstone">Base Level Touchstone</h3>
80 <p>&quot;Can an end user actually get a working VM without function X?&quot;</p>
81 <p>Let's go back to the layers. I think the idea is great, and I'm going to quibble mildly with one or two of the assumptions and then propose a slightly different model.</p>
82 <p>I think Sean is right, for better or for worse, that starting with basic compute as a building block is spot on. I disagree though about stateless compute - but I think that's because I'm looking at this question from an end user POV, not a deployer POV. I'm sure that many deployers start very small with a stateless compute cloud. But as an end user, &quot;basic cloud == minimal stateless compute&quot; falls down for 2 reasons:</p>
83 <ul>
84 <li>To run a thing on a stateless compute cloud, you actually MUST have the more advanced services. This is kinda the whole point behind Cloud Foundry, right? Stateless compute, PLUS, some way of putting your databases and object storage in the cloud so that it's not on the compute instance yourself.</li>
85 <li>The first step in the &quot;Cloud Journey&quot; is not &quot;Cloud Native&quot; - it's running traditional applications in the cloud. Infra started out this way, even though now we've got some crazy completely elastic driven-by-load-demand cloud applications - for the first year of OpenStack, everything ran on one single Jenkins server on one cloud instance and kept its data in local storage.</li>
86 </ul>
87 <p>I'd like to keep Layer #1 as &quot;Base Compute Infrastructure&quot; - but I'd like to suggest that we define it with two touchstones in mind:</p>
88 <ul>
89 <li>What does a basic end user need to get a compute resource that works and seems like a computer? (end user facet)</li>
90 <li>What does Nova need to count on existing so that it can provide that.</li>
91 </ul>
92 <p>(Here is where we get to the first real concrete suggestion.)</p>
93 <p>For those reasons, I think the set is:</p>
94 <ul>
95 <li>Nova</li>
96 <li>Glance</li>
97 <li>Keystone</li>
98 <li>Cinder</li>
99 <li>Designate</li>
100 <li>and we want Neutron to be here</li>
101 <li>and all the common libraries (Oslo and otherwise) that are necessary for these</li>
102 </ul>
103 <p>For each of those things, Nova does not or will not have an internal replacement for the functionality. Nova REQUIRES that Glance exist to get images to deploy. Nova REQUIRES that Cinder exists to provide persistent disk volumes. Nova REQUIRES that Keystone exist for auth. And Nova REQUIRES that oslo.config exist to read its config file.</p>
104 <p>We gate these things together. If they don't work together, we should all go home. We also gate with tip of master vs. tip of master because we release these at the same time. Nova also REQUIRES a database and a message queue -but we don't need to gate on their master branches because we expect to consume releases of that external software. But Nova cannot consume releases of Cinder, because we also make Cinder, and we're going to release it at the same time.</p>
105 <p>These are also sevices that a user cannot reasonably provide for themselves within the cloud on a more pared down version of this list. A user can't provide their own reverse DNS because they don't own the IP space. A user can't provide their own network or storage, well, for all of the reasons.</p>
106 <p>And to build them, we rely on a set of shared libraries which grew over time from the a bunch of developers working on a bunch of projects together. We release these separately so that all our projects (not just the ones in Layer #1) can depend upon the same versions of things. This makes distributors and deployers happy, even if occasionally it makes life harder for developers.</p>
107 <h3 id="ubiquitous-wordpress-example">Ubiquitous Wordpress Example</h3>
108 <p>Every config management or orchestration example starts with a Wordpress example, so let's walk through that as a proof point of the above (assuming I don't want to rewrite wordpress to be an OpenStack-Native application).</p>
109 <p>Let's say I want to start a new blog, <a href="http://blog.inaugust.com">http://blog.inaugust.com</a>. In general terms, I need a computer to run it on, an operating system on that computer, some disk space that doesn't go away so that my beautiful blog entries don't disappear, an IP address so that you can connect to my blog, and a DNS entry so that you don't have to type in my IP address to see my blog. Finally, I need to be able to connect to my cloud and tell it I need those things.</p>
110 <p>What does that look like?:</p>
111 <pre><code>nova boot --flavor=&#39;2G&#39; \ # gets auth token and Nova url from Keystone
112 --image=&#39;Gentoo&#39; # Nova talks to Glance to get this
113cinder give-me-a-10G-volume
114nova attach-that-volume-to-my-computer # nova talks to cinder
115neutron give-me-an-ip
116nova attach-that-floating-ip-to-my-computer # nova talks to neutron
117designate call-that-ip &#39;blog.inaugust.com&#39; --also-reverse-dns-kthxbai # designate talks to neutron
118
119# Log in to host and actually install wordpress</code></pre>
120 <p>If any of those services are missing, I can't make a wordpress blog. If they are all there, I can. If you use juju or cloudfoundry or ansible to make a Wordpress blog, they are the ones responsible for doing all the steps for you. They may do them slightly fancier.</p>
121 <p>Also, please someone notice that the above is too many steps and should be:</p>
122 <pre><code>openstack boot gentoo on-a 2G-VM with-a publicIP with-a 10G-volume call-it blog.inaugust.com</code></pre>
123 <h4 id="concrete-suggestion-1">Concrete Suggestion #1</h4>
124 <p>Shrink the integrated gate and release to this and call it &quot;Layer #1&quot;</p>
125 <p>We need to test these things together because they make assumptions that the other pieces exist. Also, the set of things in Layer #1 should never change -- unless we refactor something already in Layer #1 into a new project. (You may notice that all of these projects were originally part of Nova.)</p>
126 <p>Once Designate is in, that's quite literally all of the things you need for a functioning VM.</p>
127 <p>We can call Layer #1 something else, but all the good names are overloaded and will cause us to have two years of arguments quibbling over the implications of wording choices.</p>
128 <h4 id="concrete-suggestion-2">Concrete Suggestion #2</h4>
129 <p>Make Layer #1 assume the rest of Layer #1 will always be there</p>
130 <p>Inside of these pieces of software, assumptions should be able to be made about the co-existence of the other pieces of software. Example - nova shouldn't need a config file option pointing to where glance is, it should just be able to ask the keystone service catalog.</p>
131 <h3 id="next-layers-up">Next layers up</h3>
132 <p>There are no next layers up</p>
133 <p>I think Layer #1 should be the only layer, because after that the metaphor of layers falls apart. Instead, let's talk about some groupings of stuff, as they relate to different end user categories.</p>
134 <p>There are &quot;Cloud Native&quot; applications, there are &quot;User Interface&quot; applications, and there are &quot;Operator&quot; applications. All of these fit into the tent, and some of them may have dependencies on others -- but they ALL depend on Layer #1 being there and being stable.</p>
135 <p>Also, all of this falls under the umbrella of &quot;work done on the OpenStack project.&quot;</p>
136 <p>It is entirely possible that in the future someone might describe a user story that involves some combination of Layer #1 and some of the Cloud Native applications as being something we need to have a name for. Today we have this, we know that we need it, and there are almost no people who would argue that clouds don't need to provide the functionality.</p>
137 <h3 id="features-for-cloud-native-applications">Features for Cloud-Native Applications</h3>
138 <p>OpenStack already has a bunch of services that provide features for end user applications which could be provided by services run within VMs instead. These are the services that get controversial because some people feel they cross various boundaries.</p>
139 <p>Whereas Layer #1 provides services that can be quite happily used and consumed by a traditional IT Ops person (how infra used cloud for at least the first two years), there are additional services that many people believe are <em>essential</em> in a cloud for people to write &quot;Cloud&quot; apps, but also other people <em>vehemently</em> believe are stepping over a line and do not want in a cloud. Let's look at two real world examples from Infra about the &quot;Cloud Journey&quot; and how our apps transformed from more traditional IT to more &quot;Cloud Native&quot;.</p>
140 <h4 id="tranformation-1---the-adoption-of-trove">Tranformation #1 - The Adoption of Trove</h4>
141 <p>Up until earlier this year, all of the services that Infra runs that rely on databases just ran a database locally on the compute instance they ran on. This, it turns out, worked fine - and we never had an outage of any sort due to any related cloud issues. We did take backups and do the normal things that normal Ops folks do.</p>
142 <p>Earlier this year, we migrated most of them to consume databases provided to us by a trove installation that was availabe from one of our cloud providers. The upside for us is that now we don't have to manage them, our puppet code got simpler, since it didn't have to describe install and whatnot of databases, only that the service we were puppetting needed a database location and user as parameters. In short, we offloaded the care and feeding of an essential part of our infrastructure to our cloud provider - yet we did not have to change anything in our applications themselves. For those of you who didn't know it, the OpenStack gerrit has been running on top of Trove for at least 6 months now. Congratulations.</p>
143 <h4 id="transformation-2---logs-in-swift">Transformation #2 - Logs in Swift</h4>
144 <p>You may have noticed that we store log files, and that we store A LOT of them. Those log files are stored in a normal filesystem that sits on top of a cinder volume (ok, sits on top of a BUNCH of cinder volumes that we stuck into LVM) We've actually reached the limit of the number of volumes one can attach to a nova instance in that cloud, and each of the volumes is as large as they let us make a single volume - so we're maxed out. We could install ceph or gluster or something - (AFS, if you know us well) - but instead we're moving to a model where instead of copying them from the build hosts to a central log server, which is a very traditional IT way of dealing with it - we're working on copying them to swift instead. This is much more &quot;Cloud Native&quot; - right? The build hosts are already ephemeral, but they produce some &quot;important&quot; data, and we should put that data into object storage. This does, it turns out, require changes to our application code ... and that's fine. It's still a worthwhile thing, and it's a worthwhile feature for our cloud to offer us.</p>
145 <p>Both of these features fall into the realm of &quot;our cloud has it, so we decided to use it&quot; - and in neither case would we have been screwed by our cloud not having it. They're in the &quot;reasonable people can reasonably disagree&quot; place.</p>
146 <h4 id="concrete-suggestion-3">Concrete Suggestion #3</h4>
147 <p>All projects should gate on their own functional test suite on top of devstack</p>
148 <p>Swift has a functional test suite that runs against a devstack install and only tests and gates swift. We should adopt this model for every Cloud-Native project. Since our projects talk to each other over REST APIs, if one breaks another in an assymetric gate, it means we're breaking something fairly fundamental that should have had a tempest test to test the API contract. If a nova change breaks horizon, there is absolutely no reason that it should take horizon to find that, since horizon is using the same REST API that a user would be. If and when it happens, someone needs to add a tempest test to cover the contract. This may hurt for a while, but ultimately should help us unwind the gate complexity and provide a more solid experience for our end users.</p>
149 <p>We gain two things by this.</p>
150 <p>First of all, although it may suck for a while, doing this should get us a bunch of interface and contract tests, which should make the fundamental things more solid, which means we can build more strongly on top of them. If Layer #1 doesn't work solidly, then there is not much of a benefit that the Cloud-Native projects gain in terms of desire for their existence. (If Nova doesn't work, why would anyone care about Trove?)</p>
151 <p>Secondly, it let's us open up the tent to more things being in &quot;OpenStack Cloud-Native project land&quot; without it needing to be a land rush. Because we're not putting Cloud-Native into the Layer #1 gate, it doesn't increase the multiplicative burden on the gate, or on the developers of those projects trying to debug failures in not-those-projects.</p>
152 <p>Reasonable people disagree about what Cloud Native applications belong in OpenStack, so if we ship a bunch of things that &quot;we&quot; clearly made, but that are a bit up for debate in terms of whether or not people want them, then we can let the market decide which of them are things that people can't live without and which are things that are only kinda cool.</p>
153 <h4 id="concrete-suggestion-4">Concrete Suggestion #4</h4>
154 <p>Add opportunistic two-project gates</p>
155 <p>Glance has a swift backend. If swift is a Cloud-Native project, then it's not going to be in the Layer #1 integrated gate. But it would be good for glance to test the interface contract with swift in a gate. There should be a glance functional test that runs on a devstack that's configured with the glance swfit backend that should gate glance and not swift. Same thing as the others, if there is a problem, it means there is a test that swift does not have of itself, and that should get fixed.</p>
156 <h4 id="operations">Operations</h4>
157 <p>It should be noted that Ironic and Ceilometer are both special cases because they are consuming 'internal' APIs. But actually, they are a different category of thing that we've started to see emerge, projects which aren't clearly user-facing and aren't cloud-native either, but are solving real problems which are typical problems for anyone running a cloud which ALSO need some degree of integration from applications in Layer #1 to be useful to anyone.</p>
158 <p>Just like Glance can be configured with a Swift backend, and because Swift is also an OpenStack project, and we should therefor have a gate check that Glance actually works when configured in that way, we should also have a gate check that Nova works when configured with an Ironic driver. The difference is that that is actually testing an internal API of Nova's - not a REST API.</p>
159 <p>I think we should think long and hard on this subject, because it's a good challenge, but I'd like to specifically not cover it here.</p>
160 <h3 id="what-we-release">What we release</h3>
161 <p>At this point, we can pull in just about anything we want to that we think is a good idea into the OpenStack bucket. The barrier to entry is &quot;Are you working on OpenStack / Are you one of us?&quot;</p>
162 <p>We still haven't addressed Quality, though.</p>
163 <p>Right now, because the integrated projects list is awkward, there is a rush to get in so that your project is allowed to add references to itself into the other projects in the integrated release. It also means we're not really giving a mechanism to try new ideas, other than fully accepting them into a tightly knit club. It means that, for process reasons, we need to graduate things before the market has had a chance to test them out. Finally, it means that people want their project to &quot;be in&quot; as a thing of value in and of itself, rather than what it really is, which is giving up autonomy and submitting various project decisions to the collective will.</p>
164 <h4 id="concrete-suggestion-5">Concrete Suggestion #5</h4>
165 <p>Tag projects as &quot;Production Ready&quot; when they're good enough to recommend using for the Cern LHC</p>
166 <p>Rather than tagging things negatively like &quot;beta&quot; or &quot;experimental&quot;, positively tag things as &quot;Production Ready&quot;. If a project does not have a &quot;Production Ready&quot; tag, we're still releasing it, and we're still standing behind it process-wise - but it may or may not have seen a lot of real world action, so you may want to be more careful before deploying it for mission critical things. I think we should be stingy in granting this tag - today, I'd say we should start with Swift and Layer #1 and that's it. That doesn't mean I think the other projects are bad - just that they need some bake-in.</p>
167 <p>What does that look like? We release OpenStack. We <em>also</em> tag some things as Production Ready. That is an arbitrary determination made by an elected body. There are no exact criteria except for convincing the TC that you're project is good, and making each member of the TC be willing to say to other people that they think it's solid enough to tell Tim Bell it's ready to deploy. If that's not a strong bar to meet, I don't know what is. Seriously, we should just make our motto: &quot;If it's good enough for the Cern LHC, it's good enough for your private cloud.&quot;</p>
168 <p>It should be noted that while there are no criteria to pass, if a project doesn't have tests or docs in the official places that were contributed by the project's doc writers, project's qa and project's infra folks, it clearly isn't production ready or cared about by enough people yet.</p>
169 <p>&quot;You're an OpenStack thing&quot; is a Process determination</p>
170 <p>&quot;You're a Production Ready OpenStack thing&quot; is a Quality determination.</p>
171 <h3 id="global-requirements">Global Requirements</h3>
172 <p>RedHat, Ubuntu and SuSE are all active and valued members of our community. They show up. They participate. They're certainly one of us. They have releases. Those releases, because of the way their repos work, require that it is possible to install all of the software from a single set of dependent library versions. It's not possible for Ubuntu Utopic to have two versions of python-requests. Even though a large production deployment might have two completely different teams of people deploying nova and swift onto completely different fleets of hardware possibly even on different base OS's, it is essential that everything we release be able to work inside of a pool of a single version of each thing.</p>
173 <h4 id="concrete-suggestion-6">Concrete Suggestion #6</h4>
174 <p>EVERYTHING participates in a single install-only devstack gate</p>
175 <p>In addition to the Layer #1 gate, each project is going to be gating on its own devstack-based per-project functional tests. But, we have to maintain that our single list of requirements results in something, so there should be a devstack install that is literally everything we've decided to release. Like, stack.sh --everything. We will not run tempest against this like we do in the integrated gate ... we'll only run stack.sh and then exit. What we'll be testing is that nothing in our tent will cause any of the services to not be able to start. It has to be a shared gate across all of the projects, because we need to make sure that no patches to anything cause anything else to not be able to install (like through some unforseen python library transitive dependency ordering issue - don't laugh, it's happened before). The likelihood that this gate ever breaks other people should be very low.</p>
176 <p>Now, does each service work? That's a thing to be tested in the individual project's functional tests in their own gates, which should each all probably have a test config that runs their functional tests against a devstack --everything cloud too.</p>
177 <h3 id="user-interface">User Interface</h3>
178 <p>No matter which things are in or out of a cloud, there are a set of end-user tools we produce to make things better for the user:</p>
179 <ul>
180 <li>Horizon</li>
181 <li>Heat</li>
182 <li>python-openstackclient</li>
183 <li>python-openstacksdk</li>
184 </ul>
185 <p>At the end of the day, I think these should exist to serve the end user quite divorced from what choices the deployer of a cloud may choose to make. I think they should know how to optionally interact with almost anything that we've chosen to release - because it is more helpful to the end user if they are expansive in what they understand. Remember, an end user does not care about what we decided to release or not release in icehouse.</p>
186 <h4 id="concrete-suggestion-7">Concrete Suggestion #7</h4>
187 <p>User interface tools should be aggressive in talking to anything we release.</p>
188 <p>The instant we confer any amount of legitimacy on a project, its patches should be welcome in the user inteface tools, because doing so gives the end users more options. Horizon, for instance, should already have Designate panels in it, and Manilla should be landing patches in python-openstackclient. If the MagentoDB folks want to wite a heat provider, we should figure out how to make that work.</p>
189 <h4 id="concrete-suggestion-8">Concrete Suggestion #8</h4>
190 <p>All user tools which are based on Layer #1 APIs should be able to be used standalone.</p>
191 <p>Deployers make choices - end users do not always care, and since Horizon and Heat both consume APIs, there is no reason why an end user should not be able to chose to run them if they want. For instance, I should be able to spin up a Horizon and use it to interact with Rackspace, even though Rackspace does not chose to deploy Horizon. For another example, HP has an internal public cloud customer that has been using Heat in production at high volume for over a year. HP public cloud does not run Heat - the internal customer runs a Heat and points it at the cloud end point - and they feel as if their experience is great.</p>
192 <p>This goes past just Horizon and Heat though. If a Layer #1 cloud is a basic thing that I can and should be able to count on, then I, as a user, may want to install a standalone trove or sahara that can use my cloud account to do its thing.</p>
193 <h4 id="concrete-suggestion-9">Concrete Suggestion #9</h4>
194 <p>All user interface tools should be multi-cloud aware</p>
195 <p>Even if HP and Rackspace both deployed heat, Infra still wouldn't be able to use it for nodepool, even though the usecase seems like it would be met because our single pool spans clouds. If the tools can be used standalone, they also need to be able to configured to point at more than one cloud. For instance, I'd love to be able to run a horizon myself and point it at both of my HP cloud accounts AND my Rackspace accounts and have it show me all of my stuff. (I'd really love it if the HP Cloud Horizon would let me register my Rackspace endpoint and credentials, but let's not get too greedy, that's trying to force a product choice on a vendor - I'm talking about end user choice here.)</p>
196 <h4 id="concrete-suggestion-10">Concrete Suggestion #10</h4>
197 <p>End user tools should adopt a rolling release model</p>
198 <p>As an end user, I do not care about icehouse vs. havana. I want the current state of end user tools to work with the current state and previous states of existing server tools. NOW - heat and horizon can also be installed IN the cloud - so they should adopt the swift rolling release plus coordinated release model. That way we can release a horizon known to work with the version of nova when we release them together, but also a person running a horizon or heat standalone doesn't necessarily have to know - or to wait 6 months for updates.</p>
199 <h3 id="the-design-summit">The Design Summit</h3>
200 <p>As may be clear at this point, the importance that we do things together and in the context of the project cannot be overstated. One of the most important things about our developer community are the design summits. We've already long ago outgrown the point where all of the people who need to be in any given room can be in the room and we're having to learn new lessons about what needs to be summit material and what needs to not be summit material. On the one hand, rethinking how we do things away from Incubated and Integrated makes the task of allocating room space and timeslots much harder. On the other hand, if the summit is mostly about cross project and project interaction issues, and less about purely internal project discussions, and if we're seeing growing benefit in using portions of the time for things like the Operator's summit and individual project meetups, then we should move forward with that worldview.</p>
201 <h4 id="concrete-suggestion-11">Concrete Suggestion #11</h4>
202 <p>Design summits should be strongly focused on cross-project and user/operator interaction.</p>
203 <p>If we focus the bulk of the pre-scheduled summit time on hard cross-project issues as well as scheduled time to sit with Operators and End Users, then we could actually defer a good portion of time and space scheduling to be more real time in response to Operator/End User feedback. That way we can make more efficient use of the time we are together, and if there is important information or requests from either of our classes of users, we can start to deal with it right then, rather than waiting for six months until our process allows us to schedule it.</p>
204 <h3 id="conclusions">Conclusions</h3>
205 <p>What does this all mean?</p>
206 <p>It means we get four new words/groupings:</p>
207 <ul>
208 <li>Layer #1</li>
209 <li>Cloud-Native</li>
210 <li>User Interface</li>
211 <li>Operator</li>
212 </ul>
213 <p>And a new tag actually related to quality:</p>
214 <ul>
215 <li>Production Ready</li>
216 </ul>
217 <p>We admit that there is a base-level of essential functionality that just HAS to work. This is Layer #1.</p>
218 <p>We have a nod somewhere that we care about users at all.</p>
219 <p>We can be more inclusive without also being more exclusive towards other thoughts. The Cloud-Native bucket will rightfully get quite expansive over time.</p>
220 <p>We no longer have the quality/readiness chicken and egg problem.</p>
221 <p>We can actually let the market decided more on the relative importance of things without us needing to predecide that.</p>
222 <p>We can take a much stronger position on some of the topics, such as &quot;Compute instances need IP Addresses&quot; without having to put ourselves in the position to take such a strong stance on everything else.</p>
223 <p>Who's with me?</p>
224
225 </div>
226
227<nav class="navbar navbar-default navbar-bottom">
228 <div class="container-fluid">
229 <p class="navbar-text">
230 <a rel="license" href="http://creativecommons.org/licenses/by/4.0/">
231 <img alt="Creative Commons License"
232 src="https://i.creativecommons.org/l/by/4.0/88x31.png"/>
233 </a>
234 <a xmlns:cc="http://creativecommons.org/ns#"
235 rel="cc:attributionURL"
236 href='http://inaugust.com'>http://inaugust.com</a> by
237 by <span xmlns:cc="http://creativecommons.org/ns#"
238 property="cc:attributionName">Monty Taylor</span>
239 is licensed under a <a rel="license"
240 href="http://creativecommons.org/licenses/by/4.0/">Creative
241 Commons Attribution 4.0 International License</a>.
242 <br />
243 Website source code available at <a href='http://git.inaugust.com/cgit/inaugust.com'>http://git.inaugust.com/cgit/inaugust.com</a>
244 </p>
245 </div>
246</nav>
247
248</body>
249</html>
diff --git a/src/resume.html b/src/resume.html
new file mode 100644
index 0000000..f403bfc
--- /dev/null
+++ b/src/resume.html
@@ -0,0 +1,301 @@
1<!doctype html>
2<html lang="en">
3<head>
4 <title>Monty Taylor - Resume</title>
5 <meta charset="utf-8">
6 <link rel="stylesheet"
7 href="/css/bootstrap.css">
8 <link rel="stylesheet"
9 href="/css/mordred.css">
10 <meta name="description"
11 content="{{author.name}}'s Website">
12 <meta name="author" content="{{author.name}}">
13 <meta name="viewport"
14 content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no, minimal-ui">
15
16</head>
17
18<body>
19
20 <div class="jumbotron">
21 <div class="container">
22
23<h1>Monty Taylor</h1>
24<p class="lead">
25<ul>
26<li>phone: +1 972 979 5079</li>
27<li>email: mordred@inaugust.com </li>
28<li><a href="http://inaugust.com/">http://inaugust.com</a></li>
29<li>twitter: e_monty</li>
30</ul>
31</p>
32</div>
33 </div>
34
35
36
37<div class="techskills">Python, C++, Drizzle, MySQL, MySQL Cluster, Java</div>
38<div class="techskills">Heartbeat, DRBD, Linux (Ubuntu/Debian, RHEL/CentOS), JNI</div>
39<div class="techskills">Clustering, Cloud Computing, Scale Out, High Availability</div>
40<div class="techskills"><small>theatre director, lighting designer, photographer, some Dutch, some German, no knowledge of Portuguese</small></div>
41
42
43
44<h3 class="resumesection">
45 <span class="titletitle">Experience</span>
46
47 <span class="titledate">1995-2010&nbsp;</span>
48 </h3>
49
50<div class="job">
51 <p>Rackspace Cloud</p>
52 <p class="jobtitle">System Architect</p>
53 <p class="jobskillslist">C++, Python, Drizzle, Linux, OSX, Solaris</p>
54 <ul>
55 <li>Core developer on <a href="http://launchpad.net/drizzle">Drizzle</a>: a modern fork of MySQL for the Cloud</li>
56 <li>Conference Speaker at conferences worldwide <small>(MySQL User's Conference, Velocity, linux.conf.au, Texas Linux Fest)</small></li>
57 <li>Wrangled Drizzle build and plugin sub-systems.</li>
58 <li>Managed and owned Drizzle coding standards and C++ standardization.</li>
59 <li>Authored <a href="http://launchpad.net/pandora-build">pandora-build</a> - A set of simple and robust autotools macros.</li>
60 <li>Worked on Bazaar and Rackspace Cloud plugins for Hudson</li>
61 </ul>
62</div>
63
64<div class="job">
65 <p>MySQL, Inc. / Sun Microsystems</p>
66 <ul>
67
68<div class="job">
69 <p>Sun Microsystems</p>
70 <p class="jobtitle">Staff Engineer</p>
71 <p class="jobskillslist">C++, Drizzle, MySQL, Linux, OSX, Solaris</p>
72 <ul>
73 <li>Core developer on <a href="http://launchpad.net/drizzle">Drizzle</a>: a modern fork of MySQL for the Cloud</li>
74 <li>Conference Speaker at conferences worldwide <small>(MySQL User's Conference, JavaOne, OSCon, Velocity, linux.conf.au, Percona Performance Conf)</small></li>
75 <li>Wrangled Drizzle build and plugin sub-systems.</li>
76 <li>Managed and owned Drizzle coding standards and C++ standardization.</li>
77 <li>Drizzle "Captain" - primary community code liason.</li>
78 <li>Authored <a href="http://launchpad.net/pandora-build">pandora-build</a> - A set of simple and robust autotools macros.</li>
79 <li>Authored <a href="http://launchpad.net/drizzle-interface">drizzle-interface</a> - Bindings to libdrizzle.</li>
80 <li>Authored <a href="http://launchpad.net/gearman-interface">gearman-interface</a> - Bindings to libgearman.</li>
81 </ul>
82</div>
83
84<div class="job">
85 <p>MySQL, Inc.</p>
86 <p class="jobtitle">Senior Consultant</p>
87 <p class="jobskillslist">MySQL, MySQL Cluster, Heartbeat, DRBD, Linux, C++, C#, Python, Java, PHP, Ruby</p>
88 <ul>
89 <li>Solutions Architect for top 10 web properties, telcos and gaming companies.</li>
90 <li>Expert in High Availability and Clustering Solutions.</li>
91 <li>Authored <a href="http://launchpad.net/ndb-bindings">NDB/Bindings</a> - Wrappers for MySQL Cluster NDB API in Java, Python, Ruby, C#, Perl and Lua.</li>
92 <li>Conference Speaker at various conferences worldwide on a wide variety of subjects. <small>(MySQL User's Conference, JavaOne, PyCon, MySQL DevConf, University of São Paulo)</small></li>
93 <li>Member of the MySQL Debian Packaging team.</li>
94 <li>Technical owner of MySQL/Linbit relationship related to DRBD.</li>
95 </ul>
96</div>
97
98</ul>
99</div>
100
101<div class="job">
102 <p>StageFiles, LLC</p>
103 <p class="jobtitle">Founder, Partner</p>
104 <p class="jobskillslist">Plone, Python, mod_python, TurboGears, Debian/Ubuntu GNU/Linux</p>
105<ul>
106 <li>Started, ran and managed company with partner.</li>
107 <li>Designed and developed a web-based portfolio system for
108 Theatrical Design.</li>
109</ul>
110</div>
111
112<div class="job">
113 <p>In August Productions, Inc.</p>
114 <p class="jobtitle">Founder, CEO</p>
115 <p class="jobskillslist">Python, Zope, elisp, LaTeX, exim, ZODB, GTK, Glade, Cyrus, SASL,
116 SquirrelMail, Apache,
117 Debian GNU/Linux, Debian Packaging FreeBSD</p>
118 <ul>
119 <li>Started and managed small business concerns, including hiring, payroll and billing.</li>
120 <li>Designed an extensible theatrical lighting control system.</li>
121 <li>Wrote a play typesetting program.</li>
122 <li>Co-developed email and web hosting system.</li>
123 <li>Authored an RFP response with Zope Corp. for an online testing system.</li>
124 <em>Clients included:</em>
125
126 <div class="job">
127 <p>Washington Mutual, Seattle, Washington</p>
128 <p class="jobskillslist">C#, Python, LaTeX, Python, Subversion,
129 Apache2, Tomcat, Solaris, Windows XP</p>
130 <ul>
131 <li>Developed reporting solution for Loan Prepayment Modeling.</li>
132 <li>Provided system support including administration and system design.</li>
133 </ul>
134 </div>
135
136
137 <div class="job">
138 <p>Monster.com, Boston, Massachusetts</p>
139 <p class="jobskillslist">Zope, Python, DTML, C#, SQL Server, Perforce, Windows 2000</p>
140 <ul>
141 <li>Single point of contact for Zope related issues for the organization.</li>
142 </ul>
143 </div>
144
145 <div class="job">
146 <p>Tahinis Mediterranean Bistro, Bar Harbor, Maine</p>
147 <p class="jobskillslist">Plone, Python, Javascript, CSS, Debian GNU/Linux</p>
148 <ul>
149 <li>Created an Online menu system for restaurants.</li>
150 </ul>
151 </div>
152
153 <div class="job">
154 <p>North Carolina State University, Raleigh, North Carolina</p>
155 <p class="jobskillslist">Zope, Python, mod-perl, Javascript, CSS, Apache,
156 Debian GNU/Linux, Solaris</p>
157 <ul>
158 <li>Created a system to help students write better lab reports.</li>
159 <li>Created a system to protect copywritten works used in course materials.</li>
160 <li>Worked on web-based system to translate Western Characters into Hindi.</li>
161 </ul>
162 </div>
163
164 <div class="job">
165 <p>Cox Interactive Media, Atlanta, Georgia</p>
166 <p class="jobskillslist">Zope, Python, Oracle, PL/SQL, Java, Solaris</p>
167 <ul>
168 <li>Implemented a Content Management System.</li>
169 </ul>
170 </div>
171
172 <div class="job" style="page-break-before: always">
173 <p>Thingamy, Oslo, Norway</p>
174 <p class="jobskillslist">Python</p>
175 <ul>
176 <li>Wrote a tool to migrate data from legacy database to ZODB.</li>
177 </ul>
178 </div>
179
180 <div class="job">
181 <p>Alexander Consulting, London, England</p>
182 <p class="jobskillslist">Zope</p>
183 <ul>
184 <li>Provided solution assessment for proposed CRM System.</li>
185 </ul>
186 </div>
187
188 <div class="job">
189 <p>iuveno, Ingolstadt, Germany</p>
190 <p class="jobskillslist">Zope, Python, LDAP, IMAP, SuSE GNU/Linux, ZEO</p>
191 <ul>
192 <li>Worked on a web-based CRM system that interfaced Palm Pilots.</li>
193 </ul>
194 </div>
195
196 <div class="job">
197 <p>MTNI, Atlanta, Georgia</p>
198 <p class="jobskillslist">Python</p>
199 <ul>
200 <li>Developed a Python library implementation of RFC 1861 - SNPP.</li>
201 </ul>
202 </div>
203
204
205 </ul>
206
207 <div class="job"> <!-- style="page-break-before: always"> -->
208 <p>HRSmart, Plano, Texas</p>
209 <p class="jobtitle">Senior System Administrator</p>
210 <p class="jobskillslist">Apache, MySQL, Debian GNU/Linux, dpkg, dirvish, Exim, nagios</p>
211 <ul>
212 <li>Administered Debian GNU/Linux, Apache and MySQL servers.</li>
213 </ul>
214 </div>
215
216 <div class="job">
217 <p>Information Innovation, Amsterdam, The Netherlands</p>
218 <p class="jobtitle">Information Artist / Lead Developer</p>
219 <p class="jobskillslist">Perl, PHP, MySQL, Oracle, Apache, Zope, Python,
220 CVS, RedHat GNU/Linux, Solaris, MacOS X</p>
221 <ul>
222 <li>Led development efforts for web-based strategic intelligence product.</li>
223 <li>Designed and developed Internet news-feed reading and processing system.</li>
224 <li>Architected internal company systems for messaging and Intranet.</li>
225 </ul>
226 </div>
227
228 <div class="job">
229 <p>Branch Bank and Trust, Wilson, North Carolina</p>
230 <p class="jobtitle">Enterprise Management Systems Analyst</p>
231 <p class="jobskillslist">Perl, ksh, AIX, Windows</p>
232 <ul>
233 <li>Wrote and maintained Perl and shell scripts for Tivoli system automation.</li>
234 </ul>
235 </div>
236
237 <div class="job">
238 <p>Best Consulting: Group Health Cooperative, Seattle, Washington</p>
239 <p class="jobtitle">Consultant</p>
240 <p class="jobskillslist">Perl, ksh, Sybase, T-SQL, Stored Procedures, Solaris</p>
241 <ul>
242 <li>Wrote code to update Data Warehouse Common Dimensions tables.</li>
243 </ul>
244 </div>
245
246 <div class="job">
247 <p>EDS: Russell Stover Candies, Kansas City, Missouri</p>
248 <p class="jobtitle">Information Analyst</p>
249 <p class="jobskillslist">Perl, ksh, Sybase, T-SQL, AIX</p>
250 <ul>
251 <li>Administered systems and performed DBA tasks supporting a 24x7 manufacturing and
252 shipping environment.</li>
253 </ul>
254 </div>
255
256
257 <div class="job">
258 <p>Fujitsu Network Communications, Richardson, Texas</p>
259 <p class="jobtitle">UNIX Admin/Support</p>
260 <p class="jobskillslist">AIX, C, Framemaker SDK, ksh</p>
261 <ul>
262 <li>Provided system and user support for Desktop AIX systems.</li>
263 </ul>
264 </div>
265
266</div>
267
268
269<h3 class="resumesection">
270 <span class="titletitle">Recent and Upcoming Conference Talks</span>
271 </h3>
272
273<div class="techskills">Velocity 2010: Drizzle: A Database Designed for Operations</div>
274<div class="techskills">MySQL User's Conference 2010: Using Drizzle</div>
275<div class="techskills">Texas Linux Fest 2010: Drizzle: A Database Designed for Operations</div>
276<div class="techskills">linux.conf.au 2010: pandora-build: autotools made better, faster, stronger</div>
277<div class="techskills">OsCon 2009: Drizzle Panel</div>
278<div class="techskills">Velocity 2009: Drizzle, a new database for the cloud</div>
279<div class="techskills">JavaOne 2009: Drizzle, a new database for the cloud</div>
280<div class="techskills">MySQL User's Conference 2009 Keynote: The Great Open Cloud Shootout</div>
281<div class="techskills">MySQL User's Conference 2009: Writing Efficient Java Applications for MySQL Cluster Using NDB/J</div>
282<div class="techskills">Percona Performance Conference 2009: Using OProfile</div>
283<div class="techskills">linux.conf.au 2009: SQL is Dead</div>
284<div class="techskills">linux.conf.au 2009: NDB/Bindings: Use the MySQL Cluster NDB API From Languages You Actually Like For Fun and Profit</div>
285<div class="techskills">linux.conf.au 2009: DRBD and Heartbeat, Database Agnostic High Availability</div>
286
287<div class="techskills">JavaOne 2008: MySQL Cluster and Java</div>
288<div class="techskills">MySQL User's Conference 2008 Keynote: Scaling MySQL - Up or Out?</div>
289<div class="techskills">MySQL User's Conference 2008: From SQL to NDB API and the MySQL Cluster Data Nodes and Back Again</div>
290<div class="techskills">MySQL User's Conference 2008: High Availability Landscape of MySQL</div>
291<div class="techskills">MySQL User's Conference 2008: MySQL Cluster and Java (and python, and ruby, and...)</div>
292
293<div class="techskills">MySQL User's Conference 2007: ORM on Steroids</div>
294<div class="techskills">PyCon 2007: Wrapping C++ Libraries using SWIG</div>
295<div class="techskills">PyCon 2007: Packaging Python for Linux Distributions</div>
296<div class="techskills">University of São Paulo Seminars on Software Systems: MySQL Cluster</div>
297
298<h3> For more information, <a href="http://www.google.com/search?q=monty+taylor">Google me</a></h3>
299
300</body>
301</html>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-26 08:43:17 +0000