Hi everyone. Welcome to the SIG architecture introduction and update. You might be wondering what SIG architecture is and what its role in the Kubernetes community is and what we've been doing for the past time and what's new coming. Probably we'll talk up if you get some time we'll talk about those things too. So I am dims. My nickname is dims. So you can call me dims. On Twitter, GitHub and Slack, CNCF Slack, Kubernetes Slack, I'm easy to find, DIMS. So hit me up if you have a follow up later or if you want to get engaged in the community. Happy to get you all on board. John? I'm John. Yep. I'm John Belamerick and I'm also John Belamerick everywhere. So easy to find if you can remember my name. And so, yeah, happy to chat with any of you anytime. If it came to this talk, you have John's name. Just look up the schedule. That's right. Yeah, let's get started. Okay. So let me go over there. So it's a little bit easier than you can like switch. So the goals of the Kubernetes project is anybody not using Kubernetes right now, right? So all of you are using Kubernetes and you kind of like agree with the statements that we've made there. Those were the goals that we written down in our documents saying these are the things that we would like to see. This kind of helps us going forward too. It's not just the state of the thing that we're talking about right now, but we're also when we design new features, when we think about things that we need to do and how to do it, these are the goals that literally helps us figure out like, okay, for example, number three, right? Like, is there if when we're designing something, Hey, this is just too much for users. It's too complicated. We need to simplify. Can we like go halfway to make it simpler for the users, even if it is harder for us to do it on the back end kind of thing? So we use this as a mechanism to say, okay, fine. You're writing a new enhancement proposal. Please take a look at these goals as we do the design. So we do have some values. These values are very important to us and you will see these reflected when you come talk to us, when you come and talk to us on Slack or mailing list or PR reviews. This is what we believe in and anybody disagree with any of these things? Probably not, right? So this has kept us very good. In fact, let me take one thing and poke on it, right? Like for example, automation over process. So if you go look at how our testing infrastructure is set up, right? You know, it's running on really good with a few bumps here and there, but it's mostly things are happening on its own. We write bots and bots talk to each other, bots talks to people. So that is one example of how we are doing number three, okay? Next one. So the Kubernetes is part of CNCF. So overall structure is CNC, well, if you want to start right at the top for technicality, there is Linux foundation and there is CNCF and within CNCF, you have the CNCF TOC and CNCF TOC has a bunch of tags, technical advisory groups and tag run time is probably what we come under. And under TOC is all the projects. Kubernetes is one of the projects and in fact, the CNCF foundation was started with Kubernetes as the first project. So within Kubernetes, we have a whole bunch of special interest groups. Some of them go deep. Some of them go horizontal. I'll take some examples here, like take SIG windows. They focus on how to run Windows based workloads on Kubernetes better. And another example, if you take SIG release, you can see that that SIG owns the release process and it coordinates amongst all the SIGs. It fixes out the calendar date when we need to make a ship and then we work backwards to figure out when there's a feature freeze, code freeze and things like that so that we can have a release together. And we end up defining policies in the SIG saying, hey, we're going to do three releases a year. We're calendar based, for example. So those are the kind of things that we do in a specific SIG that is horizontal. Testing is the same way. So it spans across all the SIGs that we work on. So that's the way. And we do have some special committees for code of conduct, security response, and steering overseas the whole thing. In fact, the way to think about it is when somebody comes to us to do some work, we look if it fits in any of these buckets. And if it's not, we'll ask them to write a charter. And that charter essentially says we own code repositories. This SIG will own code repositories that pertain to whatever it is, X, Y, Z, right? Like something new you want to bring into the community. So then the steering essentially will approve the charter and you begin your work. That gives you the validity in the community to go around asking for resources and talking to people. And there is a technical lead and there is chairs and then you start doing your work and you figure out how you want to do your work. And we also have, like, if you take SIG note, for example, right, you talk about how the KubeNet works. Storage is similarly. How does CSI fit into the picture, for example? So essentially committees, SIG groups, working groups and user groups. We are trying to get rid of the user groups and we are trying to push that out into the CNCF layer, so to say. And this is constantly evolving. We added new things. We took some old things out that were not really relevant or there was no work being done. For example, there was a service catalog, SIG service catalog, and they were not doing anything. We bumped them out. There are other things which span multiple SIGs. We call them working groups. Working groups, people from multiple SIGs collaborate and the owning SIGs will pay attention to what they want to do and how they do it. John. Yeah, I mean, I think one of the main points with this is that distribution is better than centralization. And so each of these groups will own a part of the code. The project level things tend to set policies and processes across the project. So architecture fits within that area. We don't actually own much, if any. We maybe have a little bit of tooling code, but no real code or functional code. And so, you know, that's kind of where we fit in this. The horizontal pieces are things that every, you know, the API server, the API machinery and then the vertical are like resource management type of things. So that's kind of how the project is organized. So specifically talking about SIG architecture, our scope falls into, like I said, kind of this cross project area where we're sort of the monks who keep the design principles kind of in line and we have groups and processes that will help other SIGs as they're coming to design a given feature, make sure that they're in line with those design principles and make sure that we're following all the different keeping Kubernetes, the Kubernetes that you know. Space, space or tab? Oh, arrow key? Okay. Next. Okay. So like I said, the processes, different cost credit, cross cutting processes around conformance API review and then each of those processes we can go to the next slide is sort of, oh, I guess that comes later. Okay. We can still go to the next slide. So we'll talk about each of these later in a bit. Other kind of issues tend to come up for us. So whenever there's a sort of question between SIGs about how something should be done, what makes the most sense in the context of Kubernetes as a whole, they typically will bring that sort of thing to us. We're not really an escalation path, but a lot of the people that participate in the SIG tend to be people that have been with Kubernetes for a very long time and have very deep and broad knowledge. And so when there's a conflict between say the two chairs in a given SIG or the TL, you know, a couple of TLs in a given SIG and they're trying to figure out how to make it done. We're not going to make a decision for them, but we will have a conversation with them and try to negotiate or broker. That's a good word. Time broker and sort of come back to those values, come back to those principles and say, okay, if we go back to those principles, if we go back to those values, let's think about each of these viewpoints in that context. So like other SIGs, SIG architecture is arranged into sub-projects. So sub-projects then have owners. Those are the people kind of responsible for that area. So we talked a little bit earlier, we saw a list of the different processes. Each of those processes is effectively run by one of these sub-projects. We have five sub-projects in SIG architecture and we're actually going to drill into each one. Yeah, sure. So how many of you used CRDs, for example? Right? So CRDs have to go through CRDs and other things like all resources have to go through an API review, right? And the API review essentially says, okay, if you're adding a field or removing a field or you're converting from, the classic example we have is like typically, you know, resource originally when defined was a field, say an IP address, which was a string, right? And then you figure out like, oh, there needs to be many IP addresses, so you turn that string into an array. We've done this before, but there is a set of rules and regulations because we have to think about versions queues, how to support mixed versions of things, the API servers and the cubelets. We have to figure out if older cube CTLs can work with the newer API servers and so on and so forth. So through time we have accumulated a bunch of thinking around how we can make it easier because, say somebody from SIG storage comes with an idea and we say, oh, we've done something similar before, but here were the pros and the cons and the problems, so maybe you should think about doing it the other way where we had lesser problems for end users, for example, right? So that is what the API review is and we have a project board and we actually written down the changes and the conventions and things like that. So when any of the SIGs come to us for API review, we point to them to these two documentation so that they can go read what it says and then come back to us and say, hey, we looked at these things, some of those make sense, but we still want this unique thing that we want to do here, is it okay? And then we end up negotiating with them, talking to them and like coaching them through the situation so that it's good for the users, it's good for the community and it's useful for the developers. Next one. If I can just say a couple of things about this. So API review is sort of one of the most critical aspects in the development process and in the entry APIs, the built-in APIs, everything must go through code through API review and in a sort of, if you're looking to participate in a project and you really want to get deep into lots of different areas, or even if you're in a, want to participate in, say, SIG node, working towards being an API reviewer is a great way to get involved, we really need more people to do that because it becomes, it can become a bottleneck. We have many reviewers for API, but there's only a handful of people that can do the approvals, so it requires a sort of a lot of knowledge and you need to do a lot of API reviews under the guidance of those few current API approvers before, you know, you're sort of like, okay, you're good to go. We've scraped our knees and bruised our, so many times, so that's why we have this review, so to make it easier for people who are doing the work. So reduce the burden on them and give them well-defined things that they can follow. Exactly. And for CRDs, if you want to use the Kubernetes. You want to use the kates.io group, then you need to go through API reviews. Exactly. So code organization is a massive, massive effort. So everybody comes to us with a feature and they say, hey, this is a new feature, this is what we want to do, this is going to be awesome, everybody's going to love it, and we vendor the code into the tree and do things from GitHub here and there, and guess what? After six months, those people are gone, right? Because they're off doing other things and there is a set of people who have to maintain the dependencies, update your element versions and make sure that things are not broken. And there is this constant thing about, hey, there is a CV that was in this dependency and you're using this dependency, my scanner is screaming at me, can you go, hey, there is a set, for example. So there's plenty of code maintenance things that we need to do. Another example is, hey, we need to switch go versions, we need to go to 118. And in 118, can we use all the new fancy things that is coming in 118? Somebody has to say, hey, don't do it right now. Let us ship 124. When we go to 125, you know, then we can start adding generics a little bit. And then we'll figure out how it works and then we'll expand the usage of generics somewhere else. So maybe we should start with libraries first because then those are easier, smaller to tackle. And we'll figure out how we do the testing. Maybe there's some additional problems that we'll end up seeing with generics. One simple example is, hey, we need to patch something in master and we need to back port 124. And 124 doesn't do generics, right? So those kinds of issues, people come to us and we work through those situations with them and there's a constant effort to make sure that the dependencies are up to date, they work and the people who are ending up importing Kubernetes code into their repositories, they should feel that we're not pulling the rug under their feet either, right? So how many of you have projects where in your Go mod files you import things from Kubernetes? Yes? So you are our audience, right? Like if you change stuff that is going to break you, come yell at us. If the tags that you want is not in the Kubernetes repositories, come and tell us, we'll help you fix those things. That's yours. You want to do that? Sure, I can do it either way. So one of the other sub-projects within SIG architecture came out of, well, SIG PM closed down and so we adopted the enhancement process. So the enhancement process, for those of you, how many of you have contributed to Kubernetes? A few of you, right? So if you want to bring a new feature to Kubernetes, you don't just start writing it. You want to have some agreement amongst the community that the feature is appropriate for Kubernetes, that the feature is designed properly in alignment with the other features so people know how to use it without having to read too much documentation and that it's among other things. And so we have this process called Kubernetes enhancement or CAP process. This is probably the thing that contributors interact with the most that comes out of SIG architecture because it is a little painful, right? But it's like writing a design document.  So we own that process. There's a sub-project that's trying to make that better. So if you're one of those few people that raised your hand and you don't like how the CAP process works, come talk to us at that sub-project. Come help us make it better. Some of us go through that process. Some of us don't. And so feedback is what makes it better. Yeah, this was supposed to be my slide. But even if you wake up in the middle of the night, either one of us can talk to either of those slides. Yes, good point. Another sub-project conformance. So if you look at different Kubernetes distributions like GKE or Tanzu or some of these other ones, right? Everyone will have a certified Kubernetes badge. And if they don't, they can't call it Kubernetes. So that's a program run by the CNCF that allows vendors to submit their test results and then CNCF gives them the badge or not. However, it's this group that decides what those tests are. Which tests actually define Kubernetes? Which functions are part of Kubernetes and which are optional functions within Kubernetes? And so sort of where does the name, when do you get the rights to use that name? Which tests do you have to pass? So we've been working on this for years and we had a whole bunch of technical debt. There was a team from a company in New Zealand called II that's really done a tremendous amount of work for the CNCF to kind of pay down that debt. And this is not just to bug the vendors to pass this test to it. It is to make sure that you all can depend on the output to the project, manage cloud providers. You get a consistent experience across all the products that you use that say that they support Kubernetes and that is the reason we do it. So it's not for us, it's for you. Absolutely, yes. All right, production readiness review. So this is one of those things that people don't like. Well, contributors don't necessarily love, but it's important. So two years ago maybe, as the project matured and there's thousands and thousands of people depending on it to be stable, we introduced the process that a lot of big tech companies use internally, which is for production readiness review. So essentially it's contributors, when they write those caps, we added a big questionnaire in there that as they move from alpha to beta to GA, they have to sort of document how you turn the feature on and off, what the metrics are for the feature, what are the known failure modes and how do you detect them. Basically make it observable, make it supportable, and ensure that people who take this next version of Kubernetes that has this feature don't have to roll back. That's the main goal.  And again, this is for you, not for us, because we are putting ourselves in your shoes and we are asking the question, hey, we turned on this feature, what metrics can I go look for that is new in this feature, for example? Right, exactly. How do I know the feature is working? Yeah. How do I know if people are using it in my cluster? If I'm a cluster administrator, how do I know my application developers that are using my cluster are using this feature? And you see the big QR code. So every year we do a survey, since we started this third survey, we do a survey to see if it's effective, right? Because this is a burden on our engineers and in the community. We want to make sure that we're not wasting their time. So those of you that operate clusters, please click on the link, go fill it out. It just asks some questions about have you had to roll back? How many clusters do you have? How many nodes do you have? Do you think Kubernetes is more reliable than it used to be? Yeah, we closed this at the end of the month, so I'll just do it today. Yeah. So if you go look at the CNCF landscape, I know it is a huge and big, and how did we get to that spot, right? That is because we were thinking about these things. We were saying, okay, we need to distribute responsibilities. So there is CSI, CRI, CRI. There's like, you name it, we have an extension point, we have webhooks, we have mutating webhooks, validating webhooks, we have all kinds of things where people can integrate. It was not the way at the beginning. Like if you go look at, you know, five years ago, Kubernetes versions, and check those things out, you won't see it that way, right? Like because everything was in a monorepo, everything, any vendor wanted to get anything in, everything was going right into the same bucket. But over a period of time, we did all these things so that people can do things outside of us without asking our permission, without needing to put things in our repository, for example, right? And again, so it's exploded the ecosystem. There are literally hundreds of projects out there that extend Kubernetes in one way or another, and that's a conscious decision. There are some bad outcomes to it. For example, the people who used to work on the code now go do something else, right? So we need to figure out how to attract them back too. And that is happening too, because there is plenty of times where what we have done is, we've done an extension, for example, scheduling, right? So a scheduler is extremely, you know, configurable. So people went to experiment outside and now they're coming back and say, hey, we did this experiment in like five projects. We are trying to do different things. Now we think that we are at a point where there are some things we need to add to Kubernetes code, then we can go around changing everybody else and change the usage of Kubernetes. Again, the examples, I was already mentioning that, you know, one example, funny example, CRD was an iterative thing. It wasn't CRD before, it was called a TPR, third-party resource. That was one more experiment that we ran and we found some resources and we were trying to figure out how people use it and then we said, incorporating all those feedback, then we designed the CRD, then all of you are using CRDs. So, go ahead. Sure. So, where are we going? Where's sort of the overall project architecture going? And a couple of years ago, we did this talk and it was like, well, maybe it was at the contributor summit and we said, no, and neither are we and we're not going to do it. And the reason we're not going to do it is because instead, we focus on building extension points. And by building extension points, we don't need to change, we don't need to go to a V2, which of course, if you're familiar with semantic versioning, a V2 means we break backward compatibility. We don't want to do that. So, we can continue, we're going to continue on that. There's a real effort around things like CRDs, and this would be an API machinery that that, but would make them as fully functional as the built-in APIs. We're working towards it, it takes a long time. So, how can you participate? We do this. We have mailing lists. We have Slack channels. All we need you to do is come help us. So, the things that we are going through, for example, the KEP, enhancement proposal, if you are interested in a feature that is going to come out in 125, we need your feedback.  And then you need to wait till 126. So, come talk to us. Like I said, we don't buy. So, speak up, offer your thoughts, help wherever you can. And typically what we say is come to the closest to what you're already doing. So, for example, if you are interested in new features for your products, then come to the enhancement process. If you are a maintainer who loves maintaining libraries and things like that, come help in co-organization, for example. So, there is a lot of work to do, too few hands, and we would like your help. Thank you. Thank you for the talk. I have a question about GA. So, as I understood, you folks actually like in charge of letting the feature happen in the first place, but then there's a life cycle, and then feature reaches GA. I've heard an opinion recently that if it reaches GA, it's there forever. And since then, it will not ever move from... It's not true. Docker Shim, gone. Docker Shim is one example. Can you give a... Oh, there's lots of examples. We are removing the PSPs, too. So, we've defined our life cycle for the PSPs to go out and it will be replaced with something else, for example. All right. It gives us hope that at some point, Ingress Resorts will go away and we'll proceed with that. Yeah, it is Gateway API. Gateway API is the new thing. We want you all to switch to the Gateway API. That's being defined, and people are working hard on it, and that's what we're going to go to. So, deprecation policies are sort of a purview, but we do really want to make... In an ideal world, it's been specifically APIs. Once they hit a GA v1, you don't want them to go away because people have built things on top of them and when you take something away, now, that person, that whole ecosystem built on top of that is either locked out or they are forced into a migration process. So, we do take very, very long time to do it, but we do it. Yes. We've also said we have an escape clause too in our documentation that says hey, we reserve the right to do this to make things better. So, yes. You mentioned there was a list of values and you said that it helps you navigate if there's an event of uncertainty or some conflict, you take the list of values and it helps you come in. Correct. I'll give you the exact example again with the PSPs. The people in the SIG said hey, SIG Auth, they said, hey, this is not working, let's just get rid of it. Let people use SIG Auth, and other ecosystem projects to do exactly the same thing and people can already do that. So, when all those things are there, why do we need to do it? That was the initial balloon that was floated from SIG Auth. Then SIG security came to us and said, not cool. We need something basic which will cover 80% of the cases and then maybe the 20% of the cases, the advance cases, we can use other things. So, that was the negotiation and that was because we raised a cap and there was follow-ups and then we had meetings and we figured out where we, again, goes back to meet the users halfway as a value. We said that is exactly where it kicks in. This is where my question is, among those values, are all of them are equal or some are more equal than the others? Is there a priority in the event of like... I think it's a more human process than that. I do want to say one thing there which is people in the room make the decision. Those are guidelines for the people in the room because the same people are not going to be in the room all the time. Those are guidelines for the people in the room to say, hey, please think about these things when you are making a decision. And the order of the priority of things might depend on the people in the room but it's a general guideline. Thank you. Any other questions? Come on, there has to be one at least. Mohammad. I have a simple question, right? So, Kubernetes v2, I'm told that's not a thing. But how do you align that with the entire removal of v1APIs, for example? It's not as a contributor. There's no contributor. Again, we have a place where we write down some things, hey, when we get a v1API, maybe we will do that kind of thing. But there is no proposal on the table for a v2API and there is no way v1API is going away ever. Well, let's say that a little differently. Each API can evolve in its own time, right? So every API group will have your group version kind. So your group version, you get a v2, we have some v2s, we have a lot of scaling as v2, we have a few v2s. But what we're talking about is Kubernetes v2, which we mean fundamentally changing the API infrastructure such that it works differently and it breaks everything. That's not going to happen. Instead, we've architected this in such a way that individual pieces of functionality can evolve over time or at least thought processes in mind for some people saying what is the core set of things in the Kubernetes core API that are not in GA that we need to get to GA before we can say hey, maybe we can do a LTS version now, right? So, and that is an even longer discussion but the idea is we are trying to push APIs to go GA so that then we can do an LTS or somebody can do an LTS even if we don't do an LTS. I think there's also another thought process or these are all just sort of vague ideas people have but there's a part of Kubernetes that is sort of container orchestration and there's a piece of Kubernetes that is the API machinery which is being used for many, many other things than container orchestration and so if you you can kind of parcel out potentially that gem into a smaller core of Kubernetes and then the other functionality is not necessarily unnecessary like namespaces are necessary, users are necessary there's a bunch of things that we can do but there are vendors that don't ship Kube Proxy because they do it differently so they don't need Kube Proxy Cillium for example so and there is projects like virtual kubelet they say hey this kubelet thing if we replace it with virtual kubelet we'll do another set of use case and scenarios there is a version of kubelet that is written in Rust that supports Wasm so that's another use case so there are a lot of things happening in the community where people are trying different things out and we are watching, listening learning from what they are trying to do and at some point we'll evolve things over a period of time we just want to do it in a fashion where we are not going to break you and you know there is guarantees around stability versions queue and things like that which we have baked in so that we are trying to do the right thing for you so it's easier on you thank you for the question any others yes how much time does it take you to take this role of your work life 100% how much do you put yourself into this architecture team role 100% personal question I think it varies we are co-chairs and we have one other co-chair Derek Carr so I think it varies it's not just the two of us we are just the chairs all of these sub-projects have other team members people working on it and it varies during the time of year I am one of the people that does production readiness reviews and there is only two or three other people to do that for the whole project so that means in the two or three weeks before enhancements freeze I am spending a lot of time he gets reviews John please this one there are other time periods where it's like I only spend a few hours that week it varies depending on the calendar time same for me like co-organization we try to do whatever we can early in the cycle like before alpha one or something like that we have milestones so we try to put as many of the changes so that it bakes in the CI systems so over a period of time we will watch and say hey something is wrong so you start making changes early and the more invasive the change the earlier you do it for example we are changing K log so we try to do it right early in the cycle so later in the cycle people are like okay it's smoothened out over time and nothing is bothering the CI systems and users will be able to use it fine okay I think we are out of time but thank you all thank you


