In the early 1960s, America was deep into testing nuclear weapons and learning about radiation in anticipation of the Cold War with the Soviet Union turning hot. But some tests had unforeseen consequences, like the starfish prime shot that almost stopped Apollo from going to the moon. Hello everyone, I'm Amy and this is the Vintage Space, my little corner of the internet where we talk about all things mid-century that interest me, and many of those things overlap with spaceflight, including a handful of nuclear tests, because radiation is a big issue with space exploration. Radiation is one of the biggest hurdles facing future deep space human missions, or really any human mission that goes beyond the Van Allen belts. So let's take a look at the radiation environment that ensconces our planet. The environment beyond our atmosphere is incredibly hostile. Not only is there no air to breathe, atmospheric pressure to keep our bodies from expanding fatally or comfortable temperatures, there's a radiation everywhere, owing in large part to the constant stream of charged particles issuing from the sun. And there are other sources, including galactic radiation and radiation from other bodies. No matter how you look at it, it's a bad place for humans. Exposure to radiation breaks down the body and can cause a host of problems, none of which you want to deal with on deep space missions going to another planet. Lucky for us on Earth, we're protected by the Van Allen belts. The Van Allen belts were discovered by James Van Allen, who in the mid-1950s was exploring charged particles outside the Earth's atmosphere using sounding rockets and rock hoons, small rockets launched from balloons at altitude. These early experiments couldn't get high enough to leave the atmosphere, but already Van Allen was finding that the environment beyond our planet was well worth studying. Then the International Geophysical Year gave him an opportunity. Agreed to by international partners in 1955, the IGY was an international collaboration between July of 1957 and December of 1958, wherein scientists from various nations agreed to study Earth science and solar activity. As part of this initiative, both the United States and the Soviet Union announced their intentions to launch small satellites to gather data from beyond our atmosphere. The Soviets got their first with Sputnik on October 4th of 1957. The Americans struggled to join the space age in the months that followed before finally finding success with Explorer 1, which launched on January 31st of 1958. Explorer 1 was a small satellite with an array of onboard instruments, including one of Van Allen's radiation experiments designed to detect cosmic radiation. The data returned from Explorer 1, though didn't line up with his expectations. On board cosmic ray equipment registered nearly no radiation where Van Allen expected to see high levels of radiation. So he tried to work with the data to understand what he was seeing, because his early experiments confirmed there was indeed radiation in the area where the satellite was orbiting. The low cosmic ray count he hypothesized was actually a false reading. He suspected his instruments might be oversaturated with particles trapped in the Earth's magnetic field. Instruments on board the Explorer 3 satellite that launched in March of 1958 confirmed Van Allen's hunch, making the Van Allen belts one of the outstanding discoveries of the IGY. This data revealed that our planet's magnetic field is significant. It comes from flowing liquid metal in the Earth's outer core that generates electric currents, and the planet's rotation around its axis turns those electric currents into spheres surrounding the planet. That magnetic field is what protects us from solar radiation. It doesn't allow the stream of charged particles to hit our atmosphere. But what Van Allen found was that the charged particles that don't reach our atmosphere end up trapped in the magnetic field, and that trapped radiation can't dissipate into space. The trapped particles don't have enough energy to escape the magnetic field. So we have two belts that are really like nested doughnuts circling our planet. The inner belt sits between 63700 miles above the planet, and the outer belt is between 9300 and 12400 miles. And though we talk about them as belts, there is variation in the density of charged particles in both, so they are not completely uniform. When NASA started planning the Apollo lunar missions in the early 1960s, even before the missions were officially on the books. One of the big things planners had to consider was radiation, specifically radiation in the Van Allen belts. Earlier missions wouldn't have to worry about this. Because the lower end of the belts is around 600 miles, Earth orbital missions could stay well below the high radiation environment and still achieve their goals. The Mercury and Gemini missions did just this, with the exception of Gemini 11 in 1966 that reached a peak altitude of 850 miles. So for NASA it was going through the Van Allen belts to get to the moon that posed a real challenge. NASA studied the Van Allen problem and some creative solutions emerged, notably the suggestion from Van Allen himself that NASA could clear the belts by nuking them. His idea was that detonating an atomic bomb in the belts could give the trapped particles more energy, just enough to allow them to escape the magnetic field and dissipate into space. NASA decided against nuking the Van Allen belts. Further research determined that with moderate radiation shielding, crews could path through safely. They'd be going fast enough that their exposure to the two high radiation environments would be extremely minimal. It wasn't dangerous enough to cancel the missions. So the radiation issue wasn't prohibitive, but it did get more challenging after an atomic energy commission test in 1962. Among the technologies that came from the Second World War was nuclear weapons. After America's first successful atomic bomb detonation on July 16th of 1945, the Trinity Test, nuclear weapons were identified as the nation's best chance of ending the war in the Pacific Theater. On August 6th, the untested little boy bomb was dropped 1,900 feet above Hiroshima. A second bomb, the Fat Man, was dropped over Nagasaki three days later. The events had the desired effect of forcing a Japanese surrender, effectively ending the Second World War. Nuclear weapons had thus proven sufficiently useful that there was no question of America abandoning its nuclear program. On August 1st, 1946, the Atomic Energy Commission was established to oversee all continued development into nuclear weapons, and from there, the atomic age developed rapidly. The country had the perfect mix of post-war excitement over a new technology, money to fund it, and a cold war to justify that spending. It was the perfect arrangement that also allowed the space age to develop as quickly as it did in the late 1950s and 1960s. There were multiple programs that came out of the atomic testing era, among them Operation Dominic. Within this program was a group of atmospheric tests called the Fishbowl Events. These were designed to help understand how nuclear weapons debris would interact with the Earth's magnetic field in the event of nuclear war. One Fishbowl event was called Starfish Prime, and it saw a 1.4-megaton bomb detonate an altitude of 250 miles. The effect was additional radiation in the lower Van Allen belt, not a clearing out of the radiation that Van Allen had suspected might happen from nuking it. For a brief moment, it looked like Apollo astronauts would be up against a far more dangerous environment on their lunar journeys than anyone had anticipated. But even after Starfish Prime, additional research into the Van Allen problem determined it still wasn't a deal-breaker for lunar missions. By February of 1964, Apollo's hardware had developed to a point where the agency was confident crews would be passing through the belts fast enough for the spacecraft's own structure to provide enough radiation protection. And by 1969, the high-energy electrons injected into the lower Van Allen belts by the Starfish Prime event had decayed to one-twelfth of their post-test peak intensity. It was almost as safe as it had been when the missions were first under development. NASA did safely send astronauts through the Van Allen belts. At the end of the program, onboard and personal dosimeters registered that lunar astronauts had avoided large radiation doses. Their exposure was less than yearly averages of atomic energy commission workers at the time. I do have a whole video right up here about how the Apollo astronauts fared flying through the belts with all the technical details, if you would like to check it out. Given that the radiation question is often cited as one of the reasons the moon landing couldn't have happened, I hope you guys enjoyed this little, almost literal blast from the past that momentarily made the radiation environment that much worse. That is going to do it for me for today. I want to remind you guys that both my books Fighting for Space and Breaking the Chains of Gravity are available however you like to consume books. I've got links to both in the description below. I also want to say a very special thank you to my Patreon supporters and YouTube members. Please truly make all the difference in the world and allow me to continue making this content. So thank you so much. That is going to do it for me for today, you guys. Thank you so much for spending a little bit of time with me and I'll see you next time.


