Thank you very much, Admiral. Like everyone else, I'd like to start off by saying it's a great honour and pleasure for me to be here participating in this great event. Of course it's always nice to come to Newport, but wherever I go around the world and speak to navies, I can't help but notice that they usually have the nicest bits of real estate around. I suppose it's something to do with the fact that sailors always get everywhere first. That's certainly true at Newport, especially when the weather is as nice as it is today. We've heard a lot about the international context, the nature of strategy, cyber issues. I guess my job today is to get us back to the maritime narrative for this last afternoon, setting some of the issues up for the panel that will be followed and moderated by Pete Schwartz. So, hang on. There we go. Alfred Thayer Mahon, who once graced this establishment, argued that sea power was the most important material element in the rise and fall of nations. Most of us here would probably agree that sea was and is important for five separate, if related reasons. First it's a stock resource of invaluable resources like oil, gas and fish. And in the future, who knows what else. And that's a really important point for the future. Second of course, the sea is the world's main, cheapest and usually safest means of transportation, of transporting goods and people around the world. These two attributes put together explain why it is that the maritime element in many national economies around the world from China to Colombia is dramatically rising. Third, rather like today's internet, it was a principal means for the acquisition and dissemination of information. And to some extent, it still is. Even now in the electronic age, 96% of our digital information is still transmitted through cables laid on the bottom of the sea. Further, many of the world's unknown unknowns are to be found at sea in fact. Fourth, a sea has been and remains a highly effective means of securing the capacity for military dominion and strategic manoeuvre. Lastly, and this is a relatively recent addition to the listening, the sea is a physical environment whose health is critical to the world's ecological well-being, not least through its complex relationship with climate change. And yet despite all of this, which seems so obvious to us, what I would call the maritime narrative today is faced by a number of significant challenges. And I think these need to be seriously addressed because on the face of it, they could undermine the apparent relative importance of sea power for the 21st century, which is something that we tend to take for granted. I would argue that these challenges fall into three broad categories and produce what I've called three different battles that need to be won. The first of these battles is the battle for maritime security. The second is the battle for access and the third, the battle for maritime sustainability. I aim to talk about each of these in turn using as a visual aid, not a PowerPoint presentation, but a number of pictures on the basis that one of these is probably worth a thousand words. My aim is not to provide answers, I wish I could. So much is to remind you of the issues and the questions that need to be thought about if not answered when dealing with sea power issues for the rest of the 21st century, which if you like are my challenge for the panel that follows. So let's start with the first of my battles, the battle for maritime security. And this is the first of my pictures. It will be familiar to many of you, I think, because it was produced here. I think it was anyway, but in the best academic traditions I stole it years ago and have made relentless use of it ever since. And I've done so because I think it's well worth dwelling on. What it shows, of course, is a map of the world that's produced by plotting the radio transmissions of ships over, I think, it was a week. And some things really stand out from this immediately. The first, of course, is the concentration of shipping in the northern hemisphere rather than the southern, which tells you quite a lot about what's happening. It picks out some of the major sea routes, obviously, particularly across the North Atlantic and the North Pacific. But somewhat less, obviously, with one or two exceptions. Australia, for example, and if you have a really good imagination, New Zealand squeezed in down the bottom left hand right hand corner here, it doesn't pick out nations. What it portrays is a system, a system that operates over and above the level of the nation-state. Now, I'm not for one moment saying that the nation-state doesn't matter, of course it does. But it has to be seen these days as a constituent of the system. And it's a system that underpins globalization, on which, for all its faults, the world's peace and prosperity generally depend. And the key constituent of that system is that, the merchant ship, that's the Emma Meirsk, of course. This is the essential constituent of the system. Its capacity to move goods around freely is absolutely critical to our present and our future. And so is the confidence that it can do so, because that underpins our financial system, our investments and our stock exchanges. But for all of this, good order at sea, or what is increasingly called these days maritime security, is a precondition. Without it, international trade and everything that depends on it would fall to pieces. Good order at sea is nonetheless threatened from various directions. Interstate conflict, such as the Iran-Iraq war of the 1980s, is probably the worst if possibly inadvertent threat that the system faces. But we should always remember, not least in the light of 9-11, that globalization itself has its deliberate and determined enemies. Maritime crime in its various forms, piracy, terrorism, drugs, arms and people trafficking, can also severely threaten the system. Directly by what can happen at sea or indirectly by virtue of its consequences on stability and the conditions for trade are sure. Finally, systemic pollution, unsustainable levels of resource extraction, catastrophic weather events also could potentially undermine the sea-based trading system. Now let me give you an example of the kind of threat that I think we're talking about here. This is a picture of the fishing fleet at Bajor in Hainan Island in China. It's a really extraordinary sight. You see these fishing boats stretching to the far horizon. There seems no end to them. And what we're looking at really is a community of interest, a community of interest of artisanal fishermen who are under desperate pressure. They're under pressure because the fish stocks that they rely on are rapidly depleting. They're under pressure because they're facing competition from other such communities all round the South China Sea. They're under pressure because they're facing the broader effects of industrial fishermen coming from mainland ports in China, Taiwan and elsewhere. So what they do is to push out constantly looking for new fishing grounds in a challenge sea. And this brings them up against other fishermen from other ports doing exactly the same thing. So there's daily confrontations between fleets of trawlers, fleets of coastguard vessels and increasingly warships confronting each other in a restricted area of sea. It is a disaster waiting to happen. And it's a disaster waiting to happen that's critical, especially for commercial shipping, particularly of China, Japan, Korea, as well as the United States and other countries. And it's also an area of sea that's of rising strategic importance for hard military reasons. It's worrying apropos of what we were talking about earlier today for another reason too, and that's a nationalist sentiment that it tends to feed. The netizens, the citizens now empowered by the social media are getting increasingly anxious to see their governments defend what they regard as their own nation, their own sovereignty, if you like. And all of this, the fact that these fishermen are freewheeling fishermen going where they want to, the fact that the governments are under pressure from local authorities like those in Hainan, they're under pressure from different constituencies of interest like the fishermen, is all kind of boxing in the freedom of governments and the ability of governments to keep control of what's happening, to keep control of events and affairs. And that, in a sensitive and delicate area like the South China Sea, is profoundly worrying. But there's another problem too at the same place. This is a picture of fishing tackle. Mountains and mountains and mountains of this stuff being mended by ladies that you can just about pick out in that black tent up there and a whole series of all of these, the support industry, if you like, for the fishing fleet. And what this implies and demonstrates really is the scale of the threat that the South China Sea faces as a physical environment because it suggests the scale of the fish take. The South China Sea is a highly vulnerable, semi-enclosed sea threatened by imminent environmental disaster. Because jurisdiction over it is so disputed, it largely lacks effective protection. And the absence of protection itself could provide consequences that could have a catastrophic effect on the region and indirectly on the world. So that's just one example of the kind of threat I'm talking about. And there are legions of such examples. So against such threats and challenges, the aim is not to control the sea as such, but to keep it safe for all forms of legitimate use. Now this is a very different form of sea control to the version normally associated with Mahal and Corbett. It's more about monitoring the sea, supervising the sea than it is about dominating it. It's about protecting the sea. It's more often aimed at non-state actors than at states. Navies and coast guards then, and other maritime stakeholders too, seek to defend the system by what they do at sea and from the sea. And this is an important point because it's not just a question of defending trade or fishing. It's about defending the conditions for trade, ashore, most obviously in the literals. At least to the extent that navies can do that in an era when more and more of the world's population is shifting to the heaving mega cities of the coast, the so-called crowding of the literal. Navies and coast guards and the other maritime stakeholders do this both locally in their own and neighbouring waters, what you might call the home game. And more distantly in responding to far off threats, usually in the company of others, the away game. But the analogy of a game shouldn't suggest that this is anything but a battle for maritime security. It's a battle that must be won insofar as it can be won at any one time because it is so important. And winning it requires the kind of joined up ocean strategy at governmental level, only slowly being developed around the world. The demands of the battle in one area, like the Arctic, may be fundamentally different from the demands of, let's say, the Gulf of Guinea. There is no one size fits all solution to the problem. The sheer diversity of the forms that this battle can take is a substantial problem. Nor even here in the hallowed halls of Newport should we forget that navies should preserve a fitting sense of humility, for there are many things that they cannot do, even in the sphere of wider maritime security. Of Somalia, for instance, they have shown that they can deal with piracy with the symptoms of the problem, in other words, but they are much less capable of dealing with its causes. But this humility shouldn't be overdone, though, for the naval contribution is vital. The sheer comprehensiveness of the requirement, though, is a challenge to any purely military service. A consequent problem here, I think, is conceptual. Often countries do have broad definitions of what they want in terms of good order at sea maritime security, and often a set of tactical procedures. What they often don't have is a strategy for maritime security. That says not much conceptual thinking, not much examination of some of the key differences between a maritime security operation and war fighting ones. For instance, in dealing with people or drug smugglers, it's probably, almost certainly, inappropriate even to think about achieving victory as an objective. And that for a military service with conventional thinking is extremely hard to do. Instead, in the maritime security battles, it's much more a question of containing or managing a problem, probably indefinitely, and this too is an extremely hard objective for military people to accept. The last challenge they face in the battle for maritime security is that it calls for a range of procedures, activities, skill sets, equipment, weaponry and platforms that can be very different from those of what many in many navies would regard as their real business preparation for war fighting. And this, therefore, raises extremely difficult dilemmas of choice, especially in times of economic constraint, either within the navy, if the Coast Guard responsibility is part of its responsibility, or at governmental level, if it isn't. And this really gets us to the second battle, the more familiar one, as far as most navies are concerned, that is all about seeking strategic dominance and the capacity for military manoeuvre. This boils down to a battle for access. The real justification for navies is that they prevent war by being able to show they can fight it. Sea whist, packum, parabellum, after all. This surely is their top priority. The biggest threat to this traditional function, and indeed to the more muscular forms of the battle for maritime security that I've already talked about, is the rise these days of land and sea-based capabilities for denial. Some of these would seem to pose such military technical or political strategic challenges to even the strongest naval powers as to raise doubts about the extent to which they can go on defending their national interests, and perhaps a system more widely through being able to maintain a forward's presence and the capacity to project even limited power ashore. In British maritime doctrine, sea denial is defined as, and I'm quoting, the condition short of full-scale sea control that exists when an opponent is prevented from using a sea area for his purposes. In this way, a markedly inferior force can successfully thwart a superior force. Recently, of course, the concept of sea denial has been relabeled, anti-access area denial A2AD. But as a concept, it's not in any way new. But some, though, would argue that recent developments, technical, political and legal, have made it more transformative in effect than ever before, suggesting in fact that it could now profoundly shift the balance between big ships and small ones, surface ships and submarines, aircraft and missiles, forces at sea compared to forces on land, and raise doubts about the operational viability of forward deployed forces in areas of contention. All of this, it could be argued, threatens the strategic utility of navies because of the importance of access to their function. Their strategic value is bound up with the capacity to use the sea as the world's greatest manoeuvre space. Sea control, or at least the capacity to keep the sea even in the face of opposition, is a precondition for the maintenance of that forward presence which provides the ability to monitor the maritime domain, to sustain political relationships with local countries in the area of concern, and if necessary to project power ashore to some degree. To deal with this challenge all around the world, navies are looking at various ways of countering the alleged rise of sea denial capabilities, investigating it and substantively investing in it. In the United States, but elsewhere too, this has provoked debate about the so-called air-sea battle, or air-sea coordination, as it is rather less snappily known in the UK, as a means of assuring access in the seemingly new context. While you've all seen pictures like this, we all know what we're talking about. This is a hugely complex situation that goes across all five of the domains, and there's layers of battle, A2AD versus ASB. What seems to be involved in this kind of conception of the future is a contest in long-range precision strike between two systems that each comprise a multitude of components linked together electronically with levels of efficiency that make the operational whole a good deal more effective than the sum of its parts. Clearly the outcome of any such contest for access, for real, would be highly scenario dependent and would remain extremely hard to call. Geography, the relative military technical capabilities of both sides, the contending powers, and the extent to which they divide their investments between sea control or sea denial, and the effect of the international context would all have a major role to play. And in the light of what we've already heard this morning, systems of systems are especially vulnerable to cyber attack, and the sheer unpredictability of its effect would need to be factored into the equation as well. There's another big cause of uncertainty that makes it very difficult to come to a verdict about the balance between sea denial and sea control in the 21st century. Pre-emptif or reactive attacks on assets ashore often seem to be part of the planning assumption in the debate that both sides use. Either the access denier will use land-based missiles or aircraft to target incoming naval forces, or the access assertor will target those assets to reduce their effect, possibly preemptively. That being so, the prospect of an initial clash at sea escalating dramatically into a full scale war between major players would seem to be high, and so would surely deter its extended use for all but the direst of contingencies. Hence the willingness of the two sides actually to employ all their capabilities and to take the operational risk of unwanted escalation also becomes a major cause of uncertainty. Maybe this uncertainty makes for good deterrence, question mark discussed. Either way, what could well result would be a competition in risk taking where everything is uncertain. But of course in most cases a major navy would probably be able to regard such threats to access as being containable, especially when it wasn't up against high end and militarily capable adversaries who were able to provide capable and sustained incredible resistance. Even so the possibility of significant change in the defensive offensive, denial control balances does need to be taken very seriously. This is partly because of the enormous consequences for the established way of doing things at sea were it to be true. It's partly because a professional determination to produce ships that are nonetheless capable of going into harm's way in order to do their business is far more likely to increase costs than to reduce them in times that are for many navies budgetarily constrained. And it's partly because such a shift is likely to reduce the willingness of politicians and diplomats around the world to take the risks of even necessary interventions. The more discretionary the commitment is seen to be the less likely that operational risks will be taken. And this usefully demonstrates the fuzziness of the distinctions between the military technical and the political strategic dimensions of the battle for access, 21st century seaper and maritime strategy. As so often the Chinese have a word for it, or a phrase at any rate, the three warfare's. There is likely to be a very substantial, even dominating, political strategic aspect to the battle for access. Some of this will be what is sometimes called lawfare, using or defeating interpretations of international law as a weapon against perceived outsiders, something I'll come back to later. In all probability there will be a competitive campaign of strategic communications, of political engagement with allies, partners and bystanders in the region that's intended to persuade them that the presence of intervening forces is helpful or not, depending on who's doing it. It will also likely involve efforts to present the military technical threat to access as being more or less, depending on who is conducting it, than it probably is. So there are crucial legal, political and psychological aspects to the battle for access, as well as a host of military technical ones. There's nothing new about any of this either. But such is a seductive lure of new technology that we sometimes need to be reminded that there's much more to military effectiveness than things that go bang. Securing and maintaining access to the world ocean is so important, however, that no aspect of the case should be neglected. Well, amateurs like me talk strategy. Professionals like you talk logistics. This brings me to the third battle, the one for maritime sustainability. The need, if you like, to maintain the advantages of sea power and to be able to enjoy them for the long run. There seem to be four, maybe five key elements to this. The first is increasing operational efficiency. The CNO recently released some interesting figures to the effect that the US Navy currently has 104 ships operational, out of a total of 285. This is about the same number as it used to maintain 20 years ago when the US Navy was around 400 ships. This suggests that up to a point you can do more with less. Up to a point. The strength of a Navy isn't, of course, simply measured by how many ships it has, or even how good they are. Instead, it's a function of how its forces compare to the commitments it has when compared to the equivalent balance characteristic of other countries. Although most estimates suggest that globally US naval dominance is unlikely to be overset in the near future, or even the foreseeable future, the gap will be appreciably narrower in the future in some regions of the world. This calls for serious thinking about strategic priorities, about force levels, about how to maintain them and to make the best use of them. The second element to ensuring sustainability is to make the best use of other key stakeholders in sea power. This conference is about sea power and maritime strategy, not just navies, which is simply a subset of that. Long-term sustainability calls again for an ocean's policy that knits together the interests and the contribution of all maritime stakeholders. The Coast Guard, the amphibious community, parts of the other services, the city, and importantly, industry. The evidence suggests wherever you look at it around the world that it takes government policy and drive to overcome sectional interest. It's not enough simply to leave all of this to the coalescence of resources, something more substantial needs to be done to produce the kind of maritime teamwork that the future requires. This in turn requires that coherence is built across and between government departments and agencies. And it also bears repeating that the use of the word maritime implies the involvement of all the domains of cyber as well as the sea, especially perhaps these days of cyber. You only have to think of the consequences of adversaries being able to take down the operating systems of a merchant ship, or a warship even, or even a networked force to see the possible consequences of inadequate co-ordination across the domains. This all seems to call for a multi-agency maritime risk assessment procedure that is proactive rather than reactive, that is tasked to think ahead generically rather than simply to respond to the latest challenge. One problem here though is that in constructing such multi-agency and or multinational alliances of interest it's hard to avoid creating large lumbering organisations that take time to get their acts together to decide on their course of action or to get their domestic legislation in order. Compared to this, the small freewheeling organisations characteristics of drugs cartels or people smuggling gangs can be much more agile, constantly forcing enforcement agencies on to the back foot and into reactive mode, winning the battles in the Uda loop, if you like. This is a real issue. Thirdly, one important advantage enjoyed by USC Power is that 18 of the world's other top 20 navies are allies or partners at least to some degree of the United States. Continuing this happy state of affairs and sustainability will call for some diplomatic finesse on the part of the United States. The trouble with allies, as Winston Churchill once said, is that sometimes they have views of their own. On the one hand, the support of the 18 and indeed of all the other smaller fry as well will therefore constantly need to be worked for. On the other hand, the United States will want neither to offer such support as might encourage destabilising adventurism nor to make unnecessary enemies of the other two major naval players. Nor can the United States, as the global player, afford to favour one group of allies or partners at the expense of neglecting others. All this makes that concentration of force that Mahan advocated so strongly very difficult to achieve. Fourthly, there is a need for conceptual resilience in order to ensure that the maritime narrative can withstand the many challenges thrown at it, such as the alleged rise of sea denial capabilities, all the demands of maritime security that I've just been talking about. Neither of these issues nor a welter of other contemporary concerns have been much discussed by the classical masters, Mahan and Corbyn. There are many such issues to be thought about. One of the real problems with strategy making though is that strategies and doctrinal statements often do little more than articulate the desired ends of policy. They do the clasavitzian thing of applying means to ends or operationalising policy and strategy, if you like. Let me end with just one example of this and I've already signed posted earlier on, the freedom of navigation. Mahan famously likened the sea to a wide common over which men may pass in all directions. This is a very interesting analogy. Once upon a time, common used to be large areas of non-owned land that people could use for the common benefit. Poor people would keep their crops and their animals on it for your charge. But gradually over the days in England, over the years in England, these commons got enclosed. People started putting out fences on them until they dwindled to this kind of thing, which is the common of the village next to mine in the UK. This process of enclosure, this notion of putting fences on the common land, caused huge anguish and social distress. It was partly responsible for the English Civil War of the 17th century, but the process nonetheless went on. My point really is that the memory of all of this goes deep in the Anglo-American psyche. It's a cultural thing as well as a legal concept, the notion of the commons without fences. But although all countries subscribe to the freedom of the seas in general, a disturbing number including US allies and partners, I might say, in practice imposed restraints on it. Even the United States occasionally talks about the sea as an ungoverned space as though it shouldn't be. The practical restriction can come about through claiming illegitimate baselines from which sea areas are calculated by excessive claims or by seeking to limit the freedom of foreign warships to operate in exclusive economic zones. This latter is a particular problem. To defend the global commons in short, the argument needs to be better articulated and better planned for primarily by the maritime powers. I would argue that Mahan and Corwit don't offer much help. It's something we really need to think about. Such a strategy you could say then needs to be operationalised. By a designed program that puts it into effect that are designed, if you like, to produce the desired end state, which is a commons open for the legitimate use of all. This isn't just a question of conducting freedom of navigation exercises. It's largely much more a question that says that the freedom of navigation for warships, shall we say, is not just a legal right that is in the interests of global stability. This is just one example of the need to do some fresh thinking about maritime strategy and how best to put it into effect for the 21st century. There are many others. Well, in conclusion, it's been well said that if you want to understand sea power, you need a bigger map to take in the bigger picture because that's always what justifies it. But despite everything I said at the beginning of this talk in its latest Gallup Poll survey, the Washington Times found that the US Navy was regarded as the least important of the four main military services. Ladies and gentlemen, we all have work to do in selling the sea. To my mind at least there is little doubt that in the rest of this century sea power will be at least as important as it always has been and arguably much more. The only real question though is who's sea power it will be and that partly depends on you. Thank you very much. We have a few minutes so if you'd like to engage in comments, questions of what President Gorbachev in happier days used to call socialist criticism. Now's your chance. Yeah. A threatened question from yesterday. Professor Till, thank you very much for being here. Some would argue that the high water point of maritime strategy, naval strategy, was John Layman and Jim Watkins' maritime strategy of the 1980s. A question for you, do you agree with that and so why and if you don't, why? I do and I don't. I'm an academic. I can see both sides of the argument. I do in the sense that, no I don't in the sense that it didn't articulate means and it didn't identify how the means were to be sustained in any great detail to the level that would be helpful to defence planners. So in that sense I think you could argue that it wasn't a really highly effective strategy. It's more a policy statement, if you like. But I do agree that it was a high water market for several reasons. And the first was that it articulated a general sense of what the navy was for in the conditions that applied in the 1980s. That most people, most people, yes I think most people found at least interesting if not wholly convincing. It was also a nicely articulated strategy in the sense that it had different target audiences and within one document was able to transmit three different messages. The one message was to of course the Soviet Union of deterrence, that the waters of northern Europe and the northeast Asia, northeast Pacific were not to be regarded in any sense as the Soviet Union's own backyard from which it would be clear of all interference and threaten and so on and so forth. So this was an act of deterrence, if you like, to the Soviet Union. It was also an act of reassurance to the United States' forward allies in Europe and in the Far East and the far end of the Mediterranean that wherever their position was they would not be regarded, if you like, as forward of the line. I think there was an implicit message in it as well in terms of less of what was said but more in terms of how it was operationalised. That this was an occasional presence, another continuous presence, and so there was an element of reassurance for the Soviet Union as well. That this wasn't, if you like, an overtly aggressive move that was designed, if you like, to initiate an attack out of the blue or anything of that sort. Nonetheless, it contained within it the inevitability for the Soviet Union that they would have to respond in order to respond at a time when it was also famously responding to the Star Wars initiative and all sorts of other military technical challenges that it thought the United States was posing it. President Gorbachev's mind did considerable damage to the Soviet economy and played a part in bringing about the end of the Cold War. For all of those reasons, I think it had a set of objectives. You could more or less deduce how they would be put into effect. In places like this, the detailed planning on whether and when certain acts to operationalise a strategy could be carried out were being discussed in private, as they probably should have been. I think it was also important, as being, if you like, the first step of convergence in coming up with a strategy to which the US Allies and the other services could all play a significant role. In all of those ways, I think there were good things. It's a clarity of vision. It's the idea of coming up with a narrative, if you like, that even the Navy's enemies need to take seriously. I think it was a piece of the... It was something that was really effective, is what I'm trying to say. Dead silence? I can't see anybody else? Oh, yes, run over there, sorry. A questioner had, when you showed the container ship, it was a bunch of containers on it. How navy ships, the US Navy ships, they picked these things up in containers in shallow water, you know, 100 feet, 150 feet. In the latest I heard, say, ignore it. I ignore it. It's not in the Navy apparently, it's politics. I'm not sure I understood the question. Could you say it again? Could you say it again? I didn't quite understand the point you were making. The container ship that you showed on your slide, sometimes some of those containers fall off from the ship. We pick up these containers in shallow water, our Navy ships, tell the local people what it is. I guess they dive after them and I don't know what happens. Specifically we were told to ignore it, by our management, by the Navy management. Your guess is better than mine. I really don't know. But I think it's very difficult to underrate the importance of the appearance of the container and the large container ship in transforming the way that the world's shipping patterns are shifting towards the notion of hub ports, which can take these sort of huge ships. The way that it, if you like, concentrates vulnerabilities in one geographic area. Much more than used to be in the case of the old days of commercial shipping and even smaller containerships. We're hearing a lot these days about threats to what we call the open seas, particularly in the South China Sea. You see that as requiring more of the US presence in that area to preserve the freedom of the seas, if you will. Do you think that territorial claims made by the Chinese are something that we need to take action to dispute more than international courts, but more directly? Let me distinguish between the Chinese claims and actions in support of the claims. The United States takes a position, which I think is the right and proper one, that it takes no position on who owns what in the South China Sea. I think, in many ways, it's easy to underestimate what the Chinese would regard as the validity of their claims. The claims of Vietnam and China are disputable. I'm not a maritime lawyer. I don't have a definite view on this nor the most maritime lawyers, actually. There are two very interesting issues between China and Vietnam that go back to historical entitlement. The claim between China and the Philippines is also extremely complicated, though somewhat less complicated. I think the United States is very wise not to get involved in actually saying that one claim is just and another claim is not. For that reason, I think it's constant denials of taking such a position are very important, and it's very important that it should carry on doing that. Nonetheless, there's a difference between having a claim and the way you seek to process it, or progress it, I should say. I would say that even though over this oil rig business, for example, between Vietnam and China at the moment, leaving aside the validity of the claims of both claimants, the Chinese were wrong to put an oil rig into a disputed area of sea surrounded by a ring of coastguard vessels and fishing trawlers with an outer ring of naval vessels outside because that was in violation of the 2002 declaration of conduct to my mind, it was anyway, that they signed with all the other claimants back in 2002. That said, leaving aside the question of sovereignty, we all agree not to do things which are going to make the situation worse. Sending that oil rig into waters that the Vietnamese rightly or wrongly regarded as theirs I think was a gratuitous violation of the 2002 agreement, which I think does raise the question about the extent to which it ever can be operationalised. Now, your question was about what should the US do about it. In particular, in that regard, what to do with anything about the oil rig? Anything about... What if anything to do about the oil rig? Yeah, yeah. Well, frankly, I don't think the United States should do anything about the oil rig, but I think it should maintain what lawyers call a watching brief and be known to do so. It makes clear that its position is the defence of freedom of navigation. And I think it should continue to make clear its view that freedom of navigation applies in the exclusive economic zone as far as warships are concerned. I think freedom of navigation exercise is conducted with some finesse or need to be necessary. But I think they should be sustained by that broader argument that I was trying to make that you have to get over the idea, and so do the UK, Australia and other countries of like mind, that it's important for world stability that ships do have this capacity to operate forwards. And in fact, I think the Chinese are actually coming round to this point of view anyway. I can see at the Shangri-La dialogue last year, not the last one, the one last year, they admitted for the first time in public uniform people saying that they engage in military surveillance operations in the USAZ. We all know they do, but saying so in public was very interesting. And they said that this was reciprocal and therefore okay. More interestingly, some of them at least seem to be distinguishing between what they call tactical military surveillance and strategic military surveillance in the exclusive economic zone. The strategic military surveillance or military data gathering, as the British call it, it's just keeping a general eye on things. And that's okay, seems to be. Tactical military surveillance is the kind of battlefield surveillance you do immediately before an attack. That's offensive, that's not okay. And that seems to be an interesting development. I've heard people arguing that this year. No, sorry, at the end of last year in Beijing. So that might be an indication that the Chinese are actually coming round to the standard Western view about freedom of navigation. The point is that the focus should be on freedom of navigation and open seas and not the United States shouldn't be concerned about resource allocation in the South China Sea or anywhere else in the way we have directed. That's exactly my point. It shouldn't be concerned about it because I don't think the United States is in a position to do anything about it that has any legal standing. Nor is any other outside country, I might say. So I don't think it should seek to do that. Yeah. I'm afraid I'm being called.


