And it's people of the peaceful sea in the lands and lives it touches, their meaning to us and to the generations to come. The Pacific Story presented by the National Broadcasting Company as a public service and dedicated to a fuller understanding of the vast Pacific Basin. This broadcast series comes to you as another feature of the NBC Inter-American University of the Air with drama of the past and present and commentary by Owen Lathamore, authority on the Pacific and director of the School of International Relations, Johns Hopkins University. China is China. For 50 years China has been a victim of Japanese aggression. For six years China has successfully fought Japan. With the avalanche of events in the Pacific since Pearl Harbor, China has become more important to us than ever before. To win the war in the Pacific, we must have the friendship and the help of China. But China is not only great because she has successfully fought Japan for six years, nor because of her 450 million people. China is great because of her history and her culture. Six hundred years ago, a traveler returned from China with tales of such wonder. Our benefit is your return, Marco. You honor us beyond what we deserve. Where we are your friends and relatives in whom better could be feast than you. But for our diligence and proving that we are not imposters, you further ego on all Venice would have turned us away. For 16 years, 26 years you were gone. How could we know you? Even my own relative here, Gian, refused to admit us to our own house. Oh, but your clothes were coarse and tattered. And the Marco Polo I last saw was not more than a boy. Gian regarded us with suspicion and the dogs barked at us. I should not have recognized you. Your father, Nicolo, and your uncle, Mafio, looked like wayfarers. That we all are. No, no, no, no. Such splendor is those crimson robes you wear. We of Venice have never seen. Ah, they come from the court of Kubla Khan, a court more wondrous than that of the doges of Venice. Kubla Khan, in the borrowed land of China you visited, yes. They are gifts to my father, my uncle and me. Crimson robes of velvet and damasque and satin thought to riches. China possesses riches greater than any land we saw in the 26 years of our absence. For currency they use paper money. Paper money? Money made of paper? Yes, Federico. Even our city of Venice here, a trading and banking city, is not so far advanced. Oh, but your money made of paper? I do not understand, Marco Polo. It is printed in the city of Canvalu. They print pieces of different sizes, each of which has a different value. Of these, the smallest pass for a half a ton watt. The next size for a Venetian silver cloak and so on. Some are for two, three, and even as far as ten Byzantium gold. Oh, but Marco Polo will tradesmen accept this paper currency? Yes, Gian. It is circulated in every part of the great Khan's dominions. All his Majesty's armies are paid with this currency, which is to them the same as if it was gold or silver. Money made of paper. Oh, and far off China, mechanical devices superior to ours are not lacking. Water clocks are found on bridges. Astronomical instruments are in constant use. And valuable minerals are mined.   Yes, and it gives off an uncommon amount of heat. The Chinese dig it out of the mountains and burn it like firewood. If you supply the fire with these stones at night, you will find them still a light in the morning. Well, perhaps they are not stones at all. Ah, the earth is rich. And from it come not only these black stones, but here. Look, you here. You cut open the seams of your old garment. Those are where the garments you wore when you came to my house and tattered. The same. You have something hidden in the seams and the pleats. Look, rubies, sapphires, and diamonds, emeralds, and pearls. You bought these jewels from far away China? Oh, it must be a land of surpassing wealth and wonder.   Marco Polo returned to Venice from China in 1295, nearly 200 years before Columbus came to America. China then was far ahead of Europe. For China has the oldest living civilization on earth. Egypt and Greece and Rome rose before the birth of Christ but fell. China has lived 5,000 years. So the Chinese built the Great Wall of China, the greatest continuous fortification ever erected. So the Chinese built the Grand Canal, the longest artificial waterway in the world. So the Chinese built peaking with corks, palates, gardens, marble bridges. Discovery's invention flowed from China to the rest of the world by Camel Caravan. 200 years before Christ, Camel Caravan, laden with silk, crossed the deserts from China through Turkestan, through Persia to the shores of the Mediterranean, and on to the powerful Empire of Rome. By Camel Caravan over this long, long road, then the two mightiest empires in the world were linked. The making of silk is known to the Chinese alone. By the time the silk of this Caravan reaches Rome, it will be worth its weight in gold. China manufactured silk for 1,000 years before craftsmen and other lambs learned to make it. China gave the world tea. China gave the world porcelain. And China gave the world a product which has become a keystone of civilization. In AD 105, a Chinese artisan named Sailun reported to his emperors, for every day purposes, silk is too expensive for writing, and bamboo is too heavy. Thus, I have contrived to make this product of tree bark, hem, rags, and fishnet. So range, have you succeeded? Here, Your Majesty, is some of it, paper. You made this? Are you able to write on it? Yes, writing on it is very easy. Here is a piece with writing on it. Delicate to the touch. It's strong. I'm able to make as much of this paper as I have supplied. Excellent. With this paper, it will be... Sailun put paper within the reach of all, from king to commoner. Without this cheap paper, printing could hardly have come into general use. And printing, too, China gave to the world. This Buddhist sacred text I dedicate for free general distribution in order in deep reverence to perpetuate the memory of my parents, sign Wang Qi. They, an expert, examines this world's oldest existing printed book and says... This book, beautifully printed in Chinese characters, was published in the year 1868 by Wang Qi. It was done in black printing in which a single block of wood is engraved for each page of the book printed. 173 years later, in 1041, another Chinese, Qin Shen, invented separate movable type. The famous Gutenberg Bible was printed in Europe in 1456. So, you see, China was printing with movable type 400 years before the rest of the world and with black printing, 150 years before that. Printing and paper. Both gifts of China to the world. Up to the year 1800, more books were printed in China than in the entire rest of the world put together. From China also came gunpowder. In 1232, when the Mongols laid seeds to the north China city of Kaifeng, the defending Chinese hurled explosives upon them. They're not second with panic. Order them back. Do they like their flume for their lives from the heavens breaking thunder? Order them back. Dad? World gunpowder. Without gunpowder, modern war would be impossible. But so also would be great construction projects like the Panama Canal and Boulder Dam. China gave the world luscious fruits, the peach and the apricot, the grapefruit and the lemon. China gave the world the chrysanthemum, the tea rose, the camellia. And China set an example for all the world in the realms of literature, art, philosophy, and government. That attracted the European world to China in the 18th century. So self-sufficient was China that at the time of the American Revolution her emperor Chen Lung wrote this message to King George III of England. Our celestial empire possesses all things in prolific abundance and lacks no products within its own borders. There is therefore no need to import the products of outside barbarians. But now on the eastern coast of North America, a new nation was taking form. A nation of rugged, enterprising builders and trainers. On George Washington's 52nd birthday, February 22nd, 1784, this nation made its humble entrance into the Pacific. Then the main cells and the opposite cancels. This is the Empress of China, a 360 ton privateer under sail for Canton, South China. Yankees making the 13,000 mile passage from the newest nation on earth to the oldest. Yankees sailing a vessel hardly larger than a cockle shell whose strange, mysterious Canton, the only Chinese port open to the western world. Will you go with me, sir? Yes, I did, Shaw. I will be making port tomorrow. There are several things with you as a supercar goer should know in carrying on your commerce with the people. I know they regard us with suspicion, sir. More than that, Shaw. They will not treat you as an equal. They believe they are the only true and civilized people on earth. And Shaw, we are here for commerce. I understand, sir. We are here to bring back their teas and silk. Keep that in mind and all your transactions. Will you go with me, sir? No, I'll send one of them in. But remember, we are the first vessel of the United States to visit China. Your success or failure in dealing with the merchants will largely set the policy of our future. We can't leave this part of ground here in the waterfront. We're foreigners here, remember? That's their role. But this here isn't much more than a meter. That's one quarter of a mile square. After six months of tea, they can find us to applaud a quarter of a mile square. We'll land it all. This is the only port in China open to foreigners. Canton here? Yes, Canton. And this is the only season in the year when landing is permitted. Winner. We might just as well as steed aboard ship. Cold and wet here. They're not anxious to see us. They feel they're doing us a favor. That's why we must deal with a kohang. A kohang? That's a special body of Chinese merchants. Captain says they're respectable men and intelligent and they're exact encounters. Don't come along. This is no pleasure. You don't even have time to look. Well, we have an appointment. A kohang, a punctual. They value themselves on maintaining a fair character. Well, the captain says we can be none the worse for watching us. The relationship between China and the West was changing. The first Westerners sailed to China for luxury goods. Tea, silk, and porcelain. The British dominated the China trade until the beginning of the 19th century. Then down the ways of New England shipyards slid a new and formidable type of sailing vessel. The American clipper, into the keel and ribs and masts of these swiftest of crafts, went the sturdy and stalwart timber of the forests of Maine. Across the seas they went. The tea clippers, the China clippers challenging Britain for the trade of China. A remarkable change was taking place in Britain and America. Perhaps the most notable development in all the history of mankind. The Industrial Revolution. Within the space of a few years, man's ways of working, thinking, and living were changed. Our graves invented the spinning geni. Artwright invented the spinning machine. What invented the steam engine? Artwright invented the spinning loom. Whitney invented the cotton gen. The effects of the Industrial Revolution spread throughout the world and made themselves felt in China. Britain and America competed for the China trade, but no longer for the luxury goods, tea, silk, and porcelain to bring back to the West. The rivalry now was the selling of the products of the Industrial Revolution to China's millions. China resisted, but we insisted. We demanded they open their markets to western goods, especially cotton textiles. By the early 1800s? It's not only our clipper ships, it's our products. Your Yankees have offset a disadvantage. There, we've taken half the Kentown trade. You'll not have it long. We British merchants have demanded the privilege of free trade. We've been hamstrung by the limitations of the East India Company, but now the king has taken measures to correct that. His Majesty is guaranteeing protection to any British merchant. And what do you reckon that's going to mean? Nothing to your Yankees. To us, it will mean that we will no longer deal with the Kohang, but directly... That Chinese will never agree to that. His Majesty has already sent representations for the Emperor and Peking into the Viceroy here in Kentown. This means that in the future... One other factor complicated the situation. Along with their manufactured goods, British merchants sought to sell opium brought from India. Free trade meant the unrestricted selling of these products to the Chinese, prohibited by the government of China. The tension grew. The Chinese stood firm. Incidents ensued and violence flared. Hey, hey, John Chinaman. Come on, get into this doorway. You want to get shot? I've only tried to get home. Be generous out there. Have you ever broken out all along the coast? Yes, I know. You don't seem to be very thankful that I pulled you out of the way of those bullets. If you were not here, it would not have been necessary. Hey, look, I'm American. This war is with the British. You are neutral, as the French are neutral. But you are here for the same thing as the British. You will participate in the concession they hope to ring from us. Oh, no. Now look, we're here to give you the benefit of all the advances we've made. Why, it's just horse sense to see business. The Treaty of 1842 became the western world's foot in the door in China. Hong Kong was ceded to Britain. Five Chinese ports were opened to the western world. Canton, Amoy, Fuchiao, Ningpo, and Shanghai. The Chinese agreed to treat the British as equals. And extra-territorial rights were established. The year after the treaty, the United States requested and got the same extra-territorial rights. And soon after, other nations secured the same rights. The Opium War marked the beginning of the gunboat policy. The policy of western powers protecting their interests in China with gunboats. The Opium War marked also the decline of enlightened China. 1842 was satisfactory neither to the western powers nor to the Chinese. The westerners said, What does it grant us? The Chinese don't permit us to travel in the interior. The treaty didn't grant us enough. And the Chinese said, The treaty was extracted from us by force. It granted too much. And we will not regard the foreign barbarians as equals. The treaty said nothing about opium. And the traffic in the drug continues in defiance of the prohibitions of the Chinese government. 16 years of troubled truce. The western powers pushing for greater concession. The Chinese resisting. And then again, violence flared. The French have joined the British against the Chinese in the driving with all power on the capital. The British and French have taken Canton, Canton. And today they took the Chinese capital Peking. The Chinese have asked for terms. Those Chinese had nothing to fight with. They had to give up. With each year, weakened China suffered ever mounting pressure from the outside world. Russia sees part of Chinese Pakistan. Japan sees the Luchu island. France sees authority over Britain. And next up a Burma. Japan attacked China. And China ceded Japan for Moser and the Pescadoras islands. China had been forced at the point of a gun to yield trading ports to the westerners. Had been forced to permit traveling in her interior. Now the westerners closed in on her. As wolves closed in on their leader once they find him weak. One by one, her outlying provinces were seized. And now the interior she had so zealously defended was divided into spheres of interest. Germany claims Shantung as its sphere of interest. France claims Yunnan province as its sphere of interest. Britain claims the ancient valley as its sphere of interest. Rivalry for the prizes of China ran high among the encroaching westerners. And the man in the streets said, Far right in those spheres my foot. You know what those spheres of interest mean, don't you? If China is partitioned those are the parts those powers are going to grab. Intellectual leaders in China became alive to the faith that the system and cries for reform echoed throughout the land. Extremists rose. The empress Dowager seized power. Ordered all foreigners thrown out once and for all. Again, violence flared. A boxer rebellion. Guns thundered through China's great cities. The westerners against the Chinese secret society, the patriotic union of fifths. Blood and sorrow and suffering and death. And when the last gun was stilled. China is at the mercy of the western powers. They prostrate as the 19th century drew to a close. A head lay a new century. A head lay new struggles to achieve two things. To free their country from foreign control. And to build within their country a government representing the people. To clarify these spectacular events. And to tell the meaning behind them. The national broadcasting company presents Owen Lathamore. Authority on the Pacific, who for many years lived in China. And director of the school of international relations, Johns Hopkins University. Mr. Lathamore. China has the oldest living civilization in the world. The ability to read and write for instance is one of the fundamental necessities of a high civilization. Now, in spite of the fact that they had a system of writing for more than 20,000 years, the percentage of people in China who can't read and write is much higher than the percentage in a new country like America. That's true of course, but why is it true? Well, one very important reason is that China has never had a machine industry. The Chinese did all their work by human labor. People who do all their work with their own muscles don't have time left over for education. You can check this by looking at Europe and Russia. Before the Napoleonic wars and the industrial revolution, the percentage of illiteracy and ignorance was as high in Europe as it is today in China. Before the Russian Revolution and the mechanizing of the Soviet Union under the five year plan, the percentage was just as high in Russia. We completely safely assume that as industrial mechanization in China approaches the standards of America, Europe and the Soviet Union, the Chinese will also catch up with us in the numbers of people who can read and write. Then look at it from the other side. What actual advantage is it to the Chinese that they have such an old civilization? There is this very real advantage. The values of culture and being civilized have existed in China so long and so continuously that they have soaked right through the whole people. Even the poorest Chinese with no education is likely to have the bearing and consciousness of being a civilized man. Even if he knows the history of his country and his native region only by legend and folklore instead of reading, still he knows it, usually a surprising amount of it. And he sets great store by things like personal dignity, self-respect and respect for others. This means if you stop to think about it, that he has the instincts and behavior of an educated man even when he is not educated. And this can compare you for a national characteristic in which the Chinese probably outrank any people in the world. I mean the ability to absorb education. It has been my experience and the experience of many others that the average Chinese needs no incentives to education. All he needs is the opportunity. If we combine the two things I have been talking about, the lack of mechanization and the hunger and aptitude for education we can state a very interesting theory. Namely, that the future progress of China is likely to be amazingly rapid because China's lack of certain things is fully matched by China's potential ability to learn how to make and use those very things. Once more we can check this by our own history. One of the stories Marco Polo brought back from China was that the Chinese had a kind of mineral, a kind of stone which you can burn. That mineral is coal. It is one of the most everyday things in our modern life. But in Marco Polo's time the people of Europe weren't much interested in it. The Chinese burned coal because they were short of wood but the Europeans had plenty of wood. Coal was not much used in Europe until industry began to develop. When iron began to be made in really large quantities coal became a convenience. They began to use coal after they had burned up most of their forest. They called it for a long time stone coal to distinguish it from charcoal which was the old standard fuel of industry. And then when the steam engine came along coal became a necessity instead of just a convenience. The point you see is that a civilization, a way of life, is a complex. What you add to it must fit into the complex otherwise it is just an ornament of material. When the Europeans heard from Marco Polo about coal it was just a curiosity. But when European life as a complex in all its manifold activities had reached the point at which industrialism was the next logical development then the whole of European economy began to change. That was the industrial revolution. Then back to China we can check again. The old and highly developed civilization had many means rigidly opposed to everything that could be learned from the West. Within a few years of seeing the first steam ships the Chinese began to experiment with the idea of themselves. They did not treat it just as a curiosity the way Marco Polo's Europe treated coal. Machinery and steam power were things that could logically fit into the complex of Chinese culture. In fact it was not any backwardness of the Chinese which disturbed industrial progress in the 19th century. So much a military and political control by the western countries of which America was one. The system of unportraities imposed on China by force a hundred years ago gave the western countries the power to turn the economic life of China to their own profit. They used this power most recently. Under foreign flags in foreign concessions in China paying no taxes to the Chinese government foreign industry and trade were able to defy Chinese competition. The shackles were fastened on China even more firmly after the Boxer rebellion. It is only now as a consequence of their long and successful stand against the Pan that the Chinese have broken the shackles. As a result after the war they will for the first time have a chance to show how well they can adapt the mechanical power of the western world to their own civilization making it possible for that civilization to become available to the whole people in education and in training. The result will be that in 20 years at most China will be able to catch up with nearly 200 years of European and American history. Thank you Mr. Vathemore. You have just heard the third program of the new series The Pacific Story. Next week at this same time over most of these stations the fourth will be broadcast. The new China with drama of the past and present and commentary by Orrin Vathemore director of the school of international relations Johns Hopkins University. You may secure an illuminating handbook of the Pacific Story which gives background information on each program in this series with suggested further reading. This program is available for 25 cents in coins to cover cost of printing and mailing. Address the University of California Press Berkeley, California. The address again the University of California Press Berkeley, California. The Pacific Story is written and directed by Arnold Marquess. The musical score is composed and conducted by Charles Dent. Your narrator, Art Gilmour. This program has been presented by the International American University of the Air by the National Broadcasting Company and the independent radio stations associated with the NBC network. This is the National Broadcasting Company.