So, welcome to the workshop about the Always Operating System. My name is Petr Fichl and I'm here with Dominic and Miro. We're going to guide you through the workshop. Just a brief overview of the agenda. We would like to explain the vision of the Always Operating System. Then we would like to do a kind of high-level overview of how the things are working and then write down the examples to show you some tangible stuff, how things are working so that you can start playing and experimenting with this stuff if you have a laptop with yourself. But at the start I will give word to Dominic for a short introduction. Yeah, thank you, Petr. So, I'll just stand close to you so we don't lose this. Yeah, Operating System CI means we do CI for an operating system. You can see us in the Fedora space. Fedora CI do things there. There's documentation on the wiki. We try to keep all this public and internally inside Red Hat, we're called Operating System CI OSCI and basically do the same thing. So, the vision for us is with Operating System CI and Always Ready is that we don't want to be in a world where we develop things, then we say, okay, let's stop and take this and try to ship it so we can stabilize it, test it and see how it actually works out and then eventually say, okay, this is a release. What we want to be is that at any given point we can say what we have right now is good. So, instead of writing a new feature and then testing it, we say it's not actually finished until we've tested it and we know it works and we can ship it all the way through. For us in Operating System CI, that means all the way from the upstream through Fedora, that's the visible part. So, we want to make sure that there's a solid connection that when features are developed, you think about the actual end product where it's going to end up and how it's going to be used, which is a good reminder because we want users for our software, right? So, it's not just about the new features but seeing how they're used. So, you can reach us under the CI mailing list in Fedora. We have the wiki and we also hang out in Fedora CI on RC and you can reach out to us personally and you may have seen things like the CI pipeline and we work with Fedora infrastructure, for example, on the Fedora raw hide gating, which will apparently be a thing for real this year. So, fingers crossed on that. But, yeah, for those of you who've done some package testing in Fedora, there was a time, I think it was last year, where we wanted to introduce testing to all the packages and there was some mishaps with the user experience there and so there's some gaps there that we are aware of. But, I think we've gone through and addressed a lot of those, so there will be kind of a reboot on the user experience this year. And, yeah, this workshop is about if you have questions on how to make things work, how to tie in the processes that you have. And, yeah, tie those things together and make sure that we have tests for all the packages. So, that's about all the intro I get. Now we get to the real interesting part. So, at any point, I think this is a little more about being interactive. So, if you have any questions, just feel free to interrupt. Please do not wait for the end. I know that we are at different levels here regarding where we are with the testing. So, we are a couple of people here, so we can also spread out and answer questions directly if you have any. Thank you. Okay, thanks for the introduction, Dominic. Before we do the high-level overview of the staff, because the internet connection here is slow and it would take some time to start preparing a laptop for experimenting, we've prepared some container images for you. So, if you want to experiment, you can just make sure you have Podman or Docker installed on your laptop. And then you can copy the file from the USB key and then use the command here, the Podman and Podman load to load the image and then the final command one to run in the container. At the start, Dominic already mentioned this portal. So, fedoraproject.org slash wikisci is the main portal and from that you will get to everywhere. So, if you want to write this into your browser and on that page you will find all the links, including the link for this workshop. There is a special project at the bottom of the page. So, please bookmark this page and you will also find these instructions for copy paste available on the workshop page. So, now about the vision. Dominic shortly already mentioned what is our goal regarding not like waiting with the testing for a later stage, but maybe to pinpoint once more, Operating Systems CI, what is it about those really very big number of packages which are distributed together and we would like to make sure that everything works together and this is very hard as the number of packages grows. So, our vision of the future is that we would have this always very operating system where packages would be constantly kept in a good shape. There would be extensive test coverage which would be regarding the features and also the integration between the components and thanks to gating no change which would cause some problems or breaking some features shouldn't be allowed to be merged into the code base. And this should finally result in this that we should be able to release new versions much more sooner or even continuously. So, the high-level overview. So, there are three main blocks or pieces of the puzzle which make this working and these pieces consist of more little pieces which implement these different features which are necessary. So, I will start with the process. So, we start with the standard as interface. For all of these I will do just a very brief introduction, very brief description and anytime you are interested in more details or later during the workshop we can look into some of these but we don't want to spend however the time of speaking just but then you can experiment and play. So, the standard as interface specification which describes how the tests are discovered and then executed. Basically it says define some basic terms like what is test, test suite, what is other these relevant terms and what files has to be present where in order to be executed for the CI. Then the gating concept as already mentioned if there is a change which after test appears that it is breaking the package or other packages it should not be allowed to be merged. So, the package is effectively gated before doing some next step in the release pipeline. Notifications we would like to there is a federal notifications service which can be used to configure what notifications you would like to receive. This is something we would like to improve and thanks to also the consistent format of messages it should allow us to nicely configure from the user experience to receive only what you are interested in. Then the tools section. There is standard test roles which is something like an implementation of the Sundar test interface specification. So, it's a bunch of Ansible roles which makes it easier to run the test and provide the output which is expected or which is described by the spec. We have some efforts around metadata to have some efficient way how to store this metadata preferably directly in the very close to the test code directly in the Git repositories. We have flexible metadata format proposed for that which has some nice features. Then there's the pipeline which takes care of like detecting the changes and after it finds out that there is some change it will execute the test and prepare all the stuff but we will speak about that later and the peculiar as for the modern pull request workflow you probably know what is something like GitLab or GitHub. Then the last but crucial part are the tests themselves. What test types do we expect to be used in the Federal CI? We believe that most of the tests should live as close to the code as possible. For example, unit tests, it makes sense to have them directly together with the upstream project directly on GitHub for example but for when you are packaging the component for Fedora you would probably like to make sure the basic functionality is okay and that the component nicely plays with the other components. Probably this basic functionality or integration test would make sense would make best sense here. The test code stored directly in the repositories where the spec files live or dedicated space for the test in the test name space or even on other places and fetch from there. For the test execution we will be speaking and doing some practical steps so I will skip that for now. Okay. We are going to talk about the environment for the test like if it is a closed-time part where you are inside in the free-sense you could I am thinking of a package where I would like to use the nice map to create a device if that is possible what I would have to do to get an environment back and we can judge it. Okay. The pipelines I will be speaking about the CS system that runs the test name. It is hosted in an open-shift instance but it runs a VM inside a container because it is an unprivileged container so it is a VM where you have root and you can do basically anything if that answers your question. It is a VM. It is a 64 VM. Yes. It is a proper VM currently it is only a single host so you cannot easily be able to spin up multiple VMs but I believe we will be able to deliver that in the coming in the coming year. Is that clear? So it is kind of resource-price if it is a system virtualized VM We currently do not have any big performance issues given the fact that we have how many components we are testing so currently it is not a large portion but we can scale it up it is open-shift. It should be as easy as adding new nodes so the scaling up should be easy. Of course I would maybe even just add that we are planning to also support running tests directly on a Docker container, right? If it makes sense because not all components make sense to test in that environment. Just a question because we are running an unprivileged stock container I am wondering what about the infrastructure tomorrow if you want to use a SCI copy? I am focusing on the infrastructure that we use to support this So I want to point out that this is the default implementation so we have the whole concept of those tests and they should work more everything is plugged together and the pipeline that we have you can put those if you don't want to worry about it yourself if you have special needs you can either work together to extend this or you can hook up a system that you already have so you don't have to necessarily put everything in here this is really about the default implementation to make it easy if you don't want to worry about setting up your own infrastructures scaling up, working with open-shift or anything like that this is what you do Okay, let's continue because the time is ticking so we have enabled testing the CL pipeline is extremely able for all available or stable Federa releases and also Rohide Yeah, we are taking tests for the corresponding branch so if you are testing if you have the tests in Federa 29 they will be executed for the 29 build even scratch build so we should be working automatically but you can discover that the source code of the pipeline itself is on GitHub so if you would like to take a look how it works you can take a look there so for the build pipeline this is testing Koji RPM builds including scratch those are the links actually to the pipeline I can click it so currently for the blue RPM builds this is the only way how to discover that the testing has happened so if you build some scratch build and you have the tests this gives you a repository here you can find the results as you can see something is running here and this is the pipeline itself maybe I'll just show the artifacts where you can actually discover the tests how they have been run so for example this is a bus that runs a Bicolib test I'm going back to the presentation Oh, yeah, backlinks I guess so for each federal version there is a separate pipeline can you go back please so there is also a raw height pipeline there also we have poor request workflow so it means you can submit a poor request to the disk git and it will from the PR applied to the head of that branch build a scratch build and it will run the test on it so this is even before you do anything change to the production version it will be on the next slide the Pager integration itself so this is how looks currently the integration with Pager so here is a poor request to the disk component here just for testing and here actually here in the flags the tests that have been run simply because the CI is something not managed by us it actually builds the scratch build but currently we don't use it the CI also builds a scratch build and runs the tests that are there even if you add it with a poor request this test will be run and we are adding a pending status so currently you could see only the result once it completed it could take several times so we have there now a poor request to loopable which is a thing that updates actually the flags according to the messages on federal infra to have the pending state there to like retest the poor request you can just add a command in CI test and if it rerun in case you would need to rerun it for any any reason so there is possibility now for this for the build pipeline to actually get both the updates both the update doesn't get to the testing of stable repos if you add a gating YAML file to the disk git there is an example example here for the file component that is currently enabled for federal 29 this is this needs to be in this form both the update push state because this is like the event that it should like git you can change testing it doesn't need to be it can't be pushed to the testing repos if the test didn't pass and this is the name actually of the build pipeline that we currently use this might change in the future once we go to unified messaging currently you can just copy over this to your federal to your federal disk git branch and it will gate those tests that are there in disk git and here is an example usually if you have both YAML this test gating here is a little too small but usually you see there are no tests required so there is no gating enabled but when you have gating YAML file you can see that actually all tests passed this is a little bit different here discovering which test actually gated the package because in automate tests there are also several other tests being run by federal for a long time RPN Deplin and some others but it is not easy to see which actually gated the package so that needs to be some improvement okay so standard test rules as Petra mentioned is like an implementation of standard test interface this is basically what the pipeline does it executes an Ansible Babel you can basically do anything the important thing is to conform to the standard interface standard I would say so you need to create the test log file at the end and there is current specification says that the Ansible Babel should fail if the test failed we are actually wanting to change the reasons it can't distinguish between the test failure and actually the playbook went wrong even before running tests but currently there is a situation so you can actually run tests directly in Ansible that's things that people already do but you can also use our roles that make it simple to run tests via some of the testing frameworks for example a lot of red head guys use big lib then we have support for avocado test framework there is a basic role which can just run simple shell scripts a lot of people use that and source is a special role which actually doesn't wrap around the test suite but it actually makes you available the source code this is handy if you have the test directly in the source rpm and you want to run them for some reason yeah and we have tests again different test subjects like what the build pipeline is running it's running classic test means that it's passing actually to Ansible the tech classic currently Atomic is currently not used it was for the previous pipeline but currently that is really not used I would say that and for container currently we don't have a running on the container on the containers but it might be we even want to improve this tagging and stuff with a better better way how to specify the metadata for the test and for the testing itself I'm mistaken so here's a main documentation if you want to see these are really nicely structured I think better already mentioned and I don't need to do anything okay perfect thanks so with these links we will achieve most of the if you are new to this concept you would like to try something find really everything which is either on the first link which is the portal or if getting started the quick start guide is a good place to start because it nice to list all the steps which are not necessary for executing a test so let's jump into running tests so if you would like to run a test there is a definition in the standard test saying that you would place a file which is named tests.yaml under the test directory in the disk.git where spec files lie and then executing the test is as simple as calling just Ansible Playbook on this test file and the quick start guide lists all these steps so if you have a we strongly recommend for the experiments using either virtual machine or running the test in a container because the specification requires that the Ansible Playbook is run on the root because for example it prepares the environment or whatever is needed there is dynamic inventory support there so using this you can for example test all the mentioned testing containers or atomic host so that's the limitation if you are afraid what Ansible Playbook would do on your laptop it's definitely recommended to rather run this into a fresh virtual machine or container so there you would just install for example the FED package and you are prepared to do the testing with the FED package clone you can just clone the package package disk.git repository you enter this test directory and you call Ansible Playbook test summer and that's it as simple as that so if you have prepared if you have run the commands to prepare your container from our USB flash keys you can you can now do this do this testing because in the container they are already fetched also the repositories so to give you a couple of examples so there is a basic role which can be used to run a single command as a test so if it makes sense for a component it could be by like packaging and some changes might happen in the package or the environment or in the pipeline which is building the RPM package to just make sure the smoke test passes so you can run like minus minus help very very very simple command so as here we see the sorry there was a wrong button so here you see we use the standard test basic role and the text classic means that this is intended for running for testing a classic system not inside container or in a specific host and we list the tests there is a smoke test directory which should be entered before test execution is the current directory and we run this command this is just a command line tool for gathering or reports for the last year and there is like integrated simple test smoke test minus minus test which does this report from github for the last year and at the end we do just the standard packages is only one simple package and Ansible playbook together with the standard test roles will take care of everything install required packages, prepare the system make sure everything which is needed on the system is installed or if there are some extra packages which would conflict that would be removed and it runs the test so that's the very simple example of a basic law then another example from real life I think a very successful story is from python Milofranczuk started to play with it a couple of months ago and we reached this state where there is a test repository for python and because there are multiple components like multiple versions of python there are also some additional packages which are related to python many modules and such but for this example there is a simple smoke test which is called virtual env and it resides in this shared test repository using this line this repository is fetched and then the smoke test is executed and it's executed for example in this case for two python versions and you could use it for testing various more combinations here if you click on the link in the example so this is the page on ci-examples there you would see that there are multiple components covered it's about 10 or 12 python related components covered by this single test which is quite simple smoke test for the virtual and functionality but it very nicely covers all these components because it's stored in a separate namespace and it's referenced from multiple places so you maintain only one copy of the test then I jump at the beakerlib role so as I mentioned we have lots of tests written in beakerlib in the baseless query team so for the baseless components and we wanted to be able to execute them very easily so this beakerlib test role has been implemented which allows only list tests which will be run and everything else the standard test roles take care of so it checks the required packages it stores the packages and investigates these directories with the beakerlib test and executes them so that's about beakerlib example how it would look like and this is something from real life so this is bash example bash is 105 shells which are the POSIX compliant and again it makes sense to have a test for them shared in a single common repository and use them from that place here again repositories fetching the tests from this shared repo destination folder and here a new thing which was not there last year it's a flexible metadata filter it allows if the number of the tests grow if the number grows then instead of listing very very long list of tests which should be run you can use the metadata which are stored directly with the tests and from there using the FMF tool you would select I would like to run only tier 1 and tier 2 tests which are relevant for the classic for the classic test subject so that would save you save you updating if you add a new test then adding this to the list of tests which would be run to multiple repositories for example and now one more example which is demonstrating the standard test source role so here you say only you apply the source text always means it will be run for all the test subjects and it takes care of extracting the source extracting the test from the package source sources and then the standard is basic role just executes them as you see here you run the tests and you run the smoke so you don't have to copy the tests into this git repository or store them elsewhere as you have them packaged in the source rpn now I'm sure you mentioned about the B Clip if you would be interested in writing some tests for the operating system which mean like integrating multiple components starting services and doing stuff like that so this shell level integration testing library could be of good choice it has some nice functions support churnal and phases to make it very clear where the problem was like in the system setup or the test itself or only cleanup there's something to documentation and if you would like to experiment and create a simple test you just run biker wizard tool which will ask you several questions so the result is a complete test with everything with everything defined so that was a couple of examples and the overview and now we have roughly about 20 minutes to do some experimenting so we are here Petra, Mero, Dominic and also we have here Brno and Andrei who are willing to help you you would like to if you have any questions or start experimenting with that so even you could try to for example take a component and try to do a smoke test for that component which would be like calling a single command and such I would just have a question did anybody know how to use the container image or not there was a link there so in the if you run the container in the root folder there is a test directory and there are actually there were checked out repositories for two components seven at once is not a very good example there so root's home directory so you want to type cd because if you say root directory slash and I was looking around and slash so here are the instructions if you found the link so after preparing the image you can you can run it like this and then as just mentioned you can directly cd to the home directory and test sub directory and there is Python 3.6 tests already already downloaded and then with Ansible playbook you would run them so that's the command so here we have the tests we try let's try the Python 3.6 and we call Ansible playbook Python 3.6 sorry Ansible playbook test.cm there is everything there so there are some tasks which are done for all the roles for example making sure that the required packages are installed on the system then there are some additional steps which make sure for example if the tests have some special required packages for individual tests the roles would make sure that all these packages are installed like here installed a specific package requirements we see the GCC Python 3.6 R-Sync and Python 3.Tox and do some other steps and then finally the environment is ready it would execute the tests so the specification says as Mirro said if the tests pass the Ansible playbook should return 0 as return code with no problem we see here that there were some changes on the system and the final result was okay so 24 tasks were okay and here in the directory we would see directory artifacts and here you see the test log applied by the specification to have a output of the tests and test roles are quite concise here they just do here the result of the testing so I have here twice the result because I have run it already once and in the in the pass a small log you would find a complete log of running the test so here if there is any problem or anything you could have a look here could have a look here for more details so now if we jump if we jump to bash and run Ansible playbook so the page suggests you could run it with a text container so this I will show you how it looks like so the test demo looks like this there are some tests relevant for the classic test subject and there are some different tests for these the difference is in the FMF filter so from the test you will be selected only those which are tagged by container or atomic so if I run the playbook minus minus tags container and I am running in the container so we would get only those tests which are relevant to the container environment to be executed also this was the case of the shared repository so the role will also take care of fetching the test from the test repository and then actually exploring the directory for available tests applying the flexible metadata from our filter selecting appropriate tests and running them so here we see installed specific package requirements some additional dependencies which are missing are changed and installed so these tests are using vClip there are some packages some requirements are already installed in the system any questions maybe if you have to be free here to discuss right? this is quite a thing I just came from a crowd talk anyways how is it to improve the actual testing of the filter it sounds like there is a lot of moving pieces there fan messages going around I don't know I have a whole questions I guess let's say I just want to land a change in some part of this is that I would send up some containers and CentOS TI built from the upstream code do you know what I mean is that both in Flora and CentOS right? also so for the pipeline that is running for the specifications of course that is text for the tools like the metadata format that is also to utility the standard test roles are package in Fedora that has CI that will be tested once it is merged and updated the pipeline itself that coordinates the different pieces is on GitHub can contribute a change there that that will be run for the CI and if that checks out and it is merged from the pipeline it is updated automatically so I guess the sample change would be like common thing is that your log messages and some CI systems will try and use them to extract the most relevant error messages I don't know if the pipeline does that but that is one of the things as a developer it is like how easy is it for me to go in and improve the systems if you are using the standard test roles that would be a forward request against the standard test roles which you can also the standard test roles are easier to test so you can maintain that I don't know if it should be in that I don't know how many I may investigate usability is the main point especially with low velocity but I think that is actually being worked on so once we have that first thing in place it might be easier to iterate on that the puzzle consists of many many little pieces this Wikipedia portal I should list most of them so if you know where to look you can directly so for example I don't know you would find about in the metadata format so you can find some information here and link for the GitHub where to file issues or if you are not sure you just don't know it is possible to file a general issue here in the contact section so there is this Federal CI general project and we gather issues general we track them there and if we know where to redirect we can help you with that so here I just executed just so you know so FMF list when I entered this this is the shortest repository for the shell tests we have there just three simple tests for the truth of concept and you would be able here to select tests based on for which component they are relevant or if they have some tag yes so this is for this part FMF show you all the metadata for a particular test case for this login you see what is the component what the test does how it takes how long it takes to complete and such for the future improvements we have several ideas the test demo does not sound to us like extensible enough we would like to introduce a new format which would allow us to define more in more detail in what point of the release pipeline for example you would like to do some very basic test for the PURQ test itself so you would say there is a PURQ test check the code run the pilot on it and make sure there are no something like that maybe you would like to run a different set of tests for the scratch build which is created from this PURQ test then when the PURQ test is merged and the real build is created and now the question should this be merged into the compose or not then you could define some additional test coverage which would be executed and make sure that some maybe integration tests are run against this package which would make sure that it doesn't break other packages which are allowed to add so this is the very very fresh very fresh thing the CIFMF have a PURQ request just with the initial set of examples how it could look like just to give you a brief idea so for example the last one defined somehow how to discover tests so you could use like list the test or use the FMF you couldn't have some requirements for the for the hardware you can do some extra setup steps on this then you would select which tool should be used for the execution of the test and in each of these steps you would be able to say okay so I'm using just a plain text file for listing tests which should be done I'm using FMF for getting the information or I I stick with the old TCMS where I have like thousands of tests so I will use it there and here we would say for example so for the build we would like to run smoke tests that would be tier 1 and some basic test for that one once we do an update like body update or errata we would run this on all the architectures which are supported we would run additional tiers and we would do a separate test job only with security tests so that they finish as soon as possible so we can make sure there are no security issues in that so make some improvements in this area this is coming from real user stories for example the developers as you have distributed as a bunch of components it makes sense to test them together so there is a real use case when you run some tests only with all these packages together so that this should make it flexible enough to be able to execute those tests go ahead kind of along those lines maybe I just lost track of how the testing process works for Fedora maybe this isn't the right place to do that but for critical path packages and automation is there a way to use this system to say I don't know I've been a job update and I want to make sure that if you still have that kind of activity before that's going to tag it or not is there a way to do that when you run some packages and you run a set of functional tests when you're tired just go not just package specific for the package friends they were not targeting that but basically we would like to also have a composed level test or something so that definitely this should make it possible of course maybe it will be not in this give because this is not completely component centered but that's what we are looking for we would like also to make some consistency by defining how the Fedora how the message format which is shared on the UMB how it should contain the information about the test path or failed also to make this consistent and if possible also make this consistent upstream and downstream so that we could use the similar or same same tooling for processing the messages or emitting the messages this is started for the test progression and the results what we are looking into also for the rating event themselves to have a consistent format downstream upstream for the messaging even for the quality environment so if somebody enters a new build system we would like to standardize the format so it's not a mess like with all the other or the different build systems for the time they were created it's a little bit messy in the message environment so we are trying to standardize that and onboarding maybe later on legacy systems also Petri is showing something when you kick tests a little bit off can you tell it which of these what you just said you can specify which tests should be on when it's verified that's just coming I can tell try these tests kind of the same question if I'm not doing it locally I can do without committing anything I can add the test demo and do a scratch build minus minus SSRPM that would work as well currently the pipeline setup that it built picks up also scratch builds and run the tests according to this also if it is minus minus SSRPM where actually there's nothing really in the written that's fine still so if you create a pull request with this test demo so even if the test if there's nothing in this git and you just create the test the pull request which would contain this test demo like for the test execution the job would be run okay maybe I didn't understand but I would have to commit it to my local review so the question is if I just add the file to my local file system which is of course a good one whatever and kick off scratch build with minus minus SSRPM it would build what's in my local file system without that I have to commit anything can I still kick off these tests from your local currently now there's this that is currently not supported the test needs to be in this git or in a pull request you could test it locally because you just create the file I can still build on the Brutalware and it just creates for my local files and I will use the SRPM that is built on the official build system the question is if it would as well work if that has a test demo no because this is based on the test demo starting the git repository or submitted as a pull request if it's on your local because the tests are not packaged into the it's not packaged into the SRPM in this git it's not packed into the SRPM somebody that is a configure maybe didn't explain that so we are out of time thanks for coming if you have any questions you can reach us thank you