You know I think having been a journalist for decades, I think that there is need for a distinction between news and views. It is getting blurred because a lot of people think that commentary and chatter is substitute for content for actually what happened. Now commentary and you know chatter may actually be content but it is not news. So for me there is a very clear line between news and views. In the business VRN which is communications, we tend to allow a blurring because it is to a client's advantage or it gets you a few more eyeballs. But I think that the audience which is discerning which is powerful and the audience which is likely to pass it on forward tends to be able to see this distinction. It is the job of PR sometimes to blur that temporarily but ultimately I do not think it holds. PR has evolved but the game is still the same. The game ultimately is figuring out what does the client want, who does she wants to speak to and how long are they going to be in the game. And once you have these three things figured then you have the plan. Creativity is best applied to short term but I think creativity in the long term is much harder to do. So for example you are doing say the fourth convention of laundry makers of Coimbatore. Now what can you do new in the fifth year? So you have done everything in the first four years and that is when a higher level of creativity and client immersion will matter and really people who can make the difference then are the ones to watch out for. They are the ones who are long term players.


Hi and welcome to the session. Let us discuss the following question. The question says, find the indicated terms in each of the sequences in exercises 7 to 10, whose nth terms are 8 part is a n is equal to n squared by 2n and the indicated term is a 7. Let us now begin with the solution. Given nth term is a n is equal to n squared upon 2 to the power n. Since we need to find a 7 therefore we will put n as 7 in the nth term. By substituting n as 7 in the nth term we get a 7 is equal to 7 squared upon 2 to the power 7 and this is equal to 49 upon 128. Hence the required 7 term that is a 7 is equal to 49 by 128. This is our required answer. So this completes the session. Bye and take care.