So we're here to talk about Podman, otherwise known as Podmanager or the other way around. We've got a few things to share primarily around what's new for Podman 4.0, which makes its presence in the door 36. Just starting off with a quick description from our colleagues. I think this best describes Podman in a single sentence, with being daemon-less, open source, secure Linux native tool designed to make it easy to find, run, build, share, and deploy applications using containers and containers images. So if we look at what we're focused on and for just kind of a quick overview, we'll be discussing the new network stack. We'll be discussing Podman machine and what we have today and where we're headed.  So for Podman 4.0, one of the big changes is a move on from our previous network stack, which was called container network interface and known as plugins, container network plugins and some packaging. Our new network stack is written in Rust with a keen sense on performance and reducing the binary size of our network stack. It really came down to two new components which are both separate GitHub projects. One is called NetEvark and that does all the interface configuration, firewall rules, IP tables, rules and port mapping. And then the secondary component is Ardvark DNS which is a container DNS server that we wrote. And this particular one is geared specifically for proxying as a proxying DNS server as well as being able to resolve, container network names amongst each other. The Ardvark DNS actually replace a setup that we had with DNS mask. And so this replaces that setup and is working quite nicely so far. Okay, so I'll be talking about the core benefits in the new network stack. Why you should care about this. Number one, improve support for IPv6 out of the box. Podman has supported IPv6 to a limited degree for quite a while now but we have had some serious limitations on how you did it. You needed a publicly routable V6 subnet needed to specifically route that V6 subnet to the machine that was hosting Podman. And at that point it would probably work. We've had varying degrees of success. The new stack is designed to work out of the box. We take a public or private rather V6 subnet and we net it the exact same way that V4 works. This is not as technically correct as the previous approach but has massive benefits for working out of the box. It's going to work pretty well. Basically, you don't have to worry about configuring anything. It should start. On top of that, let's see, yeah, advanced DNS support. Container DNS is a very important feature of Podman where basically if I create three containers, let's call them DB and frontend and web. I could have DB ping either frontend or web and by name, that is. So we have a DNS server for all the containers and it allows you to hit any other container by name. However, in the previous implementation we had with the CNI plugins, it was only able to work for containers in a single network. So we've expanded that now and it works with containers in as many networks as you want. And as part of this, we've done a general improvement to how networking works for multiple networks. You can join as many networks as you want with Podman Network Connect and you can now set different static IP addresses, static MAC addresses for the networks you're joining. Significant improvements over there. Speed, we have made the experience of Podman run significantly faster but this change. Turns out that the process of running a container, a sizable portion of it is just setting up the network stack for the container to use. Brett previously mentioned that they were called the CNI plugins or previous stack. That's because they had different plugins to do different parts of networking. So to actually set up container, you'd end up running about five of these. Net of Arc is a single binary that does everything. And because of that, we've actually, this was completely unidentifiable. We made things rather fast. And finally, we have a solid focus on the single node, a solid focus on what Podman needs. The CNI plugins are not actually a Podman project. They were in created to support Kubernetes. And we have had some conflicts in the past where they are doing things that are better for Kubernetes whereas we don't really want those things. We want things that are better suited to running containers on a single node. And eventually we decided that it was better to do our own thing, write our own stack that was just single purpose designed exclusively for Podman to do exactly what we needed. And that is what Net of Arc and Art of Arc are. These two are, we're pretty excited and expect a lot more from the future for them. Okay, now I'll be going over the general process of how networking at Podman works. Specifically with Net of Arc and Art of Arc, but CNI did the same general thing. So we start off inside of Podman, inside what we call libpod, which is the Podmanager library we use. It's basically the heart of Podman. And Podman has just been told to start a container. This only happens on start. If you create a container and let it sitting there, you do not have a network. We only set this stuff up when you were actually running one. And we're going to create a little configuration to handle down to Net of Arc. The configuration has basic information, what type of network mode you want. Mostly we talk about bridge networking where you have a bridge on the host and the container connects to it. But there are also other modes like Mac VLAN where the container is directly connected to an interface on the host. Basically it allows it to get an IP address on the network that the system is connected to as opposed to an internal IP address that gets added. And then once we have that configuration with any information that we need, static IP, static MAC addresses, et cetera, we head it down to Net of Arc. Net of Arc is going to start off by handling any global system of configuration that we need to access the internet. This is mostly CCDLs. We need to enable routing, we need to enable V6 routing, a few other things. Then we're going to create the network interfaces required. Most notably, this is going to be the bridge or a face I talked about previously, but we also have a VET pair, a pair of virtual ethernet interfaces. One of them is connected to the bridge on the host and one of them is connected to the container. And that's how traffic gets to and from the table. And then we are going to do some IP tables configuration to get a network address translation working, what we call NAT. And that's going to allow the container to talk to the internet. There are two types of NAT we need to do. One is a global NAT for the bridge, which basically says any container connected to this bridge, any IP address really connected to the bridge can be translated out to the internet. So that lets general traffic flow, but then you also have port forwarding rules. I can do, say, Podman run hyphen P8080 colon 80. So that means we need a, what we call a one to one rule, which is going to allow that one port to be translated to one specific IP on the bridge. And then we're going to call Ardvark or specifically we're going to add Ardvark configs. Ardvark is a container specific DNS server, but it's still a DNS server, which means it needs to know what IP addresses it's serving and what names are associated with them. So we're going to take the container name and we're going to take the containers IP addresses and we're going to shove them into the Ardvark config and reload it. And once that happens, any other container on the network is going to be able to pay it by name. Okay, so are you going to get Netavark and Ardvark is the next question. The answer is if you are upgrading from 35, probably not unless you explicitly want it. This is a new stack. We recognize there may be potential bugs. We don't want to break anyone's installation. So we are not migrating anyone who just upgrades, who was previously using Podman. If we detect that you have any containers, any images, any pods, anything that at all changed on your Podman from a straight default, we are going to keep you on CNI. If you want to move over to Netavark, we recommend that you do a complete reset of the system with Podman system reset that moves everything, container, pods, images, et cetera. Or you can opt to manually edit the containers.conf config file to change yourself over. But if you are on a fresh installation of Fedora 36, you will get Netavark by default. No migration concerns there. Brent, you're muted. Okay, one of the other big ticket items for Podman 4 is the Podman machine work we've been doing. And just to give an overview here, Podman machine is very similar to the mission of Docker desktop. Right now we're CLI only, but it essentially allows you to use Podman to create a virtual machine that runs a specialized version of Fedora Core OS. And then the Podman command on the host or the Podman executable on the host interacts with the system service running inside the VM. And this allows operating systems like Mac OS can't run a Linux native or Windows, which can't run a Linux native container to be able to take advantage of running Podman. It uses Fedora Core OS underneath. It's sort of a appliance-like approach and probably most important to people right now, no cost, no sign up, no registration. Just use Podman. We support Mac OS via Homebrew right now and it's a simple brew install Podman. In the future, we do intend to have a self-contained Podman package that will do the installation and help you configure your first VM or machine as we call them. It's supported on Windows. We have a guided install now that uses WSL for its virtualization, the same sort of user experience there. You can run Podman in WSL and everything is easy and taken care of. And you can also run it on Linux. Any distribution like Fedora 36 should be able to run it as long as it has Podman 4, its dependencies and Cumule. Quickly looking at some of the features, it's a very easy to use approach. Once you have it installed, for example, on Mac OS, you simply do a Podman machine init and Podman will go pull the virtual machine image down uncompress it, boot it with a specialized ignition file. And when it returns back and says, all right, you're ready to go, you can begin using Podman as you would on a regular Linux machine. We do also now by default map the sockets from the virtual machine back into the host OS. So for example, the system service for Podman, what a lot of people would think of as like the Docker socket is being mapped back into Mac OS so that you can use things like Docker compose or Docker PY to interact with the socket. And then we have default volume mounting and volume mounting, basically the ability to be able to take a directory from the host and mount it into the virtual machine and the containers can then take advantage of it. And the other thing is the port mapping. So when you normally run Podman machine on a Linux installation, for example, it would be common space to say map port 8080 or map port 8000 or anything like that for some sort of web application. We do that as well. There's a little bit of extra trickery going on in the sense that the port mapping occurs both on the virtual machine and the host machine so that you could, for example, curl local host at a port and it would be interacting with the virtual machines containers. Okay, now we transition to Podman's highlights and I think this is kind of what we're here for. Matt, quick time check, we have about 12 minutes. All right, so Podman 4 is our largest release to date. Over 78 new features, large number of bug fixes. You can see the general statistics there. Part of why this has been such a large release is that it's so longer, at least we usually do. Normally we try and get a release out every three months. This one took about double that to get the network stack right. One thing I will note, we only have a relatively small team working on Podman full-time. So not a few contributors, the vast majority of those are from the community. All right, we mentioned the new network stack and took a deep dive in it, but just sort of looking back at it, Matt mentioned the IPv6 support, the DNS support, improved startup time, and the focus on signal node networking. One thing we didn't hit is that NetEvark and ArtVark also work in for rootless users without any significant effort to make that go. We put quite a few new things in for CUBE, some of it came from the community, some of it came for us. This would be relative to the Podman play and generate commands. We now support Kubernetes init style containers, which is a container that can be part of a pod that runs and executes first. It's an excellent use case for having a setup, for example, do some database setup before the actual database container runs is a pretty good use case. We've got new volume support for config maps with PlayCube. We can now also build images on the fly similar to Docker compose. You just need to set up the correct directory structure and have a container file present and Podman will build everything before it brings it up. And then there are new command line options that have been added quite a few to PlayCube. A good, one of the ones that I like to let people know about is the replace. It used to be that if you ran a PlayCube instance, you'd have a pod or more running. And then if you ran it again, it would air out because the name is basically taken already. So, Matt, can you hear me? Yes. Yeah, we have a little burp there. Okay. So the replace command lets you override the name and as such, you don't get an error anymore. It just brings down what was there and puts up the new ones. Couple more coob related things where you now support injecting environment variables from field ref and resource field ref sources. We allow you to set default resource limits with PlayCube. And just as a public service announcement, we'd like to see you stop using Docker compose and our justifications for saying something like that is that Docker compose while is wildly popular is only useful for Docker. While we do support Docker compose, but if you begin using the PlayCube generateCube functions, you'll be working straight with Kubernetes YAML, which allows you to be able to take a workload or a set of containers from Podman and generate YAML representing those in a pod and then be able to push that YAML file to Kubernetes and off it runs. You could also do the reverse, which is to take a YAML file out of Kubernetes and run it on your single node by also replaying or playing a YAML file. We've got some machine improvements. I mentioned some of them in the specific overview earlier, but we mentioned the Windows support for Windows and an installer now on Windows. We've got the volume support in four and four one socket mapping and the ability to be able to change hardware allocations once you've defined your VM. We used to not allow that to occur. Okay, so we also have a number of enhancements for our pod functionality. If you're not familiar, Podman lets you group containers into pods similar to Kubernetes, but this is some cool functionality that we've had for a while, but it's not really gotten the amount of love it deserves and we're starting to change that now. The first things we're doing is adding support for the ability to add volumes, devices, security settings and CCDLs to your pod that will be automatically set in all containers that join the pod. So I can add a volume mount that mounts something into every container in the pod, a shared volume. And then let's say that that volume mount requires that I disable SC Linux. Dan is gonna hate me for saying that, but I can automatically disable SC Linux in every container in the pod so they can access the volume without issues. And this is really just the beginning. There are over 120 flags in Podman Run. I wanna see almost all those flags in Podman Pod create. So you can create a pod that has anything by default. Okay, so Podman 4 was the big flagship release and that was back in February, I believe, but we just last week came out with Podman 4.1. So just wanna hit a couple of highlights on those. We've with Podman machine now, we've got a default volume mount being added. And so what that's doing is mapping dollar home from the host to dollar home in the virtual machine. So if you were on macOS or I was, it would literally be users print body on the host. And within the virtual machine, it would be users print body. And therefore you can take advantage of that by knowing that it's gonna be statically there and you can run it with the container. We put Podman on a diet and we're able to reduce the Podman's binary size by 15% relative to Podman 4.0. We were able to get Docker Compose version two working. If you haven't followed along, the initial Docker Compose was based on Docker PY Python and the new work that Docker's been doing, it's all in go. So we now will support that. And we've done a number of enhancements to build including better support of build kit. So Podman build now has improved support for build kit. And I should clarify here that we are not directly implementing build kit, which is a new way of building containers. More accurately, build kit has a bunch of additional options for building containers that the original Docker build, Podman build do not have. So we're just adding those options to Podman build. We're gonna make ourselves compatible in that way. The biggest things here, we have a bunch of new mount types. Most of these were already available in Podman run, but now you can do cache mounts, bind mounts, tempfs mounts into your builds. You have better control over outputs, including the ability to output directly to a tar ball, directly to a directory, instead of creating an image and then exporting that image. Improved multi-architecture support, you can now explicitly specify what architecture you're getting your base image from, using the from instruction. And some minor enhancements to manifest lists. Previously you had to use the Podman manifest tag, I believe the command to tag them. Now Podman tag does as well. Okay. We are nearly complete here, but just wanna talk about our community. Podman does have a happy, healthy project going right now. We wanna make you all aware that we have a monthly meeting. It's the first Tuesday of every even month. We focus on talking about project news, we do a lot of demos, and we actually ask users of Podman to come present ways in which they use it or side projects that they're working on that are relative to Podman. And then on the odd number of months, I believe, then we have what are known as community tabals. And here, these are basically discussion and problem-solving discussions where they center around features or large bugs that we need to have that warrant larger discussion than just one person going in and fixing it or implementing a feature. We also have an email list for people to ask questions, support things along those lines, and all of that can be found on podman.io. Speaking of which, we'll end here with some of our social media and communication avenues. Again, most of the action is on GitHub. I mentioned podman.io. We also have a Twitter handle and our newly renamed YouTube channel. And that is it. We have a couple of questions in the Q&A. We'll try and get through one or two of them real quick. First one is, what about Podman containers without Cates? Any Podman compose equivalent? So that's what Podman playCube. So basically, we believe Kubernetes YAML files is the replacement for Docker compose. So we want to work with the same way Kubernetes does, same format. Okay. Somebody mentioned specialized Fedora Core OS. Does that mean you're building or we're generating a different Fedora Core OS image or just adding an extra layer on top of the existing one for the Podman machine? We are, right now we are kind of painted with ourself in a corner because we're releasing Podman 4 and 4.01. Yet Fedora Core OS is anywhere from two to six weeks behind. So it takes us, it takes a little bit of time for the Podman packages to make it into one of the F cost streams. However, so we have been making one that include the latest stuff. However, the plan is as soon as 4.01 filters into some of the F cost streams, we will turn off the R builds and it'll switch over to F cost proper.