What's up guys? Welcome to a brand new blu-ray haul and unboxing for Avengers Infinity War because today is Avengers Infinity War day because Avengers Infinity War finally came out on 4k steelbook and also the original films got released on 4k's and they also are in steelbooks and they're all exclusive Best Buy So I had a little bit of a Best Buy haul today And I want to be showing you guys that haul and also doing unboxing for you guys And I've already reviewed the Avengers Infinity War blu-ray But I do want to review the actual 4k blu-ray. So we'll be having a little bit of a movie time today This will be fun guys. I got my gauntlet. But before we get into it I do want to announce the winner of who won my Iron Man Funko Pop. His name is Derek Johns. Congrats to you man Please please please it looks like you subscribed to my channel and that's awesome So thank you so much for subscribing hit me down below in the comments And then email me at ZachPokeReviews at gmail.com that way we can get into it And I can send this Funko Pop to you man But now guys let's get into the haul before we get into my main hauls today I did pick up Predators the three movie collection 4k blu-ray and digital copies of all the three predator films now I'm a huge predators fan. I like the Adrian Brody one actually. I kind of love it. It's a guilty pleasure of mine I like the predators too and I love the original predator This is a predator is one of my favorite like movie characters ever and I'm really excited for the brand new one So I had to pick this up. It was like only 45 bucks for all three of the films and Comparing that the first one was like 30 bucks for it. This was a steal I'm glad I got this can't wait to rewatch it and of course like I said I love the predator This one we got is the matrix to pick this up because it was like only 15 bucks on HDR 4k and this movie is a masterpiece like this movie is awesome It's one of the best action films ever made and of course I had to upgrade from just a normal blu-ray to the 4k how we get to the main event of the day It is Avengers steelbook 4k Avengers Age of Ultron 4k steelbook And of course Avengers Infinity War steelbook and these are the things that I will be unboxing for you guys showing you guys them off And of course doing a little bit of a movie time as I go rewatch infinity war for the fifth time at home And of course this time no wait 4k beautiful 4k Let's get to it. All right guys. Let's get to this unboxing some beauty right there Let's take these discs out real fast So we got Iron Man right there right in the back that badges looks amazing look at that Iron Man you look at this Sides this is a really nice steelbook. This is just going back to the classic right there classic Avengers right there I am really excited to revisit this film. I have not watched Avengers Well, I watched a couple months ago, but 4k it's kind of look gorgeous Can't wait to see all the colors popping off bring on to Avengers Age of Ultron Let's look how beautiful this thing looks at. Yeah, baby Ultron right there Yeah, beautiful damn the reds just pop out on the steelbook. This is a beautiful beautiful steelbook Of course you get this You get beautiful Ultron right there and I just I'm really digging that so far I'm really digging this so far. Let's peek inside for a first reveal boom. Oh, oh Let's take out these discs real fast Let's check out the picture with inside pretty nice pretty nice We get the image of all those other Iron Man bots coming in I dig it I dig it and then you get the discs right here Nothing really fancy. Of course. We've already had 4k's of these come out So these are kind of just the same but these are the steelbooks these look amazing now on to the main course Avengers Infinity Wars steelbook. We've been wanting this thing. We've been waiting for this thing Let's look at this beauty of a thing Obviously you see the ring light in my steelbook because it's just trying to get into the picture, but man Let's dig into this thing Here we go Thanos the main appetite right there the stones all shining up Earth in the background or maybe that's tight. I'm assuming that's right though. We got Avengers right there Giant a logo right there now. We're going to look right inside Hello impression, of course, we have the disc right here. Let's take all these out real fast And let's just master fight our beautiful heroes and sapiens right here black panther Hulk Captain America Iron Man black widow Thor and Gamora. You know what's surprising? I'm a little disappointed that there's no Star Lord in here Where's the Star Lord? Maybe people are that mad at him? Oh my god, but seriously the steelbooks amazing. It's beautiful. I love it Look at all these steelbooks. They are Fantastic and great in every single way and I think this is just great This is just a fantastic way to get about it. And yeah, I'm just I'm really happy with all these So guys that is my Avengers Infinity War steelbook. These are the unboxings of them I hope you guys enjoyed this and of course, we're gonna have a little movie time with this Guys I just watched Avengers Infinity War in 4k and let me tell you this film holds up even More, you know, like on the blu-ray on a 4k TV the visual pop out a lot Especially when you look at Thanos's face in the detail that they get into the CGI guy And the fact that it just makes me pissed at Steppenwolf looked so bad and just because we got Thanos Come on. We got Thanos But I just want to say how beautiful this movie was like this movie is insanely Insane Beautiful off the top my head I cannot wait to go back and rewatch the other Avengers films now and also in 4k if you have an upgrade to a 4k TV I was always so against it But it's worth it like it you can totally tell the difference on it and I the HDR the Dynamic range and all the colors the blacks everything looks beautiful can now recommend enough course guys This is my unboxing and also my haul so thank you guys so much for watching if you're new here hit that like and subscribe button I'll also go hit up see how much on films down below cuz right down there He doesn't get into advanced movie screens check out the movie news and also some movie reviews plus guys make sure look out for that Giveaway, I'm gonna be giving away at my own Avengers Infinity War blu-ray copy I'm gonna go pick up one in a couple weeks Just when I get some more money after blowing out and killing my bank account I want to save up a little bit cuz I got Deadpool also coming out next week But I'll be giving that away to one of you lucky guys and I'll be using gleam again cuz I really like gleam But guys look out for that. Thank you guys so much for watching and of course until next time stay classy