with a different method. So remember your research process. Start with your research plan, document your research goals and questions, determine your participant criteria and recruit, all of that's the same. The only thing that's slightly different is writing task-based questions this time. So again, remembering that they're interacting with your thing that you're trying to evaluate, conduct your feedback sessions, synthesize, iterate, write the research process. One new thing is the think a lot method. So in interviews, it's kind of naturally you're asking them questions, they're responding. This time you're really interested in their behavior, their thought process, expectations. So that has to come with having them actually talk out loud. So what are they looking at, trying to do what they think about all of it. And again, helps us understand thought process behavior. And it's uncomfortable and unnatural, right? To like be thinking and talking the whole time. So it's important to kind of help participants ease into it. And I think I do have, I'm not gonna read it, but it's in the slides and you'll have it. But this is kind of a blurb that I use that lots of people use.


Hello, this is Christian. Welcome to episode five of this video series. In this video, we're going to do a little demo to put all these together, the classes, trades, and interfaces, and how they are used in a program. So let's go and take a look. So in the IDE here, I'm going to create, I know I call classes, but that's OK, I guess. Let's go and create, let's just say there for our example, I want to create a class called Plants. So I'll call the plants file. OK, and also, I already have animals. I'll use this animal to compare with the plant. And let me just collapse this. And I will use this two screen to show you what, well, not that way, vertically, I guess. We can close this one here. OK, so we can compare between the two here. So on the left side, let's say I'm going to use the plant. And then on the right is Animal Kingdom. So for now, let's say I'm going to create my class for the plant first. So I have a class kind of similar to the animal kingdom. And I'll call it Plant Kingdom. OK, and then this plant kingdom has something in there. I can also make this as an abstract to kind of match what I have over there. And then I have a class called the actual plant. I guess we call it, I don't know what, Tree. That is, well, I mean, Tree is a real plant. Let's call it that spruce to be more specific. And that it will extend the plant kingdom. OK, so here we go. And then I can create an object here, P for plant. Yeah, well, S for new spruce. OK, so I have two objects kind of similar to what I have over here. And these are just constructors. So let me turn these off. And so we don't have to show any of those stuff. And this one here is something else. I want to turn that off and remove that. So they look very similar to what the other plant class is. OK, so we have two separate sets of classes. One is for the plant kingdom. One is for the animal kingdom. And so what is the point here, I guess? I don't have an interface here, right? So we could have an interface to create something that is very generic that the animal and the plant kingdom must implement. So how do we do this? So we can create, let's put it on the animal side. Let's create an interface. We call it just I for interface. And I'm just going to call it type. I don't know, I'm just making this up, OK? And so let's just say inside here, I have a function called set type. And also I have a function called get type, right? I'm just making this so we can use it. And so it's an interface that both of these animal kingdoms will use. And I'm going to implement that as well. Implements the I type. And then this also implements that I type. So now both of these have those interfaces. But now they have to implement that, right? Implement those functions because they both use it. So in this case, I have to implement both of those, which is required. You can either do that or you can implement inside the abstract class so you don't have to do it, right? So I should have put it in the wrong place. Implement type. Yeah, that's correct. All right, so then because they're required, I can do inside here in the abstract class. So I don't have to do it down here. If I do it in here or in here, you see that I have to do it both of them. And depending on how these functions are used, OK? If they are used differently, then that's great. If it's not, then it's redundant. But you have no choice because you are stuck with it, right? Because you have to use it. So therefore, I'm going to go and just put here. Implement the methods down here in my Animal Kingdom class, and the Mammoth class. They're in here now. And let me turn this off so you can see. I'm going to turn this off just to show that they are in here. I'm going to just collapse these. So we have this implementation. The Mammoth is happy. They plant the spruce tree. It must also implement those to make it happy as well. So here they are. And then they are both good to go. OK, so you can see how interfaces can be played in this scenario. It's something that can be shared across two different classes now. Now let's say that in the plant kingdom has a really important function called, maybe, again, I'm going to put public here, function something like what should we call it, determine age, the age of something, the age of the plant, or whatever that is. So its function can also be used to determine the age of the animal. So I say, I'm just using one example here. It could be a bunch of functions, a useful functions that the Animal Kingdom can also use. So instead of recreating these functions in here again, these are for implementations. So the interface, they are not implemented. So you have to do that yourself manually inside here for each subclass. But let's just say that the Animal Kingdom, the plant kingdom has some functions that are really useful. And I want to use those in the Animal Kingdom too. So I don't have to recreate them again, because what they do is very similar in nature, or exactly the same. So what do you do? How do you solve this problem? Well, I don't want to rewrite them here. So you can say, OK, well, maybe I can then make another class, another class that can use and share these functions in both classes. So you can say, OK, well, then let me go and create another class up here, maybe another abstract class called species. So I put all these functions in the species class, and then now this plant kingdom can implement the interface, but also can extend the species class. So you can see how that works. Let me kind of minimize it a little bit smaller, but I apologize. So here's the same thing. So if I want to use those functions, I can just, again, Animal Kingdom can extend this species class. And so now I have both have access to the same functions in the species class, so you can extend that as well. So my mammoth can have x to that.  Absolutely. Same thing over here, s, and then have determinant h. So I solved that problem. Cool, huh? OK, so and then another scenario will be, say, you have another class out of somewhere, another class, and this is nothing related to species at all, or the Animal Kingdom. I'm just going to make this up, say I have another class called math, some kind of math class. And this math has a really important function called special class, special function, in my case, special calculator. That is really useful for both of these species, or the plant kingdom, and the Animal Kingdom here. OK? So you want to be able to use those, and so you can say, well, OK, because I can extend these classes. Of course, if you extend this species class, if you extend that to the math class, then problem is solved. Of course, if you do that, and you can see that down here, I have s points to my special calculate class. Same thing with m over here. You saw already a special class. There you go, problem is solved. So this is fine. But let's say you have some restrictions, or you don't want, because this math class has a lot of functions, how do we do this? So let's just say you don't want to extend this class to the species class. You don't want the species to extend this math class, or you are prevented from doing that. Or let's say that you don't have access to that extension. So you cannot extend that class. So the species cannot extend, because, again, you are given this class as a species class. As this function, you can use it. You can extend it to use it. But you also want to get this class from the math class. And since you cannot alter the species class, it's locked. It's not public to you. And you really want to use its functions in here. Well, you either have to create them yourself, or you have to forego one or the other. And this is where traits come into the picture. Traits come in place. So of course, this class, I assume that you have your own implementation. So you can implement this math class and include these functions inside the plant kingdom. Yeah, the plant kingdom. This is your kingdom. And so you have these functions. And you also want to share these classes, or these functions, and the member of class 2. But you can't, because you can only extend one class at a time. So you have limitations. So therefore, you can say, OK, I want to turn this into a trait. So the trait can work very similar to another class. So with a trait, you can then use that inside either the spruce or the plant kingdom if, let's just say, these are your classes that you create. And this is the only class that you are not allowed to create. You can extend it, but you cannot touch it. So you can put it here or in here, depending on which level you want to use. Let's say I want to use inside the plant kingdom. Then here, you would just go and use it, use the math. So now I use that in here. I can also use an animal kingdom. So you can see that now I have access to all the functions in the species, the functions inside the math, and implement my interfaces all together. So now, and then any other class, any other kingdom that belongs to the species, maybe don't want to use the math class. They don't have to, because it's not part of the species. And if it's not useful to that class, then you don't have to use it. So have a math class. You can have another trait for something else. For example, you can say trait, I don't know, service. I'm just making this up, OK? And the service has a public function that has a really, really service. IT, of course, has no relation to this, but has a really important function you want to use. And so, OK, well, it doesn't apply to the species it does apply to the animal. So you add that to your animal kingdom. So here we go. I have borough some functions in the math, service, and the species all together to my mammoth. So my mammoth now has access to all of them. So m has, you can see, has the service IT, has all the other functions that are special calc, but I did that already. So it gets pretty messy here, but at least you can see where traits are, how they play, a role in your program. And interfaces are as well. Of course, when you design this program, if you are to design a developer, you have this, you had some designing to do. And if you are the user only, if you're given only these interface or these species classes, abstract classes that you are required to use, then you must implement any function in the interface. You might implement any abstract functions. If I have an abstract functions in here, abstract function called solve, for example, that you must implement those in your subclass as well. As you can see here. And again, just the rule. So you have no control over that. And if you want to add more functions from another class or something class you wanted to create yourself and you want to share those classes with other classes that you own, then of course, trait is the solution for that because you can either, again, in this case, forgo the species. Or if you want to use them, then you have to create traits to provide other services or functions to your class. Of course, our assignments will probably won't ever get to this part, but I just want to give you a look up ahead in case if you ever run into a large project and like this scenario. I mean, it saves you a lot of typing, a lot of redundancy, because you don't want to recreate all these functions that are very similar or actually exactly the same in your classes. So I hope that at least gives you a picture of what the complexity of these are, but of course, the power of using classes, traits, and interfaces in your program. So let me know if you have any questions. Thank you.