BCF G2 in the house? CF engine? No? Okay. Cool. So hopefully we won't bore you too much with the intro stuff since everybody's fairly familiar. We're still going to run through it, but we'll make it quick and then we'll start talking about what Provizo is all about. But first, we'll introduce ourselves. So again, this is our sessions on Provizo, which is a goal to sort of standardize vagrant-based Drupal development. I'm Patrick Connolly. I work at MyPlanet Digital back in Toronto, Canada. I guess I'm not a DevOps team, but I work there and just try to help teams create tools to help them self-serve their own infrastructure internally for our projects. I am Howard Tyson, Tizzo on Drupal.org Twitter and anywhere else I can get it. I work at a company called ZivTech where I kind of do a lot of the tech direction and work on a lot of our stack tools and have kind of been really focused on building out our hosting infrastructure and our vagrant stuff and making that as slick as possible. And so I've been spending a lot of time on kind of that side of things. So we kind of wanted to frame this with a little bit of history. So in the beginning of website development, local development was hard because you probably had to kind of set up all the different pieces yourself for LAMP infrastructure. There were endless screencasts on it. Lots of people back then were still using Windows before this kind of Mac revolution where everybody has a glowing apple if they work in tech. So you're probably doing it on Windows, so you just didn't. And a lot of people just kind of went in and used FTP and just kind of said, this whole local thing is too hard. So that was Bill O'Reilly saying, screw it, we'll do it live. Really disappointed after all that. Anyway, so then we started to build tools. We were the monkeys with the bone and that's the sort of tool that we built. And we called it MAMP and WAMP and ZAMP and it worked on my machine. This is a vagrant talk, so we had to have the obligatory it works on my machine slide, right? And you had Drupal running locally, but was Solar running, was Memcache running, was Varnish running, Redis, SSL, Selenium. There were all these pieces that you really needed that you just didn't have. And so for those parts, a lot of people still ended up just developing on production or on something like it because those tools just weren't easy to set up. And then there was vagrant. Welcome to the future. And so that's where we stand today. vagrant creates virtual machines under the environment. Hopefully you guys all know you can kind of provision it with any of those provisioners we were talking about, which led us to this rise of all of these different vagrant projects and all of these different machines. We can just run vagrant up and all of the stuff was working perfectly in rehearsal. And vagrant bundle installs all of our plugins. Vagrant has a lot of awesome plugins. We're leveraging a lot of them in the Proviso project and it builds your system. But this kind of led to this proliferation of lots of different vagrant projects. Kind of an insurmountable and daunting set of overlapping tools and people working on the same stuff. Oh God, there are so many tools and so many machines rising up in this flow where we've got the Drupal Vagrant project, Oscar, Ariadne, Oscar again. Quick start. Drupal Pro, AgerUp, DevShop, Drupal Lamp, the Vagrant DevVM. We've all been reinventing the wheel and we've all been doing things slightly differently but mostly the same. And there hasn't been a place where people have been coming together to start sharing best practices and starting to assemble sort of how is it that this community should be doing this? And what are we sort of trying to replicate? And I think there's sort of an upside and a downside to that because part of the idea with Vagrant is you can use your real provisioners, your real source that's going to be running on production to build your dev infrastructure. If you build and maintain your own dev infrastructure, the thing is that a lot of companies don't. A lot of companies have some sites that run on Pantheon, some that run on Aquia, some that run on the clients hosting. And so there's an awful lot of kind of shared stuff. And there was no way to collaborate and no space for that until now. That's the baby from 2001. Just in case you didn't get that running. So proviso was born. So what happened was a whole bunch of us that have been working on this stuff got together at DrupalCon Portland and started saying, oh, you wrote a little SSH plugin to automatically add your SSH key to SS agent to do the thing. So git would work. I did that too. Oh, yours is kind of better. Oh, but mine does this thing. And we started realizing that there was a whole lot of kind of overlapping effort. And we should kind of pull together and start coming up with ways to collaborate. So what is proviso? It's a community project to assimilate them all. Resistance is futile. If you've got your own Vagrant project, just come on board. So first off, more than anything else, proviso aims to be a community. It aims to start conversations and get us working in a place where we can start to assemble best practices and look at each other's code and start contributing to a common thing. Don't we have a community? Yes, we do. We have especially folks that are working on this kind of stuff. A lot of people hang out on groups.drupal.org slash devapp slash high performance. Those conversations aren't as active as they probably could and should be based on how much time we're all spending on this. But most of the stuff that's happening there is conversing not converging. We talk about, hey, I have this bug on my server. But there's no easy way to sort of replicate that issue to be able to set up exactly what your server looks like and say, let's make a tweak and benchmark in a way that all of us can kind of reproduce. All of us can contribute to. All of us can start to figure out what should a secure server look like? What should a high performance server look like? What's the performance implication of terminating SSL with nginx versus apache versus whatever?  And it's all words. It's not executable. And everyone's doing this when they find it, hopefully they're doing this on their own. Yeah. So the idea is it's code is conversation. So let's see. Oh, right. So the idea is can we kind of follow some of the more recent DevOps best practices of can we have code over documentation? Instead of having a checklist, can we have a chef cookbook or a puppet module that just shows you what those steps should be so that you can look at a working machine? Because if you're building a chef cookbook, or sorry, yeah, chef cookbook or a puppet module, that has all of those steps captured in it in a way that's clearly understandable. Both of those tools have optimized for being able to read and understand what's being specified in there. So that's sort of the best form of documentation because it actually will then run. And it's not a checklist that needs to be maintained, needs to be updated. And you know, you're not missing a step if it works, right? So the idea is if we can pull all of this in, this is such a sales pitch most of this presentation, if we can get all of you guys to come to Proviso and start pulling some of the conversation there, we can start to turn more and more of our best practices into community modules that we can all use and share locally and on our remote servers potentially. So how? This is where we start to get into the technical implementation of how we're trying to tackle this project. So Proviso is an initiative in addition to being a community. It's not a finished product. It is a thing that we are trying to get more momentum on and trying to get more people contributing to. It's not that we don't have code, it's not that we don't have stuff running. It's just that like how we get together and talk about Drupal core initiatives where we think something's a good idea and a lot of people are pushing on it, that's where Proviso is especially right now. So we're trying to work to find the best ways to share because sharing is caring. It's also a vagrant project. So the idea is that teams that need a vagrant development environment can use ours and we can again start to reduce duplicate effort with all of those fricking projects that we listed before that mostly set up a lamp stack. And then another thing is to make it accessible. I don't know if any of you guys have been following the Calamuna guys. They're this dev company that's been working on this project called the Calabox. It's very cool. It is a wrapper around vagrant and virtual box that gives you a one click installer for OS 10. They hope to have one for Windows eventually and then they use Node.js and some desktop-y Node.js packaging to build a pretty slick GUI. So it's kind of modeled after the lamps and the lamps and the zamps out there where you have this like status page that says whether Calabox is running, whether it's got engine X up, my SQL up, whether the SSH keys are installed, whether Solar is installed and running, whether WebRoot is, rating of happiness, it's maximal, you'll be glad to hear. And the idea is that you've got a list of local sites, you've got a list of your sites on Pantheon, you've got a list of the different tools. These are like quick jumping points for things like PHP My Admin. You've got commands so they have some sort of nice wrappers to do things like pull down copies from Pantheon. Some of that stuff is a little still in progress, but a lot of it works pretty slickly. And then the plan is eventually there's going to be a deploy so that you can actually then deploy sites that you've built locally on to Pantheon. Just to add on to that, the idea is like if you're not using Pantheon, they each of these panes, I guess they're looking to make it extensible so that like if this, you need an aquia pane, you work with aquia or there's another tool that you'd like to resurface in there. Yeah, they want to make it so it's opinionated but you can always extend on those opinions or like remove ones that you don't agree with. So the next big component that we need to solve that we're working on hashing out and starting to write code around is exactly how to make this part possible. Because how do we pull a bunch of people together if they don't have quite the same needs?  How do we allow all of that to live under one roof in one project? And our idea is to make sure that there are sort of individual pieces that can be turned on and off and kind of assembled with some sensible defaults so that you can piece together the individual parts. So you can pick your provisioners and you can pick from service packages. We'll talk about a little bit more of what I mean by pick from provisioners in a second to be able to tack on your own pieces and leverage mostly what's already in the community. So you'll notice that Proviso has both Chef and Puppet. Yeah, sure. I guess the idea of making it multi-vendor was I think kind of the original catalyst and it was basically stemmed from all our frustration where we're in the same room of the fact that we're only talking now because we're talking about how we're complaining about how we're not talking and it seemed like one of the roots of why we weren't collaborating on these things and these ecosystems around whether it's like how we're using plugins or little helper scripts was because what we all thought of is the big component, the provisioner, we were speaking different languages. So the thought was that it's very common in enterprise to, as a security measure, to choose a multi-vendor approach. You don't lock into any one. It seems a little redundant but you cover, you use different products and then if you need to swap out that's actually safe for you and it makes it simple to, you know, if things don't go in one direction with a product you have this other one that's ready to go. So the thought was we could take that approach with with this project as well and get us all in the same room kind of thing and in the same issue queues. Also, I don't know if you guys have all seen the To Do MVC site. To Do MVC is this group of people that took the backbone.js, backbone, the front end JavaScript framework. They took the backbone.js example, which was this little simple to do list and they started porting it to every other sort of implementation. So what we're kind of hoping is that we can get some other people that are involved in some of those other projects, that's kind of partly other provisioners, sorry, people that are using other provisioners. So I'm a puppet guy. Pat's a chef guy. We're still friends and we're hoping that some of you are Ansible guys or salt girls and that you can come and join us and that maybe we can kind of be the To Do MVC of provisioners where we have one set of sort of acceptance criteria. We have one set of sort of feature requirements. We have implementations in puppet and chef and Ansible and that way it's an easy place to go and sort of compare and contrast how this tool sort of organizes and assembles the different things that need to be built. So sort of if you go to To Do MVC you can go and look at the same thing, the same feature set, the same kind of front end built with Angular and backbone and Batman and all the crazy JavaScript frameworks. So the goal is hopefully as we continue to build out this multi-vendor support right now we've got actually right now we've got pull requests pending that get us all the way to to a lamp stack and with chef and puppet but we'd like to get we'd like to get more so that we can kind of be this middle ground for comparing and contrasting projects. Yeah so it also lowers the barrier to jump ship because right now if you have started to build a tooling around one and you're building that tooling on your own then just say you know just say you look at this you know this analog of To Do MVC and you recognize wow like it seems really more straightforward how chef is building this exact same thing and you now if you're using the puppet tooling then you can kind of jump the other and try it for a while and you're in a bit of a safe a safe zone where you're not like starting from scratch and having to learn how to replicate your full you know whatever you had before. So maybe I'll take a second to just mention I think we get to this later too but so one of the things that when I say like we have you know feature parity between all these between the chef provisioner and puppet provisioner and whatever else we include the idea of a big part of this is to have a common set of of integration tests that are basically testing the built stack and ensuring and we're doing this using using combination of Travis CI a tool that Opsco who maintained chef have created called test kitchen which is for like basically spinning up a bunch of test suites a matrix of a bunch of test suites and a bunch of different platforms and running building running the running the puppet modules or running the chef the chef cookbooks and then running final integration tests and making sure that you know it's memcaches available and apaches or apaches responding in a certain place so yeah it's you got you know that you have a this feature parity in between stacks and the idea is that we're testing this on every commit using by spinning up on amazon basically every time. So I think that that was automated testing from day one is one of our goals so just to elaborate on what Pat said so here's an example from one of our pending pull requests that that we've got tests that can reach out and run from to have Travis CI spinning up the amazon instances and you can see these are each of the things reporting back is it running on sentos 64 or is that sentos 64 right sentos 63 sentos 64 precise 64 bit lucid 64 bit and getting back all like results on all of those in terms of the upstreams we just wanted to comment on the fact that we're big fans of librarian both librarian puppet and librarian chef we're using that to pin all of our dependencies and to kind of enforce best practices where we're pulling from community cookbooks and modules and trying to force ourselves to either produce a new community module or cookbook or find one that already does what we're looking to do how many people here are using community modules or cookbooks primarily rolling your own primarily most of you guys that raised your hand saying you're using puppet or chef aren't doing either creating your own or using puppet or using community stuff um fair enough i don't think puppets doing very much for you guys i've just got a quick question um i saw you're talking about different distributions there are you talking about using the same golden images are you building those from a set set of scripts i mean where are those images coming from because that's obviously an underlying piece here right so um so the yeah so it's kind of people are having to package up the base images like there are there's a base ones on amazon that are basically kind of the stock sent os 63 image the idea is we're going from the very the very basic install and now you know most most most os maintainers actually put those packages out on amazon and they're kind of getting the habit of actually creating vagrant base boxes and providing them so we're not in as a community rowing them all on our own and uh michael hashamoto the vagrant maintainer actually wrote this school project called packer that's helping everyone do this and there's yeah that's kind of where i was going was because you've got like vwe and things like that that basically are scripts to they take an iso and build an image out of it yeah and i'm just wondering if that's sort of on the horizon there to include that that basically you've got it okay we're gonna if you're building everything essentially from packages you really want that absolute minimal system and that's usually the biggest problem is you have to make sure that everybody's on that exact same minimal system and if you have the script you guarantee that we built it from an iso to this standard yeah yeah it's uh and just encouragement everyone like that that's awesome that you just got up and asked the question so anyone else who has a question in the middle that's great um so the uh the as pat said the tests that run on amazon aren't actually running through vagrant really they're um provisioning from amazon base images and while it is kind of a golden image in that it's cloning the existing kind of amazon image which allows us to do it fairly quickly um but not anything is not much as pre-installed on that um it's pretty much a clean install there's not like a golden image that has to have a patchy and other stuff on it at the moment we're relying on base boxes for vagrant that have puppet pre-installed but i think we have omnibus the omnibus plug-in that'll um put chef on so that you're on the chef side you can have a really clean install on the puppet side at the moment we're still pulling a bunch of box you're still relying on an Ubuntu box that has puppet pre-installed at the right version which is um suboptimal um so uh this part gets hand wavy or um but uh at the moment we're just setting up a basic lamp stack because that's kind of our minimal viable product but the idea is that we want to ship with some simple switches that can say give me your best approximation of aquia give me your best approximation of pantheon so that we can sort of um reduce the come reduce the chances for having different variables right that's one of the big promises of ending it works on my machine is that you can have something really close to production we have lots and lots of people running on basically the same production um it would be really great if aquia and pantheon published um vagrant boxes turning over all of their configuration and secret sauce is probably not something that is easy for them um but uh but they have both people from both teams have been um forthcoming saying you know like we'd like to be supportive uh at some level and and kind of share so the pantheon guys especially have been really open the aquia guys have nodded at conferences and said they'd like to be at least um so we're hoping that we can get a little bit more support from them obviously we won't ever get it perfect because they've got some special sauce behind the scenes um but we think we can get it pretty close um having a really similar setup um and then the idea is that we're going to have some fairly human readable yamal component lists um that pull in sort of uh meta cookbooks and meta puppet modules which would be the only thing that actually lives in our project um so that you can sort of have mix and match things where um you mostly have the same Apache stack across several different kind of um platforms that were imitating or the same engine x stack um probably the same redis release could be you know the same redis version could be the same item that drops into a yamal list um and the idea is that we can have a space in the repository where you can add your own um we're still figuring out the exact best way to model that it sounds like lots of you guys are familiar with uh with chef and there's the idea of the run list which you can build dynamically and basically drop drop roles in that that are the different layers of the stack that we're building so the only thing that needs to be you know you just configure in the yamal what what are the what are the core set of roles that we want in here and we've got those roles defined in our in our project and just last night we hashed out how what the equivalent of that would be in um in puppet just to make it work in a chefy like way that that um that would jive with how we want how we see this this project later in yeah kind of a mix of some custom fact plugins factor fact plugins and some magic to make puppet pretend that it's a dynamic language um so yeah um room to add your own components I think is critical because I know at my company we use some tools that we've written to be able to make synchronizing our environments with our remotes really simple where we're running our own hosting we're going to want to be able to drop that stuff in and we're not going to be able to move from our own system which is on our github thing it's open source but we're not going to be able to move that to from that to the shared thing that we're not the sole maintainers of until we can kind of easily plug in customizations without forking um so that's kind of our kind of next big priority which is why we spent a much time last night kind of figuring it out so um this is where we transition to kind of a a section on imagining so this is kind of a bunch of stories of where we think proviso could be useful to people and hopefully we can get some feedback from you guys on whether this is the kind of stuff you were hoping to see from this project when you read our description and decided to spend 45 minutes with us um so um danger will robinson danger no will robinson danger that's uh danger will robinson with the waving arms there um so the first thing do you want do you want to take this one so uh the idea is uh platform fluidity is the first scenario um so the idea that you know the situation is you're getting ready to host on ubuntu 12.04 you've been developing for a while you've been developing locally with proviso um this is in the possible future where this is a success and people are using it um so uh halfway through the project uh client says that here linus indoors his red hat linux 5.2 can we do that uh and this isn't true when linus doesn't do this but uh but this is an enterprise client and what they say is very serious so in other words linus does say this and it is true um so with proviso the idea is that you can see which platforms are supported and tested at a glance by just reading the reading and seeing hey these are the things that we have tested on and that we have built this stack on and run these individual test suites different layered stacks um and you can actually go to travis and look at the test runs so even if you see that the build status is not successful right now or one platform isn't available you can kind of like you can go through and see all the evidence of maybe where that platform stopped being supported because it wasn't you know it was old and it was like lucid or something like that and you can see you know evidence of um it's very transparent it's not just saying hey we support this you can actually go and look at the tests that say what we support and if we don't support something what you will have to overcome um so sure um and that story uh that that hypothetical story of where a client says that linus insists that this one flavor of linux is the only one that he endorses um that that actually happened i was i was told that linus he takes money under the table from sentos and that's why that you really need to use sentos because he said that but you know client's always right right uh so uh i guess just a little more on what makes that possible like as i said the testing infrastructure makes it possible to easily at a glance look at this um but also the fact that we're using robust community cookbooks like we're not just using a custom cookbook that we built that applies for our platform most of especially in the chef community and more so in the public community um they are the cookbooks are very very multi-platform um sometimes that makes them very large some people have opinions about that but overall it's it's really nice especially when you're new and coming into this the fact that you can just you can swap these things out pretty pretty easily um it's still it's still a little rougher in the public community we're we're still getting there but it's more and more of the community stuff works so um yeah that's scenario one um scenario two is uh the idea of um helping overcome the idea of or deal with imprecise stack versioning so oops so uh just for example my sequel aquia is running 5.5.34 and you're running 5.5.32 on your local machine um a lot of people will look at this and they'll be like yeah it's all it's all uh 5.5 so it's all the same right so no no it's not so if you just look at the um like the the mysql change logs are scary sometimes uh so if you just look at a tiny patch release this is the this is 0.33 the number 33 patch release um you had three different versions of three patch releases just in between that thing that seemed like a small probably a small change um and this is the very top of the page here's the rest of the page and the all of these it's just like itemized bullet list this is one of the small ones that just go down for a long way and each one is a change that has happened internally in the system and each one of these represents a scenario where maybe something crazy is happening and you're seeing a little bit of a a difference between environments and maybe you'll spend a day trying to troubleshoot this um so these this is all the wild card variation that gets introduced when you're dealing with like slightly small pin versions or differences in in versions um so i guess the thought is that uh you um like in this example if you know um the standard version um that's available in the package repositories is one and you know aquia has rolled their own it had a slightly newer one um you don't have to make that compromise and deal with maybe all these big differences um the ideas we're working on this together uh there's we have an aquia roll and we've we've said hey this is important so we're figuring this out we're going to mimic them where this is important um and you know one person does this a few people do the work and everyone gets the benefit um scenario three uh is the idea of this could be a great opportunity to work together on tooling that makes this like not just a development environment but a an SDK for working in the Drupal community a software development kit so it like the idea that maybe it's we're talking about the idea that maybe this could become the de facto way of um of doing regular routine community tasks um so can we um can it be a standard tool to help us say file better support support issues um so you know traditional support issue in the drupal.org core queue my site's broken and some rather scant details i don't know what that is but i guess the thought is um you know wouldn't be great if the uh if we had one tool that we were rallying around and we could say hey could you just reproduce this in proviso that's kind of the bare bare minimum that will ask of you to get our full attention um and uh it's the current approach even if like you know a simple approach of just like proviso as a regular vagrant environment is you run you know vagrant up vagrant ssh um you do a quick drupal um and load in the views module and enable it and then you set a variable just say that's what it needs to produce the bug then go to this page and you see it kind of thing and now uh the person the maintainer follows this advice sees the bug and can immediately deal with it saves everyone time they're incredibly happy but we can even create some um some more tooling in the form of vagrant plugins that serve our needs um and uh that just essentially drive drush inside um so this is this is in some ways tangentially related to building a vagrant development environment but this i guess could form like the issue queues where we're where we're building this are a great place to have these discussions about uh building these tools um there's a you know also hypothetical uh could we create a standardized uh a vagrant plugin that helps us deal with bug reports in the community so um oh yeah that's out of place um so the i'll i'll just skip to the next one for um easy for the could we build another tool for um for easy testing of patches in the issue queues um it is like this old man with a patch there's no reason this has to be here uh so like hypothetical vagrant command which we could very easily do and i'll just walk through that so uh vagrant proviso patch test and give it the um and feed in the argument for the path to the patch the the text file so we can easily get the issue number from this uh we can go to that page um this is easy to do with the vagrant plugin and you know some ruby some ruby gems uh scrape that scrape that page find the core version and the module that it's talking about find the dependencies for those modules by checking um the xml updates um the same thing that you check when you when you're looking for updates um or that the drupal site checks when you're looking for updates um also you know look on that page find the place where that patch is linked and and then find the date of that comment and then load in that version that that head the commit that was at the head on that day because everyone when they're doing their patches they're doing it against the head um so anyway this is just a quick one liner that now maybe this environment this environment actually helps people in the issue queues and it's a you know a commonplace that we're going to just solve our problems and the things we deal with every day which right now have a bunch of different tooling around so last scenario is the idea of remote deployment so just say you've working you've been working locally with proviso and your original plan was to host with say pantheon or aquia uh but then uh you realize something mongo db and no js are freaking sweet you really want to use them but they're not those don't exist on those larger platform providers you see you've been developing on a roll that emulates aquia um but now you can instead of being kind of at a dead end where now you have to totally rebuild a stack that works for you um you've already been developing on one that we have as a community built to emulate say aquia and um and you can just you know there's some work to figure out how to write your cookbooks hopefully leveraging community cookbooks to get mongo db and and uh no js setup um but you do those customizations and we have that that conversation in the commonplace and maybe and maybe you share back for the next person and now you've got um you've got your remote your local development environment and uh simply by using vagrant awas the plugin that allows vagrant to push remotely you don't just have a local development environment you you know you actually have um something that you can spin up and and you know at the very least use it as a scratch base but maybe later you know actually hosts your live site on it um yeah uh those are like yes end of imagineering period uh so anyone have any questions on what the goals of this project are or like what your thoughts are well i mean i'm just wondering how far along are you actually um and maybe i should explain a little bit about my situation uh we're deploying on the amazon and are planning to use opsworks uh which is using sheh uh and as far as i can see we we can get some really really good stuff out of um having a git repository without cookbooks until opsworks to just look for the cookbooks there and deploy and the run list i guess is managed in the in the opsworks configuration um it will be really really great if we very easily could make a a vagrant sheh uh solution that would look at the same cookbook repository and well basically do the same um am i looking at the right project then the like this is a great place where uh where it would be wonderful if we were having conversations in a common place because a lot of like even to build a chef repo the cookbook repository that's done a lot of different ways and there's um lots of thoughts that the wider community talk has about um about how to best organize that and like if i mean i my personal thoughts would be like using librarian or birkshelf and that doesn't um that doesn't it doesn't it's not it doesn't mutually exclude um using this project to figure out how to build your um uh how to build it using amazon service um because it's a very concise definition and just tells you exactly which you know we're if we're doing this right um all our cookbooks aren't living inside this project they're actually out there whenever we need something even a little bit special sauce we're we're publishing a a cookbook to wrap around that that's external to this project we're pulling it in with um using those um those cookbook that cookbook package manager which everyone it is so the thing the fruits of what of the labor that goes on here can if we're doing it right we're pushing it all out anyways you can choose to resurface it and use it with amazon um and that's that's no big issue but i mean hopefully the i guess the idea is the triple community has very specific needs on how to optimize a stack and right now a lot of those really exciting conversations kind of happen in the engine like among the engineers at aquia and among the engineers at pantheon when they do awesome work and they push out great features for us but they don't we don't have any place for these conversations to happen among um you know people who are who are really known stacks right so if the question is um will proviso will proviso help me to also either pronunciation is fine um will proviso help me to uh to take a chef run list that i have in a bunch of chef cookbooks that i have and turn them easily into a vagrant project um i mean i think vagrant only takes a couple of lines to do that part um but um hopefully the idea is exactly like pat said it will at least serve as a place for um you to see vetted community vetted modules and a reference implementation of how the community considers this best done um which isn't to say that like the five of us working on this are the the community that decides how this is best done but hopefully after this session you'll all yell at us and tell us how we're doing it wrong and we can do it better um and then it will be community vetted and and we'll have like sort of a consensus on how it's best done so first of all i want to thank you guys because i have played with a number of the existing solutions and found them all to have positives and negatives and i was at the point where i was like i need to build a dev environment to hand out to my devs that i know is solid and i was going to end up having to reinvent the wheel again and i didn't want to do that so this is great because i will absolutely contribute stuff back i guess my question is what's the scope i mean you went to the imaginary thing and so obviously you can you can go really wide with it but um so somebody in this room says hey i want to contribute they're working on chef they don't know anything about puppet is somebody at that point going to say well okay wait we've got to make sure report some of the same stuff over to puppet to keep them parallel because that seems like a huge complication unless you've got people willing to take that responsibility because that initial contributor is not going to go learn puppet to go put the other side of the patch in um so that's number one and number two how deep are do you want to get do you want to keep this as just being a basic lamp stack is this going to become something where we put pieces in potentially to turn on for developers so we install you know um particular editors you know i mean obviously if it's available through chef there's a cookbook someplace is that going to be sitting i guess this kind of goes to the previous question how much of that is going to get rolled into the distribution and how much is going to be like well you can add that to your own custom thing we're not going to put that in so that's always a tough question and also i realized that we didn't exactly answer how far this currently is um so i think if you clone the repository right now you get the you know github.com slash previso slash previso if you clone the repository right now you get something that um that has the magic to do the puppet or chef librarian work to pull in whatever is defined and build up the box using either chef or puppet all of that stuff is in that repository and then pat has a fork that has the chef kind of lamp stack cooking and i've got a fork that has the puppet stuff cooking and we're about to start pulling that stuff together so at the moment it doesn't build you a functioning the proper project doesn't build you a functioning lamp stack but the work has been done and it's just a matter of pulling that in so as for what's in scope immediately so first off as soon as we get that that stuff merged together and thoroughly tested right testing is the key as soon as we get that stuff merged together and thoroughly tested the next step is is adding the ability for someone to um to add on their chunk in a clean way so that you don't have to fork previso to add your editor your thing um and and then um the idea is that we're going to have stuff that seems of general interest um we've been hashing out a plan to that's related to that to allow you to flip on and off some of those things that are of general interest so mango redis memcash are all becoming common enough components in a dribble stack that we think it should be one line of configuration to turn those on or off um in terms of what about my crazy idea it's gonna kind of be up to the people that weigh in on the issue queue to kind of decide that this is kind of in what should be in one of those like flip on yafi things or not i think what we're talking about last night is the idea that the extensibility part needs thought and it will be like it's not something that's there right now so we're airing on the side of like the most important thing we're trying to do is not alienate someone or not choose to say hey you you're not doing it the way that this project wants to do it um so until we have extensibility solved which might be a while the idea is have this just be a melting pot of different ways and make sure that these can go be turned on and off um and we're not we don't require someone to fork or say oh this doesn't solve this isn't willing this project isn't willing to entertain the way that i do deployments whether i play with cookbooks some people are against that like there's there's lots of different variation um hopefully the core central things is in like what's uh i don't know i guess that what what is how do we optimize the mysql part of the stack that's more clear um and it seems i guess by the the fact that aquian pantheon essentially do this for the tons and tons of sites they deal with makes me feel that this is like we can do this we can kind of come to some consensus but they might also be optimizing in different ways and if you're trying to create an aquia model and a pantheon model because that's what somebody needs they needed to match that you're going to have multiple configurations in there anyway um so i'm not sure that you're necessarily going to want to be like the one true way to tune it because there isn't going to be one true way you're you're really creating sort of a okay here's here's the aquia stack as close as we can come whether they share information or you go look at you know whatever pieces you can get to and say okay that's what we can clone um versus the pantheon stack so our idea there is to create um to create the the thing that we were talking about before about wrapper puppet modules and wrapper cookbooks that configure those other pieces so the idea is that you kind of you kind of wanted to get a sense for what in as far as they'll share or in as far as we can figure out um what they've done to tune you could kind of diff the proviso mysql aquia wrapper with the proviso mysql pantheon wrapper and kind of see how we think that they're tweaking that um trick question the aquia one would be uh percona i think but right and then at that point that wrapper then actually has two pieces one of which is a chef piece and one of which is a puppet piece that's right there there'd sort of be parity so and then and then in the issue of um do we let something in when we get a submission for puppet but we don't get a submission for chef or vice versa um the thing that we've landed on so far and i would love to hear what you guys think about this is um when we accept that pull request for puppet a an issue gets created for chef and so that doesn't require the person that's contributing to do that because that's going to put the brakes on the whole project it's going to seem insurmountable for someone that knows one side and not the other but the idea is that that then creates an issue for somebody on the other side of the team to start looking at and again increasing the conversation of seeing how it was done in puppet and contrasting that with with sort of how it's done in chef and ansible and so there's a skill set here for people who speak more than one of those to act as sort of translators and so that seems like a real need for this project that definitely needs to be addressed this you need to find people that have spent time learning both to be able to do translation at the moment um we're training each other up and expecting that like as other people join the project they'll get trained up to um and i think that sort of serves a need in the community as i've been talking to people a lot of people have some buyers remorse or anxiety about whether they made the right choice because i've heard people on both sides say well if i had it to do today i think i'd go with the other one um because the grass is always greener um but the hope is that we can sort of get a better consensus about what the better sides of these different things are like a puppet feature that i like is that it can show you a diff of what it would have done completely without actually touching your system um as far as we can tell chef just can't do that for some various reasons what's that oh chef 11 can do it nice thanks nick that's awesome um yeah but uh but yeah comparing and contrasting the tools which are obviously getting better all the time every time i come up with something that's like you know what like puppet has this one thing like i can hang on to that this guy's always like no not anymore uh and just want to say like we're talking like at least in chef role like we're talking about the idea of writing wrappers and that's not this isn't like a fringe the thing it's a common pattern in how how people design their infrastructures at least in chef role i'm not sure about about puppet but yeah so we're not doing anything like crazy to solve our problems um it's just yeah it's using a model that lots of other people use when designing i think we're a bit short on time but a few questions on a puppet i've been using puppet this year and i've found that the modules are often kind of hierarchical someone writes module to write a lot of modules which fit together and even just building a lamp stack which we can use for Drupal for service it's not so easy that i find someone like come to camp Drupal just lots of different modules but you really have to go with them and use all the modules but then i find your people a little about this useful and then i have another project where i need postgres and this postgres depends on a wget module which is not going to play together with another module and in the community it doesn't seem to be as homogeneous how or seems to be interference between modules which you don't have for instance in the Drupal community yeah i've done i haven't actually stated a question but it's a question is there such a thing as a pattern for how to use a provision of Drupal server on puppet today that there is a lot a consensus behind me um what we're trying to work on building a consensus is that a nasty question a little bit no no no i think you're right puppet more way more in the public community people have been rolling their own than in the chef community in the chef community there's a ton of reuse and i think the puppet forge has only really started to mature in the last year and it's and it's still kind of slow going and i think you're thinking of example 42 where they have just this whole ecosystem and you really have to buy into their whole stack for any of their pieces to work and it makes some assumptions that just won't work with other module providers i think that's kind of being considered sort of bad form there've been more blog posts about how to build puppet modules that make sense i think puppet puppet has a language puppets puppets piece on format that you use to describe all your manifests has some limitations that are being worked on that have caused some of that fragmentation but there absolutely are a bunch of modules that will play well with each other and don't bring with them a whole bunch of other dependencies other than puppet standard lib which pretty much everything works with so um so so what um are the pull requests that's going to be landing uh shortly that pulls together lamp um relies really heavily on the puppet labs modules those are all well written as you kind of expect um and they've got modules for apache my sequel but some of those are like two years old for instance that lot the lot about ones are way better sorry for the introduction the um better better is relative um and it depends on which one you're talking about i should join we'll discuss yeah yeah um maybe have one time for one more question i think we're out of time actually so um so we should just say uh yeah we want you as a proviso contributor um we would really love to get um to get more hands on deck and get more of these conversations going about what puppet modules don't suck and if there aren't any we need to get the ones that suck least to really not suck or write some of our own um and that's that's definitely some work to do i think on both sides but especially maybe especially puppet um so join us on github um which we're using github so that we can interact more directly with the rest of the devops community which is mostly on github um the pound parse proviso on uh freenode we've got our irc room and um and we've got a google group that's mostly for announcements we do um we do hangouts every other week on friday on google hangout um to just kind of hash out where we're at and what we're working on and what's up next so we hope to see you there thanks a lot