Welcome folks. This is Tom O'Brien of TFNN. We have five days a week. We have seven hours a day. We go 24 hours a day on the Internet at TFNN.com. Always remember folks, whatever you think about, you bring about whatever you focus on grows. Hope everyone's having a great day, safe day. It's making a great night, folks. Don't take anything personally. Transform your life. When you refuse to take things personally, you avoid many upsets in your life. You're feeling anger, jealousy, and even sadness will simply disappear if you don't take them personally. Knock it wise. Let's take a look at it out here. We have the Dow Industries down 287. NASDAQ's up 109. S&P's down 40. Gold. Gold contract down $10.10 trading at $19.33 an ounce. We have Silver down $10.22.60 an ounce. Light Sweet Crude off $1.51. $81 flat. Notes and Bons. Ten year note. Down six ticks trading at a price point of $109.25, the 30 year down 18 at $120.04 and $Kingdala. $Kingdala's up 19 ticks trading $103.209. The Euro is at $109. The yen is at $145 and the British pound is at $127.00 to $1.00 at U.S. Dollar. Our phone number is<PHONE_NUMBER>. Give us a call, folks. I want to know what's going on in your world and the world of the S&Ps. Let's take a look at it. Let's go into the futures first. So we get into the futures. Bottom line, right off the open out here today, they sold it down. The lower the day is 4458. Right now we're at 64. And I suspect the bottom line is that it's probably going to go after this because it is a little high volume low. We get 39,000 contracts down there. And the above one only is 24. So the pressure is still downtown at that level. Now that's in the futures. Now watch this. If we go to the spy, what you're going to see is that we're going to get about the same amount of volume that we had at the low on Friday. And the price at the low of Friday was $443.34. Well, we hit $443.47. We did $68 million here at $46.00. So I suspect we're going to do, we'll probably do around 60. And I will sell the shakes out. I don't think it's going to get saved on price, meaning that you're not going to get down there. You're not going to get a rejection of global price. But here's the divergence. The divergence is if we, let's do the NQs. Go over to the NQs. You take a look at them. Enter today first. So you take a look at the NQs. And the way the NQs are set up, you know, it's telling me that, yeah, you know, same deal, meaning we're going to probably close at the lows, which is 107 versus the 152 that we're here now. Okay. Because the 107 had volume at the 30, 16,000 contracts. The pop of above is only 12. So the pressure is still down there. Okay. That being said, if you take a look at the Qs, the Qs, you know, you can almost say this is almost a sideways move. You're now in $2.64 cents. But you can see yesterday, you know, we did volume of 42. And you got up to a price point at the 370. You started off at $364. I don't see this thing going on at $364. I can see it going to $366.53 again, the low of today. But then you're just going to, you know, basically have more sideways move. That's what this looks like. And what's holding this up, folks, okay, is the trading that was developed out here on June 9, 10th and 11th. You can see this quite clearly. I mean, there's some big numbers right in here. You know, you got one, two, three, four, get four days with a lot of volume here. That's what's holding this thing up right there. Notes and bonds hold different ballgame, man. This is a whole different ballgame. You get, you take a look at the note and bond market. And you know, right now we're at the highs of the year, literally, as we're speaking, 4.217. Make sure of that. Let's go back a year. Oh, no, the high of year is 4.242. So we're not at the high of the year yet. We're going to be, though, you know, this thing's not slowing down, man. They're selling this thing off. You know, your next stop, TY1. We did this yesterday. But it's important each and every day to tell you to keep following this up, because bring this back, because if we break this first level, the next level down is pretty intense. I'm going back 15 years, but it's the low of last year that it's going after right now. And the low of last year. Come on. Okay. So you can see the low of last year was 109.10. Well, we hit 109.11 today. Okay. That's telling me that we're actually going to get out of this 104 or something. Because there's not a lot here. That's the case. That means lower price, higher rates. And then if we go over to the dollar, the bottom line is that this dollar wants big numbers, man. You had the wide price spread out here yesterday. You went back to the beginning of the wide price spread. You rejected lower price today at 102.18. It's not a stretch to get up to this 104.690. And if that's what we get, you're going to get some turmoil happening ASAP. If we go to the crude market, the crude's already sniffing it out. The crude market, you know, bottom line came down fast and furious today, 278. You're at 80.98. Anything inside 81.44 puts it in the lower range again. So we'll see whether they're just going to go up and down in that particular market. We go into the gold market and, you know, gold looks to me like we have the 1904 coming at us. And the 1904, what that is, that's how we came off the bottom the last time going all the way back in February. That would be considered nice. You know, the bottom was 1885. The reason I'm going with the 1904 there, that's the strength, because what has happened is that you're coming into this with low volume. So when you come into it, the cool thing is when you come into it with low volume, you know, bottom line to keep destroying price, that's when you have a better probability that you're going to reject where the strain started at that 1904 area. Dow. Dow industrials right now trading down 292. We get the NASDAQ off 121. SAPs off 42. Stay right there, folks. Coming back with our man, Mr. Basil Chap.