A test cross is a special cross done with a homozygous recessive individual times a dominant unknown. Mmm, the dominant unknown. Okay, a dominant unknown. That just means that they're showing, they're expressing the dominant phenotype, but you don't know the genotype. So the dominant phenotype is expressed, but the genotype is unknown. In this visual here, they use the letter Y. This is pod color, I think. And again, this is another one where I'm pretty sure that they flipped the colors that we have used with this visual. Sorry, but a dominant phenotype person, or P, could have a dominant homozygous dominant genotype or a heterozygous genotype. And if the critter is expressing the dominant phenotype, you may not know what their genotype is, but you do know that it could be either one. If you run a test cross, oops, not T's, if you cross the unknown individual with a known homozygous recessive individual for the same trait, and then look at the babies, you can figure out which babies, which, if the person was heterozygous or homozygous. And I'm saying persons and peas, it's the same difference. Now look, here we have a heterozygote, here we have a homozygote. Both of them are crossed with a homozygous recessive. All we did is a punnett square. We threw some gametes in there. I do want to say something about this situation here. Sure, go for it. Sometimes it's nice to have four boxes, but you don't need them. Though that second box is extra work, because you only have one possible gamete from the homozygous recessive parent. That's everything. Do you agree that that second column is just a repeat of the first column? I like to save time, and I just figure out what my possible gametes are going to be. And then I save time and only put those possible gametes in. I don't put both possible gametes, even though I know that we're going to have two and everybody gets two. But it's just a repeat, and it doesn't change the percentages. But notice, if the person I crossed with was heterozygous, we're going to have some heterozygous recessive offspring. If the original cross was homozygous dominant, there are no heterozygous recessive offspring. So from that test cross, you can determine the genotype of a dominant critter. That comes in handy. Okay, you are punnett squared. Don't be punnett squared, or be squared punnettly. Don't, what? I'm going to stop now. Okay, goodbye.