We're here today to honor the crew of the proud ship USS Utah For years in keeping with the wishes of the USS Utah survivors This very simple yet elegant ceremony has been held at sunset on the eve before the day of the attack on December 7th typifying the Navy's bedrock principles of honor courage and commitment Those sailors of the USS Utah Without ceremony and most without recognition did their duty under the most severe conditions For 58 of them it was their final duty Today during this beautiful Hawaiian sunset. We remember and honor them USS Utah was commissioned in August of 1911 on the same day as her whole number 31 She served with honor in the Atlantic during the First World War on both sides the battle flip the flag ship of battleship division one Following the war she conducted a variety of wartime readiness and peacetime missions on both sides of the Atlantic and South America In 1931 she was converted to a target vessel Where she helped train Navy pilots as a realistic target for exercises Involved involving carrier-based aviation units Later in the 30s. She became an anti-aircraft gunnery training platform Serving in the US Pacific fleet in the Hawaiian area. She became operational in 1941 On the morning of December 7th, 1941. She took multiple torpedo hits that caused her to capsize In much the same position that you see her today This afternoon we remember the 58 crew members who died on this proud ship At this time, I'd like to welcome Tom Leatherman the superintendent of the Pearl Harbor National Memorial Mr. Leatherman has been working for the Department of the Interior for more than 34 years starting as a biological science intern in a 1989 while still in college Before moving to Hawaii, Mr. Leatherman served as superintendent at four National Park Historic Sites in the San Francisco Bay Area Including Port Chicago Naval Magazine National Memorial and Rosie the Riveter World War II home front National Historic Park In October of 2021 he arrived here on Oahu as the permanent superintendent of the Pearl Harbor National Memorial Ladies and gentlemen, please welcome. Mr. Tom Leatherman Good afternoon everyone on behalf of the National Park Service. Welcome to the USS Utah Memorial but this this Memorial here was originally commissioned by the Navy and constructed and in 2008 the National Park Service assumed responsibility of managing the Condition of the Memorial as well as visitation But it was until about two years ago that we actually were able to start bringing people out to visit this site And to learn about this history directly And I'm committed to continuing that effort and bringing more people out here every we do it three times a week now and I think that it's really it's really our responsibility and our Our commitment to honoring those who lost their lives here to make sure that we provide an opportunity for people to come out here to experience the the the memorial itself and to pay their respects And I I have to say personally This is one of one of the The more moving memorials for me and in particular There's a quote that's on this memorial And if you when you get a chance, I would encourage you to go and see the quote And because it to me it represents Really the the the whole purpose of why we do memorials and why we Why we are here to honor those who lost their lives And it's a quote by frank moss who was the united states senator from utah and it was This quote was delivered During the groundbreaking in 1971 on december 7th when this was when they started the construction While we honor those Who here gave their last full measure of devotion? All of us hope and pray That the time will come When we no longer need to dedicate memorials to men who died in battle That we will dedicate memorials to those who live in peace To all nations and all men Thank you for coming today And um I appreciate all the the participation. I've this is the lot. I've been here for this is my third Um event and I'm I'm I'm actually very moved by the number of people that are participating in this event this year So I really appreciate you coming. Thank you, mr. Leatherman Now we'd like to remember the 58 crew members who perished aboard uss utah In keeping with this year's 82nd anniversary theme And passing on of a legacy of hope to the next generation Cadets nevea woods and audrey kane of the highland high school junior rotc unit from sparta, ohio Will read the names of each crew member lost aboard uss utah the morning of december 7th 1941 Stan syndrity the chief interpretive ranger with the pearl harbor national memorial will ring the bell after each name is called seaman second class william d r buckle fireman third class joseph barda lieutenant commander Rudolph p by elka seaman first class Virgil c bigum lieutenant junior grade john e black fireman first class john t blackburn seaman second class palace f brown fireman third class william f bruner officer cook second class feliciano t gugheran seaman second class george v chestnut junior seaman second class Lloyd d clippard fireman first class joseph u connor fireman first class john r crane seaman first class david l crossett fireman second class billy r davis seaman second class leroy denis signalman first class douglas r rakeoff seaman second class william h dozer seaman first class vernon j eidersbig quartermaster mevlin a gondre bosan mate kenneth m gift seaman second class charles n gregory lieutenant junior grade herald a harvison seaman second class clifford d hill baker second class emory howd ensign david w jackson seaman first class leroy h jones ships cook second class william a judas yeoman third class john l caylin gunners mate third class eric t campmire fireman first class joseph n caroban seaman first class william h kent gunners mate third class george w laru lieutenant junior grade john g little the third seaman second class kenneth l lynch seaman second class william e marshall junior electrician mate rudolf m martinez lieutenant commander charles o michael seaman second class marvin e miller seaman second class donald c norman fireman second class oris n norman electrician's mate second class edwin d odegard chief storekeeper elmer a parker ships cook third class forest h perry seaman first class james w phillips machinist mate first class walter h ponder ship fitter third class frank e reed seaman first class ralph e scott fireman first class henson t schaus machinist mate first class george r smith seaman first class robert d smith seaman second class joseph b sowsley fireman third class jerald v strintz chief water tender peter tomich fireman third class elmer h olrich fireman third class michael w villa fire controlman first class vernard o wetridge fireman first class glenn a white thank you cadets woods and cane and rangers and dritty at this time i'd like to invite lieutenant chris bell to provide the benediction let us pray gracious and eternal father thank you for the opportunity together this evening on the 82nd anniversary of that fateful morning we have taken time to solemnly remember who faithfully served and perished with the uss utah as their names have been read we have once again heard the echoes of sacrifices made by those entombed in this sacred place on this occasion it is appropriate that we recall the words of abraham lincoln who said in another hallowed place the world will little note nor longer remember what we say but it can never forget what they did here indeed as we depart let us never forget those who carried out their duties ultimately fulfilling the principles of honor courage and commitment as they gave the last full measure of devotion for their shipmates families and nation may their legacy continue by your grace to live on in us and future generations as we continue to carry the mantle of freedom and hope in your holy name i pray amen ladies and gentlemen this concludes our ceremony we'd like to thank our reef donors for the beautiful wreaths that you see on display on the memorial pacific historic parks the national park service and the sons and daughters of pearl harbor survivors we invite everyone here to take flower petals from the basket and lay them in the water paying your own personal tribute to the crew of uss utah and all of those who gave their lives on december 7th i invite you to enjoy the peace of the Hawaiian sunset and the promise of a new day it brings check check you can all can start coming up and we'll have the flower petals here and then you can walk out to the memorial