Members of the Japan Ground Self-Defense Force recently worked together with soldiers from U.S. Army Japan and a U.S. Airman to conduct tactical combat casualty care training or TC-3 at Sagami General Depot, Japan. The training was meant to enhance the soldier's ability to efficiently provide medical care in a combat environment and also to develop a better understanding among the U.S. Army, U.S. Air Force and the JGSDF on how each service provides medical care. The JGSDF members are currently attending the 101st iteration of a 10-week bilateral cooperative work program class or co-op for short at Camp Zama, Japan. This is a mandatory training that we're doing. It's something that's going to not only is it mandatory, but it helps out soldiers, right? We want to have at least one CLS personnel for every squad is the minimum we're going for, but really the U.S. Army and DHA has asked that we do everybody TC-3 trained. So everyone should have some form of TC-3 training, whether it's all combatants, CLS, or up to my combat medics and paramedics. The training consisted of three distinct phases, care under fire, tactical field care, and tactical casualty evacuation care. The participants were tested in realistic, simulated scenarios on the skills and techniques they learned over four days of instruction. It was great to be able to receive training from U.S. Army soldiers who have actual combat experience. I will definitely bring this experience back with me and share it with my unit. The most impressive moment was the pressure delivery device training, in which they used a bottle to apply pressure to stop bleeding from the groin. It was my first time seeing that, so I was very impressed. After participating in the TC-3 training, I got a sense of how kind the U.S. Army soldiers were. When I had a hard time understanding some of the medical terms in English, everyone in the class tried to explain it in an easier way. I was also impressed by the energy of the female soldiers. They were very strong, and I felt like I wanted to be like them in the future. Nearly 20 U.S. Army, Air Force, and JGSDF members participated in the training as a way to enhance U.S.-Japan bilateral relations and interoperability. Everyone's just so nice and ready to get hands on. We were working with some higher-ups. I had a first lieutenant, a mass sergeant, and a sergeant's first class, and a sergeant major in my group, but everyone was just so willing to be hands-on, and it's just a humbling experience, so it was great. I appreciated it. As the only Air Force person in the class, the biggest thing that I wanted to achieve was just proving to the other members that, hey, even though there's not a lot of Air Force people here, we're still part of the team, and we're still able to participate and communicate, and if they need us for anything, like, hey, guess what? We're going to raise our hand, and we're going to be a part of the team, and just do absolutely anything that needs to get done, so you can count on us. What I always tell my attendees to take away is these are guidelines. Build to them. All right? I gave you a basis.  Find what works for you. Find ways to make it better. Find things that you can educate yourself on and that you can keep learning. This is Kevin Crates-Ark reporting for U.S. Army Gears in Japan.