Want to kick us off? Sure. Hello, welcome. Hope you're having a great conference. Hope you're here for the what's cooking. This is a deployment with the chef and the open stack cookbooks. So I hope you hear about that. Everybody can hear us all right. It's all good. OK. We'll start off with some introductions. Hi, my name is JJ. I'm that guy. I'm a senior partner engineer at Chef. I am the open stack chef guy. Anything chef-related and open stack-related usually gets funneled through me at some point. Technical resource. So my name is Mark van der Wiel. I'm from IBM. We started using Chef a few years ago when we got involved with the open stack project. They seemed like a good pair to put together. So I've been working on the project for quite a while now and I'm one of the course. So what is Chef? If you don't know, it's an application to be able to provision and control your machines from a centralized repository. It's infrastructure as code. Everyone know what Chef is, so I can just kind of know, yes. So as it says, some of the simple concepts are it uses idempotency and also you'd have state-driven code to be able to make things happen. So you can say, yes, I would like to do package VIM and you run to the Chef client and installs VIM for you. And it uses, as I said, infrastructure as code where you can control things called cookbooks that I'm going really off the topic here. So as you can read, it automates and how applications are configured, deployed, managed across your network, no matter the size. The advantage Chef has over a lot of other configuration management systems is that the Chef client is run on the compute node instead of on a centralized server. So you don't need to expand your master of puppets, if you will, to be able to take a blob back and forth on the machine. So I'll get into what do you get with the current where we're at with this project. This is part of the Big Tent. Everybody knows the Big Tent, right? It's the core projects and everything outside the core projects as part of the Big Tent. The OpenStack Chef cookbooks are in the Big Tent. So you can take a look at them where we participate in the community like everything else. So what do you get with it? The thing with this project that was key to making it whole was, of course, coverage of at least those core projects in OpenStack, Nova, Glantz, Sender, Keystone, all the rest of them, right? So having support for those so you can lay down OpenStack with that type of deployment was the goal of this main start of this project. The other part about this is keeping the overhead down on your nodes, right? So you don't want to have a lot of infrastructure on your nodes to be able to have to manage these nodes. So these nodes are managed via Chef, and it's ChefClient is called. That's an agent that runs on the nodes. The biggest thing that I think that's most important if you leave this room out of anything else is to understand what distinguishes a lot of the Chef design concepts. I'm a designer. I'm a coder, right? I keep designs in my head more than I keep ads in my head of other things. Is the idea of being state driven, OK? This means you run something, right?  Every time you run it, the state will be the same. It's hard for people to grasp that because most people don't code that way. That's not how code is written. That's not how scripts are written. Scripts are written. You run the script. It doesn't work if I run it twice. Oh, you can't run it twice without deleting this first. That kind of thing. All the backlash you have with running things more than once. The whole point of this is trying to be a state driven for your node management. And of course, the other thing about it is that the community has come a long ways with our cooperation with getting into the big tent, as well as moving along with our testing. So we think we've done a pretty good job moving the unit tests forward with these cookbooks so that they're relatively stable. And I can add to that also. Chef is Ruby. It's not Python. That was Freudian. So we have TDD, our test driven development, built in. If you ever use any bit of Ruby at all, one of the tenants of Ruby is test driven development. So we have unit tests. And they are actually RB files. So you can run actual RSpec, or we call ChefSpec, which is a level on top of it, of RSpec to be able to verify that when a converge happens, which is what a Chef client does, it comes out as a state you expect to have. So you can create a CDCI pipeline using the testing. So when you're moving through your changes, i.e. creating an open stack cluster, you can actually, before even running it on a physical box or a VM, you can verify that the thing will come out how you expect it to come out, which gives you confidence in your changes to production, because it'll catch early on in the pipeline. So the next thing is, OK, why would you step up to this versus other types of deployment mechanisms? And the one like you mentioned before is the part of this infrastructure and being tested before you move it. The cookbooks have resiliency in them that drive your state driven deployment of your open stack clusters. The other thing is that I think it's a good and bad thing, and you'll see it later in the slides, is customization. This is a fully customized solution. You can extend it, beat on it, twist it, turn it, and it does have the ability to be conformed to what you really want. And that leads to the last one, that it's customization, but it's beyond customization of what open stack wants. You can customize it also with how Chef works. Chef allows itself to be easily expandable and wrapped, if you will, with other solutions that can go with it. So it's not only customizing what you do in your cluster, but also customizing your management solution. So that's some other things don't quite do that much for you. Talk about our community? Yeah, absolutely. So one of the strongest things Chef has is we have a huge community online to do, to create what are called cookbooks that are literally a collection of recipes to do something. Anything ranging from building an open stack cluster to installing Vim to controlling SystemD and everything between. There's something called the supermarket, which is supermarket.chef.io, which is not on that slide. I should have put that there, which is a collection of places for cookbooks. So if you have your laptop in front of you, you'd probably want to check it out. It's a great way to share cookbooks and have things out there. So with the cookbook community, we have volunteers controlling the cookbooks and administering them. And there's a certain level of, you can have gradients of quality of cookbooks, but most of them are that are out there do what they say, which is amazing. And it's all completely volunteer driven, so which is great. Oh, and we should say that too. Because yeah, we are part of the big tent. We do get ATC. I have verified that. So if you do commit to our cookbooks, which, as part of the open stack community, you can go through the normal Garrett process, and you will get a great ATC. So here's a slide that's trying to tell you the nuts and bolts here about there are good things and there are bad things, strengths and weaknesses. So one of the strengths that I think is one of our most important goals we've been trying to focus on is being production ready. So we have the test cases behind to verify that we can actually use this in a production environment. Speaking as an IBMer, we have used this in three products already. It's shipping. It's out the door. It's in the community. We've shipped it to hundreds of thousands of customers already. Underneath the covers of customers don't even know that it's being used, the chef serving clients under the covers being used by our clients. Hundreds of thousands? Whole bunch of them. Oh, OK. So the instances of the customers are there. And then like I mentioned before, in order for IBM to do that, we had to extend it with our own IBM wrappers, because we have some things that we do slightly differently, but we were able to do that with these customization with the wrappers. And of course, the platform dependencies was key for us, because we decided to use Red Hat for our enterprise solution for the platform of choice for the internals of our products. And we were able to do that. These cookbooks support not only the Ubuntu and the conical side, it also supports the Red Hat side, which is very important. And some Sousa's still in there. Sousa, if you've got Sousa's expertise, we'd love to talk to you. Yes, we would. And of course, you mentioned the supermarket cookbooks. Third-party cookbooks are essential, right? So we don't develop the Apache cookbook. We don't install Apache. There's a cookbook that does it for us. That's out in the community, right? We don't do some of the database, MySQL. There's a cookbook for MySQL. That's used by part of the OpenStack cookbooks to give you the total solution. And of course, like I said, the community strength. We've been doing a pretty good job, becoming part of the big tent, and moving our community forward. As for wheat mixes, we still believe that our cookbooks are too complex for most folks. It takes them a while to bring themselves up to speed to understand the concepts. Not that they're hard. It's just we have a lot of pieces in place. It's kind of like a puzzle. You can put it together. You will see the picture when you're done. But there are a lot of pieces. And can I interject something real fast? We have our PTO. We have a new PTO. John, come on up here. He wanted to talk about the complexity and what we've decided to do for this next release. Yeah, hi. Yeah, especially for these weaknesses. The complexity is, I think that's one of the biggest problems. So as Mark and JJ already said, it's easy to add something like wrap cookbooks, add a lot of community cookbooks, add another layer to that via environments, roles, whatever. So you can really easily customize what you're doing there. And we did that for some years now, which in the end, right now, put us in a place where we really have a lot of layers, where you can configure everything. But that makes the whole thing very, very hard to understand. And although it basically has a lot of switch cases for all the platforms, you can deploy RedEd and SUSE. And you can use MySQL and Postgres and DB2. You can do the most, the craziest things with it. But it's hard to understand. And we want to really bring that down to covering the most cases, or this idea of covering 80% of the cases, but just 20% of the code. So really putting out all of that stuff that is not needed by most of the customers and moving that to somewhere else. We're still talking about that. Tomorrow we have a session where we will talk again about that. But we really want to make it easier to use these cookbooks and to throw out a lot of code. Thanks, John. Thanks, John. Yeah, and the bottom one on there, of course, like you mentioned before, is this is Ruby code. So obviously, if you don't know Ruby, but for me, I've coded in how many different languages, right? To pick up another language is not that big a deal. So if that's your stumbling block, then I think you've got other things to worry about. The other part that I put on there is individual projects. The cookbooks is not one project. Like the rest of the cookbooks, there's Nova and there's Nova. No, for the cookbooks, there's a separate project for every corresponding project in OpenStack. So there's a Nova cookbook and a Cinder cookbook and so on. So that also tends to lead to a little more confusion because you have to manage more projects. Yes. So this one right here, I figured I would bring up pretty early on in the conversation. Because a lot of people wonder, so why not use Ansible? Why would you use Chef? Well, not only as a Chef employee, but as a community member of our community. I believe Chef is a superior product for this.  Because I haven't been able to figure it out.  You can't rerun it. You can't verify the machine is in the state you want it to be in. Chef, it's all built in. The Chef, you can actually, as Mark was saying earlier, it's idempotent. You can run the Chef client as many times as you want to get the desired state. Ansible, you can't do that.  Could they continue on that flame more here? Yes, exactly. So why not Puppet? Have you looked at the Puppet manifest recently? So even Infra, as of this summit, is talking about using masterless Puppet to do their deployments. So the major thing, it is literally called a Puppet master where everything stays.  Unlike Chef, which I said earlier, where the compute is actually done locally on the box, that it's going to be told to do the thing. So it's a scaling problem. There with Chef, you can do thousands and thousands of nodes, but there's a point in Puppet where your Puppet master will fall over, and then you have to build an infrastructure around your Puppet master. All of a sudden, you have three or four boxes as a Puppet master. The Chef server is just, in essence, a S3 endpoint where it pulls down, makes sure it's in the state that it needs, and then converges everything locally. I'm sure we'll have questions on those two for you later. Oh, I bet so. So keep those in mind. So let me go into a little bit of the details of how this thing kind of works when you actually run it. So there's the notion of a Chef server. And the Chef server, like you said, is basically an S3 point. It's basically your data point for all the information that the Chef client would need, which would include cookbooks, things we call environments that describe your topology, things that the roles that describe what's within your topology. I have a database server. I have a compute server. I have a network server. And then you have data bags, or basically containers of low-level bits of information, like how are you going to set up your user at Eastern Passwords? Are they going to be just floating around on the clear in some script file somewhere? No. You want it to be under control somewhere and gather together so you have all your essential information at the server level. The client is basically then just a user of that information to set up, to move your client, your node into the state you described up above. So if it's supposed to be a network client, it has a network role. It runs the network role with the recipes behind that. And boom, you get a network client. Underneath the covers, there are some other pieces that the Chef client uses. And one is OHI. OHI is another really cool thing I think that distinguishes Chef and how we do things differently than other folks is that it discovers the basic information about your node. Where I see other clients, they have to go out there and do this manually, or have other scripts to do it. OHI will know some of the basic informations about the node, the IP address, how much memory it has, how many CPUs it has. All these little pieces of good information are pulled right automatically into your Chef client infrastructure. So it's kind of nice to have it there, because then you can base your recipes off of that. And I'll talk one more here. And then I'll turn it back to you on the other one. So we basically have this. This is the projects that are out there today. So we have something called the Chef repo. It's our gathering point to bring all the cookbooks together. Like I mentioned, we have separate projects. Those projects are called cookbook, open stack, common is a common one that we have that kind of put some common code together. And then cookbook, open stack, nova, computer, whatever the rest of it might be. These are specific to those particular ones. And then of course, we have some other cookbooks we bring in. We have some wrapper cookbooks just in our own implementation to wrap around the database, or wrap around the messaging server. Because we don't know what messenger server you might want to have. Do you want rabbit, or do you want something else? The database, do you want MySQL? Do you want ProScratch? What do you want? We don't want to hard code that in our cookbooks anywhere. So we've wrapper the community cookbooks that support those with our own wrapper cookbook. So you can kind of see this hierarchical thing trying to form in your head, right? We have the repo, we have all the project cookbooks, and then we have some specific cookbooks that wrap even community cookbooks. So it's quite the scheme of how this works, but it comes together with the repo. So the open stack Chef repo is the thing that if you have any interest at all in this, this is where I'd probably like you to start. This is an all in one blob of the data you need to build an open stack cluster on your laptop. So if you have ideally 16 gigs, but you can get away with eight, vagrant and virtual box, you can actually, we have rake tasks and documentation on how to build with using the community cookbooks on your local machine a open stack cluster. It can be all in one, or it can be multi-node. So you can have multiple compute nodes after it with a controller with the network node inside of it. It even has neutron support also. If you're in essence, it's Chef Stack, right? It's Dev Stack running with Chef. And it uses right now the packaging from upstream. We haven't done it from source yet, but we are thinking about going down that path. The second bullet point is also important. Basically, there's a lot of people out there who want to just have an all in one build so they have an extra desktop sitting beside their computer or they've depreciated value in their desktop and they're getting a new one. But they still have 16 gigs. Well, we have documentation called all in one bare metal.md inside the Chef repo that will actually teach you from absolutely nothing to having an all in one build of Kilo right now from the ground up. So you can teach you how to use Hosted Chef and all the major portions of the Chef ecosystem. So you can actually see it. We're planning on adding multi-compute to it also. So you can horizontally scale out with multiple compute nodes. And then also, off of that, I'm planning on writing some documentation on how to teach you how to use the Cookbook Test Kitchen, which is part of the Chef ecosystem with that compute, with that Open Stack Cloud that you build. So some nuts and bolts here about how this kind of works.  The first thing, right, check out the Chef repo. That project is the umbrella project that brings all this together. What do you need on your laptop to get this thing going? The cool thing about this, but I think is another thing that I can debate Python Ruby. You can do that all night. That's fine. I'll have beers with you if you want to talk about it. I think it's great. It's a great conversation. There is this great new thing that they came up with that Chef that's called the Chef DK. It's a development kit that encompasses more than just Chef stuff, right? It puts Ruby inside there. And some other tools inside there. So basically, if you install the DK, you've got all the things you need. You don't have to go searching around and try to figure out what other packages you might need to install. They're right there. And in Ruby, they call them gems, by the way. Can I just jump in real quick? Yep. And with the Chef DK, it actually, for instance, on a Mac or a Linux box, it installs it under Opt. So it doesn't mess with your system Ruby. It has its own embedded version of Ruby and everything. So it's its own entity. So you don't have to worry about dealing with gem files you may have heard back in the day of Chef or whatever. It's all self-contained. Right. So that's a big key. You can start it right now, and it's not going to blow up your laptop or anything like that. It's pretty straightforward stuff. And then, of course, I mentioned like Linux Windows Mac is all there for this to get your development started, whatever you choose. The other part that we've been working on really hard in the last couple of releases is testing. Testing is done with make files. This is a Ruby make file that runs. We have our standard tests, like almost all the other projects have, some type of a lintest style test. And of course, we're working really hard to get unit tests fully complete. We've got quite a bit of unit test coverage right now. The big thing we've added lately is integration testing. So we're actually eating our own dog food here. We're making sure that when we run the tests, it's running against the actual stack that we put up there. We call Chef Stack. So what we're doing there is we're actually staying up our own all in one inside infra as a gate, and then checking to make the basic things work with temp business like that, run some basic tests, make sure things are up and running. So that's been a big thing. It's kind of cool that now we're actually, we've got gates that are running like the other folks in infra. You'll see everybody else is running Dev Stack to set up their open stack and then run a test against that. Well, that obviously defeats the purpose of using Chef to do this. So we're setting up our own stack in the gates, but Chef Stack. So that's clear. But that's what we're doing. And that was a big leap forward. So we're taking care of making sure that when things change, we're testing it, at least for the first part, for the all in one. Just to continue on with that, we did this just recently over this last cycle. We started this in Vancouver, and we were joking about it at Vancouver, saying, oh, this is probably going to take us a whole cycle to do it. But as soon as we sat down with the infra team, we discovered that it was literally just us hooking some things up. And all of a sudden, we're able to build everything we want locally. And this is important, because any change that you put into the cookbooks, any attribute change, anything you do, we have a non-voting job that makes sure everything it verifies. And then we even, as we say, run Tempest after it. So we actually verify that the machine, the OpenStack Cloud you just built and made the changes for, Tempest passes. Granted, we need to better Tempest tests, but we'll have that sales pitch in a little bit. So there's some other related products that GED is the owner of. So I'll let you know about those real quick. These are the three main integrations from the Chef ecosystem into OpenStack. So instead of the builders of OpenStack, consumers of OpenStack, we have a knife plug-in, which is Knife OpenStack, which basically is the major, I want to spin up a machine inside of my OpenStack Cloud. We have Kitchen OpenStack, which allows you to use the kitchen driver, which Test Kitchen is the integration testing framework for Chef to be able to spin up multiple machines or one machine inside of your OpenStack Cloud to make sure that it shows up how you expect it to. And then we have Chef Provisioning Fog, which is a little bit more, it's a resource to be able to declare clusters and multiple machines inside of your OpenStack Cloud. So if you want to spin up three machines and make sure that three machines are always there, you can write using Chef Provisioning Fog to make sure it shows up how it does. You haven't seen Chef Provisioning. Check it out. It's pretty cool. So just some references here that, like the other projects, we have a wiki that we've been trying to update and keep the documentation there for the basic development, how to get started, how to contribute, how to help out. We have meetings, of course, they're right there. We have an IRC channel come and talk to us. And of course, we are on Launchpad like the rest of the projects. All of the projects underneath I mentioned before, the repo, all the specific cookbooks, are underneath one Launchpad group called OpenStack.Chef. So now we'd like to leave time here, so you guys can ask your questions about where we're at and where we're going. We'd like to have a conversation because there's a lot of people out there that believe that Chef is extremely complex and challenging to use. And we'd like to have an open discussion about it, see what we can do better, or maybe stumbling blocks or anything. Anything? Paulo, I'm looking at you, buddy. No, go ahead, Matt. What is the coverage for the various OpenStack projects? I mean, do you have Heat, Morano, all those other things? That's actually a great question. We probably should have put that in the slide. So we have all the main core projects. And this release, I'm planning on getting Magnum and, was it Manila, I decided? Or was it something else? I think it was Manila. Manila. Those two projects. But all the core main projects, you can totally build off the ground. And that includes Heat. And the Heat was? It's not part of the circle. They're short on their maps. They moved, Heat moved outside. But Heat is already there. Orchestration is there. And then, Ironic, Bare Metal is there. Boo. So we have those there. And we also have some Docker integrations parts there, too. So those other pieces are already there. And then there's starts for cookbooks for both Trove and Sahara. They're started, but they're definitely not complete yet. So that's, if you're really interested in those, let us know. We can help you work on them. I don't think it would take that much to flush those out. It's just that it's not been our priority at the moment. We are trying to make the priority as Jan was saying during this next cycle is to make this more accessible to more people. We acknowledge that these things are complex. And we are trying to make it more accessible to more people so they can just build an open stack cloud how they would like to build. There was a question back here. I'll just leave this out here. Sorry, I joined a little bit later. But we are using in my company, I'm working for a German telecom. We are using a lot of Chef. And the main problem we have is how to package the cookbooks, how to manage the life cycle of the cookbooks to get them through a development or QA pre-production, production environment. And to guarantee that the cookbooks that were used in one phase, we are the same in the next phase. How do you manage this? So there's a handful of different ways. Off the top of my head, there's just simple version and pinning to make sure you're adamant about your version pinning. There's also policy files, which is another option, which we don't fully support inside of the open stack Chef project. But I can take that conversation offline with you. But when it comes to open stack Chef, the version pinning is how we do our things. Master right now, we don't version, because we're constantly moving it forward. But as soon as we stamp something as stable, QO, stable, whatever, then we have a very strict sumver policy that we actually put inside our wiki to tell you to make sure that you get exactly what you expect to have. So we take version pinning quite seriously. Yeah, for the IBM project that we worked on, we did it a couple of different ways. But the main way we had it is we basically had our own copy of the repo. And we had our own locking mechanism there to lock to the commit levels, in addition to just the version levels of each cookbook for every branch of the product. Yes, that means you have quite a bit of branching going on. But none of those branches, though, were forks. They were just branches pointing to something in the community. So that was the key, is that we weren't forking anything. We were just keeping track of, OK, we shipped out a patch and it used that set of cookbooks, and we could track it that way. And then on the internal side, we could use that as a tracking mechanism to fuller understand when something goes wrong, people can bring down the exact set of code again and take care of business. If you want to know more about that, I can talk you offline about that, too. OK, one of the traditional drawbacks used to be the complexity of installing the workstation, in addition to the server and bootstrapping the nodes. So what's the difference between the old Chef binary, the old workstation package, and the new ChefDK one? What exactly does it make simpler? Absolutely. So the ChefDK is, if you actually go to the old workstation wiki page, which we're not still out there, which we need to fix, the ChefDK is everything you need in that workstation as one binary. So it has all the testing, all the Ruby, everything locally there that you need. So the workstation, in essence, is just an install of that. It makes life much easier and allows you to get everything you need to get off the ground as quickly as possible. The key management can be answered in two different ways. If you're running off of hosted, there's actually a Getting Started button now that gives you all your key management you need and even creates a validation key for you. But if you're doing local or doing an on-premise Chef server, you'd actually use the same process because hosted and the on-premise server are the same thing now. Yeah, just to iterate, too, that what happens during our integration test, right, is integration step one, load and install ChefDK, step two, run the test. I mean, that's all it is. We don't have to worry about whatever else is on the machine. Just run ChefDK install, and then we start running our test. That's as simple as it is. So it makes it very nice. Though that's right, yes. And in 12.1 of Chef, you don't need a validator pen because it uses a user name to validate against it now. And you can see some examples in our repo about how we put together some of the data bags and how we're using the keys just in there. It's a way to get started. They all in one build, all in one bare metal build that is inside the Chef repo. I challenge everyone to go take a look at it and attempt to try it. I've had multiple people go through it and be extremely successful with it.  And then as soon as you understand it all, you can actually blow it away, start over again, and you'll have it in less than 10. So less than 10 minutes, you can have an OpenStack Cloud running QA right now. We'll have Liberty soon. We're in the process of doing that to get it stamped where we're gated by the distributions and then the packaging. So that's why we're always trailing a little bit behind, because we're not doing it from source. We're doing it from the packages. But still, we try to stay as close to that as possible. But yes, I do challenge everyone to try to build, to the AIO bare metal build. Other questions? Yeah, I'll just start on the summary here then if you have something to let us know. But the basic we're talking about here is a project that has been growing. And we're learning from our mistakes. And we're growing. I think we're getting in a better way. I said, it grew in such an enough way that even IBM picked it up and said, this is to the point where it can be used in production for a customer. And we actually did that. And so there weren't, it wasn't perfect, but it worked. And it's been, it was quite a good story, I think. Especially since, like I mentioned, that a lot of folks I've seen there are forking the Copics internally. They want to mess with it and mess with it. And boy, I put my foot down really hard to say, in IBM, we are not going to, because we, that was our first attempt at the first team who started at IBM that did some of the chefs up. They forked all the cookbooks. And they were off in La La Land, masking changes. And I'm like, well, what good is that if you haven't worked with the community on making it better? So I put a stop to that. And it worked really well because now I became core to make it better. So I had to work my butt off to do it, but it was awesome. So, and that brings me to the growing community part. That we're always looking for feedback, good or bad, on the cookbooks, any solutions or any questions you have, we'd like to, a challenge is always good for me. And like I said, I think we have a pretty good future. As Jan, our new great PTL, we got going here, we are going to try to address the complexity issue with how the cookbooks work. That shouldn't scare you away. I mean, complexity is the thing we see with a lot of things. But I think, and I think you will see an evolution happen with how we address these things in cookbooks. We're going to take a different approach to how we look at the cookbooks in terms of trying to solve a configuration for everybody, try to make a configuration for the 80% of the users, and then other folks can add on what they want as they need. But don't let that complexity drive the main branch. And that's been tough because the history of these cookbooks came from a spot where they were trying to solve everything for everybody almost. DB2 support. And then, yeah, that's my bed. Sorry, I'll take that right on the chest there. That's DB2. If you're a DB2 guy, let me know. I'd like to talk to you. But no, DB2 is not part of the issue anymore. It's magically going to disappear from this particular project. And just to pair what Mark is saying, we are looking for more people to be involved. Our community is agile. The advantage of being small right now is that we have a core group of people supporting this. And we like working together and pairing and making things happen. We would like more people to be involved. And also, feedback. We desperately, desperately need more feedback. We know we're building stuff. We know people are using it. People just aren't telling it that it's broken or telling this it's successful. We need any type of feedback. We are on the official mailing list. We have bug reports. And my job is to make sure that the stuff is and I am the open stack chef guy, right? I am supposed to help make it forward. And with Jan now taking the PTL, we can move things forward. And I guarantee you, if you put up a patch, I'll be the first one to negative one it. It's true. This guy, he's brutal. That should thrill you, right? Because you're going to get that feedback. I'm pretty good at giving negative ones out right away, just to introduce you to the community and say, great job. And fix that typo. And maybe I spelled it wrong. So it's all good to get the bloods on. He's legitimately made me abandon multiple patches because I just couldn't do it. Sorry, I have one more question. You said that you use it in production right now. Are you handling the hardening of the hypervisors with the Chef cookbooks? There's the system level hardening. Yeah, probably I can answer that, especially for the telecom because we have also worked with. You're great. Yeah, we have also done that. The telecom laboratories actually in Germany especially have done a lot of cookbooks. And we are using actually the official OpenStack cookbooks with these hardening cookbooks. So it works perfectly. You are using the hardening of the .io from telecom. So it's basically just another layer wrapping everything, including the hardening, works perfectly. And the only feedback, and I know this sounds weird to say out loud, but the only feedback I ever get about these cookbooks is, well, they just work. And you think we'd be proud of that, but we know we can make this stuff better. And we want more feedback. Just works doesn't help us make it better. It works. That's great. But we need to know what we're missing. The container story I know is huge. Everyone's starting to love containers. So we're starting to move in that direction. We have support for the Nova Jocker driver. But with Magnum, that's my personal goal, is by the time we get to Austin, I'll have a Magnum cookbook that I think our community can be proud of. And with that, thank you for coming. Appreciate your time. Have a great conference.