You really got to be aware of anything that is fat free Hey there and J root 22.com here with another low carb keto carnivore chat and today. It's gonna be a quick one.   It's like 70 grams of carbs and just so you know whole milk is About 50 grams of carbs and it gets even worse when you get to 2% milk 1% milk and then skim milk the the less fat and it has it has the higher the sugar and Contents so comparatively a quart of heavy cream is Zero carbs me it it may have some maybe maybe it's 20 grams of carbs for the court because they have a weird way of Measuring and if it says if it's under 0.5 grams, they can say it's zero grams So I really don't know the actual truth because the serving size on the heavy cream You get 60-something servings per I think it's one tablespoon is a Serving of heavy cream in half and half a serving size is two Tablespoons and a serving size of whole milk is a cup. It's like bizarre. I don't know why can't they just standardize Or put a chart in if you're one ounce two ounce four ounce, whatever eight ounce They have the serving sizes are different. You have to be Aware when you look at the nutrition facts on any product if you ever want to compare something because most people just look at the big bold number on there, which is the calories and Some people might look at the fat and you know smart people look at the carbs and sugar, but We just look at the cars We don't care about the sugar because sugar and carbs are the same to your body. So This is like 70 grams of carbs. It's ridiculous. It's not it's fattening That's that's the truth.  We buy our heavy cream with carrageenan in it at Walmart or Al Aldi and I think that's that's the best way to go And it satiates you like you can have a big cup of coffee in the morning with heavy cream and not be hungry Whereas if you put skim milk or a fat-free half-and-half in your coffee, you're gonna be hungry really damn quick So watch out for this stuff and that's that please hit the like button the subscribe button We have three videos a week on this channel and enjoy your day