My name is Susan Hewitt, and I'm one of the three people who started the Loved Art article. What's a Loved Art? A Loved Art. Loved Art? A Loved Art? The dart that Cupid shoots a person with. When we started Loved Art, there were three of us that created the first draft of it. Never before, really, in the history of humanity, if so many people come together on a volunteer basis to build an extraordinary resource like this that everybody can use. So you just write freely, and then your work is edited and improved by the other people who are working on it.  And they use it before mating. Each snail or slug tries to stab the other one with a Loved Art. Oh, my God. So that's how it happens. Because Cupid is a story from ancient Greece. There might be a real parallel between Cupid and his Loved Arts and the snails and their Loved Arts. I like Wikipedia a lot. I'm a big fan. I love Wikipedia. When I meet other Wikipedians, inside them, there's this light that comes from building this extraordinary structure of knowledge. I'm not a believer in ignorance's bliss. I think the other way around, knowledge is power. So I think Wikipedia is a very, very powerful asset for the world. It doesn't matter what your area of specialized knowledge, there's a use for it on Wikipedia.


Hello lovely fragrance lovers. It's Healer again. H loves fragrance. Today we're going to be testing out some samples that I got from the perfume shop. So perfume shop have got this really great service where you can order samples for one pound each. You can only order a maximum of three samples and you pay three pounds for postage and packaging and they use Hermes to send it out to you. So it does get to you pretty fast and you're getting the carded samples so you can be absolutely certain that it is the real McCoy. So I love using this service. I think that this is my fourth set of samples now that I am getting today. Now normally when they deliver the samples they do deliver them in an envelope, a GP envelope, but for some reason this time around they've come in a big box which is a little bit silly but this is the first time that they've done this in the four orders that I have made with them.  Okay, right. So this is what we have in here. So we've got a Dior. I think I got Miss Dior roses and roses, I can't quite remember, but got a sample of Black Opium in St. Laurent and C-Pasionia Scioscio Armani. So I've been hearing a lot about this, several of the YouTube channels that I watch. They've been talking about the C-Pasionia and oh no, this is the Black Opium Odopaphonion. So that's going to be interesting to try out. I tried the Black Opium. I got a sample from fragrancesamples.co.uk and I quite liked it. So the Dior one comes in a special Dior angelope. Very harsh. They actually sent me two samples. How proud. Yes, this is the sample that I actually selected. It's the Miss Dior roses and roses. Thought I'd try that out. I mean, for one pound for a sample, do you know how much these things cost on eBay? It's like four times as much. So I thought, yeah, I'll try. Finally got a sample of Sauvage. Yeah, yeah, I'm going to try and get my husband to try that. What else is in here? Okay. All right, we've got a postcard here. That's fabulous. It's like an extra sample that I wasn't expecting. How wonderful. I do think that perfume companies, it is in their best interest to send out perfume samples to people, especially during lockdown when you can't actually go into a shop to try them out for yourself. Okay, so we're going to start off with a Dior, Miss Dior roses and roses. So I am just dying to have a Dior in my perfume collection. I don't yet have a Dior perfume, but I want one so bad. I feel like I can't call myself a fragrance lover if I don't have at least a Dior in there, but I want to get the right one. So I am trying out stuff. So I like this one because it's pink. I love pink. Pink is one of my favorite colors in the world. So I haven't checked the notes profiles or anything like that. So I'm just going to try it out without knowing what the not profiles are and see how I get on with this. So this is an older toilet. So I'm expecting it to be very lightly infused.  Atomizer not so good on this sample. Oh, very, very light, very flirty, flirty, flirty, delicate, very delicate. I can get the roses, the roses coming out there. Lovely pink rose, fresh rose and a spring morning with some dew drops on it. Powdery. I'm getting the powderiness coming through, but not like heavy baby powder. It's very delicate and very feminine as well. Not too bad so far. I quite like this. I do. It is. I'm getting the sense of the dew on the rose petals. Yeah, it's not a heavy rose. It's a very light, sprightly, sprightly rose, very springy. I feel like if I'm wearing this, I have a spring in my step and I would probably wear this with my spring shirt dresses, the ones that have got florals on them. I like this. I do like this. It's an auto toilet, so performance wise, it might be a little bit problematic, but I'll have to check if this is available in an auto platform. Okay, so the next one that we're going to try. Ooh, should we go for black opium or seat? Let's go with black opium neon. So I really liked the black opium. The coffee note in it was just bellissimide. It was like, you know, the girls had descended from Mount Olympus to make me a nice orange flavored creamy chai latte. I loved it. So I have high expectations for this one. Oh, but sadly, the problem with the black opium was the longevity on me. It wasn't more than five hours before it was gone. Right. Black opium neon. I'm going to try you all the way up here. Oh, okay. It's got the same signature. That was very strong. It's definitely got the same coffee coffee orange blossom note as the black opium. There's something else in there. Something else that's given a kick to my nose. I can't tell what it is, but there's something else in there that's lifting it up a little bit. So that this one isn't quite as heavy. It's got a slight powderiness coming in, a slight powderiness, but I'm definitely getting the coffee, which is what I'm happy about. So I think this smell relatively similar to the original one. I don't think it would be necessary to have both of these. I'd have to pick either the neon or the original one. And I think that if the neon lasts longer on me than the original one, then I'd be going with the neon. But I love it. It's pleasant. It's as nicely pleasant and it just reminds me of coffee. And for me, coffee is a very uplifting sort of fragrance because I associate that with my mornings when I drink my first cup of coffee and I feel like I'm ready to face the day. Yeah, I quite like that. Okay, now let's try a Si Passione Odupafon by GioGio Armani. Okay, so this one, the bottle looks interesting. When I went to Devonance before lockdown, the bottle definitely did catch my eye. Let me just get out of the sun. We've got some lovely sun here in England. So it says on here, the new feminine fragrance.  But it caught my eye, but not enough that I wanted to try it. So let's try you. I'm going to try you over here. But I caught it though, I did. Right. Oh, hello, hello. Very fresh, very sparkly, a tart, clean opening. There's some citrus in there, citrus. I have no idea what the nose profile is. Because I'm trying to test perfumes without an expectation of certain nose, because I feel like that always kind of leads me to disappointment sometimes. And I think it's a good thing for me to just get kind of like a blind idea of whether I like something or not using the sample. Okay, there's some creaminess coming through, definitely some white florals. I can't quite detect which white florals. There's a bit of rose in there, a bit of tuba rose as well. I'm guessing the musk, it must have some musk in its base. And perhaps some amber as well. Okay, it's not a fruity floral. It's not a gourmand. I'm not getting, I'm not feeling like I want to eat it. And I definitely, I'm more of a gourmand fan more than anything else. I don't like it. Yeah, si passione. I don't think you're for me. I really don't think that you're for me, but I will try it on a day because sometimes even if it's not love at first sniff, it might turn out to be something that might be worth long term relationship. So these ones are my samples that I got. Out of the three, okay, it's difficult for me to pick which one I liked better. I quite enjoyed the black neon, sorry, black opium neon, but I really loved this. I thought that this was quite nice, although my problem with it might be the longevity versus how much it costs because I'm going to pay a lot of money for a perfume that doesn't last long on me. That just, that doesn't feel good for me to do. So I want to do that much as I like a perfume. And there's literally thousands of perfumes out there. I'm happy to keep on searching for a perfume that will last long and that I can spend the money on. But I quite like this. Let's just check in on them. Nice and powdery. The orange blossom has become stronger in this one, in the black opium. And it's turning a little bit sweeter. But yeah, that was my sampling day today, guys. Thank you so much for joining me.  Do let me know if you've tried any of these. I'm quite keen to find out if there is a similar perfume to this that might be stronger than an auto toilet. I would love to find that. And also, let me know what would be a good Dior perfume to get. I must, I simply must have a Dior perfume in my perfume wardrobe. I have decided that it is a must. Therefore, it is a must. Thank you so much for watching, guys. Hit that subscribe button, like, comment, turn on your notification bells and all of those wonderful awesome things. And until I see you next time, guys, take care. Bye.