What's going on everybody? Got Kyle and Shawn here with LaytonSports.com with three boxes for Aaron K. Got a 2023 Leaf Exotic Baseball, a Bowman Chrome Mega Box, and a 2023 Bowman Chrome U. Some football. We'll start with this. Good luck, Aaron. Good luck. Some Bowman Chrome U football after some Premier League Sunday. Oh, yeah. This isn't the penance. Yeah, it's gotta be. Oh, are they in the hunt? I have no idea. Come on. No idea. Are Tiger and Charlie in the hunt for that thing at all? All right. Good luck here. Anybody know? Over. There's a Greenway to 99 Eli Holstein. That's a Roger that. Blake Corum and Caleb Johnson. I'm going to over and out before. Six back. Okay. Okay. Not bad. There's a Marvin Harrison, early risers. There's Cooper Dejean. Dejean. Canada. Send me that link to my email. Sean S.A.J.W.N. at ladiesportscards.com. Refractor is Gene Bray. Please, sir. Like, shape it. Please, if you would be so kind. A quarter will get you 750 on the pass. Say, Carl, hey. Hey. I don't hate that. I got a quarter. I have a quarter. Here's a Ryan O'Keefe. I'll throw a quarter on it. Let's say. Throwing a quarter on a lot worse. Button for Eagle 105. Extractor first. Brennan Presley. Oh, Eagle. Let's go. You can say Kool-Aid McKintree or Fractor. Maybe he wants to play against Ohio State. Maybe he didn't like them. How they treat him or something. Wants to be on a team that plays them. Okay, Lemon, Moorhead. I have no idea. Here's the first X-Fractor out of Night, Michel. Hit him with a DMS. Corey Kiner. Charlie's a beast, he says. Yes, he is. Audrey Estimate and Tatian Sanders. Charlie made the thumbnail today. Jordan Travis. There's Smael Mundan. Charlie made the thumbnail today on YouTube. Whittington. Tori Horton. Righty. Half the box down. Keep it going here. Good luck, sir. So we got Aaron. Okay, I'm going to check it out. Fuchsia Minidiamond. It's going to be AK Clubnick. Nice one there. Clemson starting QB to 150. Nice Clubnick there on the auto. Got Eli Holstein. Is that his daughter? To $2.99, or $1.99. So I'm going to leave Benson for Bama. Caleb Downs. Yeah, I saw that, man. Where's his wife? Oh, it's his daughter. Oh, it's his daughter. His daughter is on the bag for him. That's a freaking secret. That's very Winston Wright. Geoffrey Harvey. I think that's awesome. All those kids out there. Tatian Sanders. Brian Thomas. Charlie looks like he talks a little... You know what, man? These kids nowadays. Tell them. Mayan Williams on the shimmer first. That was a product of TikTok, man. No. I was going to say, what? No, this isn't the choice. There's always this much. Okay, yeah, that's a pretty good choice, right? You know Thumbnail, Sean dressed up as Santa, beating Sam with... First Justice Day, do you know my Photoshop skills, Carl? Yeah, that's just... I barely got Charlie Woods on there, dude. I was fighting that thing this morning. I barely got Charlie Woods on there, man. Trying my best here. Yeah, but yeah. It's a 399. Got Tatian Robinson for Kentucky. Got a Mason Taylor. And I was trying to get something else on there, and I just couldn't do it. It was not working. So we went with Charlie. I want to learn how to photoshop. Yeah, it's a... Me too. Me too. There's a Mecheg Buka. Hunter Deckers. I got like a 15 minute class. Yeah. And then just put it on my way, so... That's it. That's what we get. That's what we get. Say Brian Thomas on the first place. Really? Brian Thomas. And the last one. We really just got a whole game. That's awesome, man. Really? All right. I got some second generations coming up. And a first bowman, Shador Sanders. I can't wait to watch Charlie play. All righty. We'll do a bowman Chrome Mega now. We'll leave the exotic for last. Good luck here, Aaron. Appreciate you grabbing up some spots, my man. Dude, we have Sunday Fonday coming on later today with Forrest and Jake. Jake. Getting here about five o'clock. Jumbo Diaz. Jake. Jakeus, Jaker, Jake Crembo. Jakeus Winston. Crembo. Jakeus Winston. Gutters, Jake 0-3. They'll all be here. Yeah, there's a lot of Jake's. Jake G08. I believe it is on Twitch. Yeah. Jake, Jake, Jake, Jake. Jake G08. We'll be here. I told Hallie to do him. She was toppling for Rich. She's the one to do it. Yeah. Here are TJ. They're the ones to do it for you. Not me. One time I tried to make Sean. I tried to make Sean with a dolphin head wearing a Sean chain, but I couldn't do it. You couldn't do it? Couldn't do it. It was too much. It was too much. I tried to have a dolphin wearing a Sean chain, didn't work out. SRA Ruiz, for the silver packs most. These are all rookies and vets. Matt McLean, Podai Sanga, Andrew Waters, not for the silver packs. Miae Jettamette. Gave Dayan Jorge. There's an iconic Machado. First Rivas and Jordan Lawler on the silver. Wow. Eagle. Four back. Let's go. Here we go, Tiger. You go, Tiger. Where did you watch that, man? Xavier Isaac. You're watching 15 minutes. Carter Young on the first. And Green is Andy Acevedo. The 99 Nationals. Fry on the Golf Channel. Marco Luciano and Gutierrez. Usually golf in the morning and then three o'clock or two o'clock. They put on the main broadcast. Alrighty there. Oh, I did it again. What am I doing, man? One more box for Aaron. What am I doing, man? One more box for Aaron. We got an exotic baseball. Goodness gracious. Sean's got to be distracted today. Sean's got to be distracted. Thinking about Charlie Woods and whatnot. Charlie Woods and whatnot. Oh, it's on Peacock. He's on Peacock to start. Oh, Peacock? I had the Peacock for a little bit there, but... It's free. It was just a... Hmm? Isn't it for me? Peacock? Yeah. It's another subscription service. There's a Game of Reno. Nice one there. Rookie for the D-Backs. Game of Reno, one of eight. This one there had a great season for the D-Backs. And we got a Seya Suzuki. Nice one here. That's a Mythical 101 Auto. There we go. Nice Seya on the redemption there. That'll be a one of one. I don't know the parallel. There's a couple of different ones in there. On the Mythical Autos. They even put a sleeve on this. On the Seya Suzuki. One of one. Very nice one there. Second year player for the Cubs. And on the back we have a O'Neal Cruz. O'Neal Cruz on the Tiger Stripe. One out of 10. Nice little box for you there, Aaron. O'Neal, Moreno and Seya. Soled one there for you, sir. And that'll do it for your break. Thank you, sir, for the three boxes. We'll get that right out to you.