Okay, let's get started. Welcome everyone, thank you very much for joining us today. Welcome to today's CNCF webinar, What's New in Kubernetes 1.19. I'm Jerry Fallon and I'll be moderating today's webinar. We'd like to welcome our presenters today. Nebrune Powell, Infrastructure Engineer at ClearSites, Taylor Dozal, Senior Developer Advocate at HashiCorp, Max Kobachar, Manager of Cloud Native Engineering at Storm Reply. Just a few quick housekeeping items before we get started. During the webinar, you are not able to talk as an attendee. There's a Q&A box at the bottom of your screen. Please put your questions in there and we'll get to as many as we can at the end. Please note that this is also an official webinar of the CNCF and as such is subject to the CNCF Code of Conduct. Please do not add anything to the chat or questions that would be in violation of the Code of Conduct. Please be respectful of your fellow participants and presenters. Please also note that the recording and slides will be posted later today to the CNCF webinar page at CNCF.io slash webinars. And with that, I'll hand it over to our presenters for today's webinar. Thank you very much, Gary. So welcome to this webinar about the Kubernetes 1.19 release, I'm Max. I'm the Kubernetes 1.19 communications lead and we'll be the moderator for today's session. With me, we have Taylor and we have Navarune. Both were like the key figures to move the release. Taylor as the release lead and Navarune as the enhancement lead. So for today's agenda, we're first looking on the 1.20 release, what's coming up there. We're moving on to the 1.19 stats. Going over to the 1.19 highlights, like how we came to this awesome great name of the Kubernetes 1.19 release, but also what are maybe some really interesting changes on what is new to the Kubernetes. Then finally, we move on to all the different updates through the different six. And in the end, we will discuss a few of your questions and hope you will also find some answers for it. Please remind that you can anytime ask us questions, I will try to answer some of them during the session. And if we have some which we really like to discuss or need some broader discussions, we will move them to the end to give there also some further insights. With that said, please go ahead. Sure. So I am going to go ahead and cover some of the 1.20 release states that we have coming up. Jeremy is leading the 1.20 release, Jeremy Ricard, and just spoke with him yesterday. We talked a little bit about 1.20 will likely be the last release of 2020, unless I don't anticipate anymore jumping in there and surprising anyone. They're working on defining a test freeze, I believe last week Shadda, there's a PR going in for that. The release is targeted for Tuesday, December 8th. The enhancements freeze is Tuesday, October 6th, and all of the shadows for that release have been onboarded. So that did kick off on September 14th, and then the original target date was for the 8th of December. So looking at like that is going to be the release date, but happy to have you all here today. And really excited to cover what came out in 1.19 and answer all your questions on that. With that, I'm going to turn it over to Navarue who is going to kick us off with enhancements. Hi, everyone. So I'll give you a brief overview of what enhancements did we ship out in the last release. So we shipped out a total of 34 enhancements in 1.19. So by enhancements, we mean features in Kubernetes. So they can be like APA changes, they can be like usability fixes, they can be internet test changes, they can be conformist changes. So we usually categorize changes or enhancements of features into three broad categories, alpha, beta, and stable. So we had like 10 stable enhancements. What this means is there is like nearly 100% confidence that these features are here to stay up, adding some changes. They may be like improved, but not substantially, which would affect the users. We have 15 enhancements graduating to beta in 1.19. So beta stage usually features tag in when they feel that they are confident enough that this may go to stable or generally available in the next few releases. So the API remains more or less constant between beta and stable changes. And then we have like nine alpha features. They are like majorly new features into the Kubernetes project. There may be new feature additions which we will go through later on when we do the SIG updates. With that, I would hand over to Taylor again for some highlights on the 1.19 release. Thank you so much, Navarune. So with 1.19, the release name that was chosen for this is Accentuate the Positive. I have to give a huge shout out to Hanabath Lagalov for designing this logo and truly capturing what it felt like to be on the release team during this time. We faced a lot of uncertainty, which I'm sure you've heard that word numerous times over the course of this year, but it was really true. We started the 1.19 release in one world and ended it in a completely different one. It was also quite a marathon release. And I believe it was the longest release that we've had to date. And really just wanted to focus on the community. That's why it got stretched out so long. We wanted to give time so that people were able to really work through their enhancement proposals and features and really focus on the community, right? Because if we don't have the community working and behind us and we're working well with each other and communicating, we don't really have an open source project. That's the community makes the project not the other way around. And so really was happy to see everyone in good spirits while working on this project and while being sensitive to all that was going on around the world. But so within this logo, you can see there's some fun little Easter eggs. If you look close enough, you can see the Kubernetes logo and hat and all of these hints at things that might have come out during the 119 release that a lot of people enjoyed and found fun. And then I'm pretty sure, I haven't asked these characters here, but I'm pretty sure they're using a green screen because I don't think I've ever seen that part of the beach just yet, but I'll have to ask them later. So in terms of new things, we are going to cover each of the features individually but just at a glance, some new things are structured logging, which I'm quite excited about. So looking at JSON logging or just standard out and standard error, that's going to make it a lot easier for ingest and you don't have to do any wild regex rules or anything like that on that front anymore as of 119. So very excited about that. Storage pools for capacity management. Storage got a big uplift in 119 and there are a lot of new rules around how to deal with storage. It's not treated as just nebula storage that's infinite. There are ways to atomically control how that is used and utilized within Kubernetes 119. So again, we'll talk more to that, but that's also something I'm quite excited about. Allow users to set a pod's host name to its FQDN. This will help with getting some legacy systems or other things that need that FQDN to transition over. So if you have a service that was called FU, you can get a whole qualified domain name when you set that and you call that within the pod itself rather than just getting the service name. Allow CSI drivers to opt in to volume ownership change. That again is a storage interface improvement kind of within that same vein of being able to have a little bit more control over storage and how that's defined. And then same thing with generic inline volumes. But again, we'll cover more of that as we proceed forward. 119 marks a brand new support model for us as well. Previous releases were only supported for nine months, which worked really well with the, it was one release or two releases back, just kind of supporting that three release cycle. So at any given point in time we were working on a release, we have one out and then there's one behind. And so this is the first time that we are moving to that one year support. And this is in reaction to a lot of the, what the community has expressed at some organizations, it's much more difficult to, even though you have a year, it's difficult to uplift a lot of these workloads and get them ready for the next version or N plus versions of Kubernetes. And we heard that and wanted to react on that front. So very excited to announce with 119, we're gonna have that year of support to allow people a little bit more time to shift their workloads over and dealing with things like the deprecations in 116 and other things of that note. Again, hoping that this makes things easier for most teams. With that, let's jump into the SIG updates and for to kick us off, I'm gonna turn it back over to Navarune. Thank you, Taylor for all the highlights from 119. That was really awesome. So I'll go through all the SIG updates. Basically, we have categorized all the enhancements into SIGs. So when any Kubernetes feature is added to a release, it has to be driven by a group of people. So the Kubernetes communities structured into logical isolations of groups called special interest groups who actually own code in particular areas. And that's why we're doing it like SIG by SIG. And the first SIG to come is API machinery. So let's jump ahead and see what API machinery shipped in in 119. The first feature that the shipped in was, so when you see Kubernetes resources, you have a status field and inside the status field, there's a thing called conditions. Now the scheme of conditions has been like a bit, it varies a lot depending on the resource. Now with this release, there's a feature shipped which actually specifies some guidelines or a default thing that you can use any API can use. So there's a condition type for conditions in status objects that the API designers can use and then they can also like drive more features out of them, more attributes out of them. This is graduating is stable. So it is available in 1.19 by default. And the next feature in those API machinery SIG is warning mechanism for deprecated APIs. So Kubernetes follows like a graduation mechanism for APIs and then you go from alpha, then beta, to like stable releases, even in cases of rest APIs. So what you see here is the ingress API. So ingress API resides in two different API groups. So one is like, one version is like V1 beta one, the next is this table. So what you see here is if you try to access V1 beta one resource, ingress resource, you will get a deprecation warning that, hey, this resource will be phased out in 1.12. Can you please use the new one? As you see here, when you use networking.KADS.IO slash V1 beta one slash ingress, it actually prompts you that, hey, use the stable one, networking.KADS.IO slash V1 ingress. We have a beautiful feature block on this. So when we post the slides, you can just click on the slide where we wrote feature block and then see the blog on the Kubernetes website. Moving on, the next in focus is SIG architecture. So the first thing there is a clarify use of node role labels within Kubernetes and it also attempts to migrate the components which actually use the node role labels. So traditionally there has been a label called node role that Kubernetes.IO slash something. And it was seen that several components even inside the Kubernetes architecture use that to change behavior. But the purpose of the label was to give a API. I should not tell it as an API, but as a resource for other people or in attribute for consumers of Kubernetes to actually modify behaviors or migrate, like do stuff around it. So in this Kubernetes release, it's a beta rollout. So along with clarifying the usage of the label, there has been like identification of who consumes all those labels and an attempt has been started to actually migrate them out of that behavior. Now the next feature of SIG architecture that we rolled out was enabling running the conformance tests without beta or STPAs or features. So this does not usually conform to our alpha beta stable thing because it's like internal APIs and then so this is kind of a stage thing. So the conformance tests can, so what happens is if you see Kubernetes projects or projects outside the Kubernetes ecosystem who actually use Kubernetes as a resource or a product, so they need a stable and reliable foundation for actually using Kubernetes. Now in order to achieve that, when you run Kubernetes conformance tests which actually verifies whether a distribution is conformed to the spec or not, you now don't need to run the beta features, like the tests are not run using beta features. The next feature is very important in a sense. It is kind of related to the deprecation warning. So there have been instances in the past where certain Kubernetes resources, like let's say, Kronjox or Ingressus or port disruption budgets, policies basically, port disruption budget policies, they have stuck in beta for a long time. Now it's like a double S sword. So in one sense, when people ship it to beta, they get enabled by default in the Kubernetes distributions. But if you see it like that, there is little incentive to actually make it to GA but then this may lead to instabilities or user friction. So with this release, it has been mandated as a policy that along with any new beta features that are coming in 1.19, any old beta features that were there have to reach GA and deprecate the beta or have a new beta version. For example, they can go from B1 beta 1 to B1 beta 2 or they have to go to B1. There has been like some resources that have been already transitioned in 1.19, like Ingress, which was betaed, I think a few releases, a lot releases back. I'll come to that later on when I give the signature updates. With that, I'll hand over again to Taylor for more updates on the sync front. Thank you very much, Nubrin. We needed a baton to keep passing back and forth.  So looking at the first one in authentication is the Cubelet Client TLS Certificate Rotation. And so what that is is, so before with the Cubelet Client, there was an out of cluster system that was set up to kind of handle that rotation. And while that was done automatically, it was not as efficient as it could be and it didn't operate within the cluster. Thus kind of, even though it was secure, we get even more security by having this happen within the cluster. So now this feature has moved to stable. And as that expiration date comes up, this automatically gets rotated out. And then you'll notice with each of these slides, we have stable tracking issue and Hansberg proposal. So as these slides get distributed, you can click on those and kind of introspect these in a little bit more detail if you want. So the next one is limit node access to API. So this is a security conscious enhancement in that previously nodes were able to set labels and some of those could be done within the Kubernetes namespace, Kate's IO and Kubernetes IO. That now is protected and no longer the case. This has been moved to stable and just overall makes your workloads a little bit more secure. You can operate with a little bit more confidence of things not changing that on your actual nodes. Certificate signing request API. So this one is that the certificates API would handle the root certificate authority used to encrypt traffic between a lot of the core components within Kubernetes. And this now adds a registration authority such that the signing process is a little bit more secure. And you now have that endpoint able to be called if you want to include this in any of your machine, your operators or machinery within core Kubernetes. With that, I'm going to, cluster life cycles is mine as well. Cluster life cycle. So the first new feature that we have here is new cube ADM component config scheme. So the cube ADM component that configuration management is getting a huge refresh. Some of those changes include the stop defaulting component configs and delegating that config validation. This is a new feature. Again, you know, cube ADM is getting a lot of work done to it in the releases to come. And I'm quite excited about that in terms of a little bit more granular configuration and hitting on some of the things that we've seen problems with or rough edges in the community. The next one is customization with patches. So this one I also found quite interesting in that new flag experimental patches has been added very similar to the cube control type of declaration. And so if you want to set different values for dev test prod, other environments, you can do so. Once this moves out of alpha and into beta, that flag then becomes dash dash patches. And with that, I would like to hand it back over to Nubrin to talk about instrumentation. Thank you, Taylor. So with instrumentation specialist group, we have a beautiful thing called events. So if you see Kubernetes, there are a lot of resources or components with generate events. But one thing that people need to ensure or workloads need to ensure that the rate at which they churn out events that should not have impact on the other part of the cluster, other parts of the cluster. And users should also be able to track what changes are happening. It can be related to verbosity of the events or let's say some event, like let's say I want to find out an event by which component of the cluster actually generated that event or which controller generated that event. Now with this release, a redesign happened of the event API. You can go ahead and read the enhancement proposal. It has a lot of details on how the structure is changed. And there is one more really good enhancement coming up next, which also deals on similar lines, which is structured logging. So as Taylor spoke about it earlier when giving the highlights. So if you see Kubernetes logs in controllers or any other component, you will see that they were traditionally strings. So now there is a backward compatible change in 1.19. It's also in alpha by the way. So if you want to use structured logging, you have to enable the feature flag, which enables structured logging. So what this does is, you have an additional function called InfoS in Kellogg, where you can basically specify object key value pairs and which will basically parse out the references later on when you see the logs. So as you see, we have added an example. So if you do a Kellogg.infoS, pod status updated, say that hey, the key is pod and the object is this, Kellogg.keyObjectPod and then again status is equal to status. And then it comes out beautifully into the logs. Also one more thing is, you can actually see all the changes in the JSON format. What you need to do is basically pass a flag called logging format is equal to JSON, which will also turn out this logs in the JSON format wherever applicable, whenever you did using InfoS or errorS. What this enables the end user to do is, you can basically ship out the logs to any log turning or log warehouse and then basically filter those or index those logs based on the keys, which makes debugging a lot easier. How do you want to see what happened at a certain point of time? Moving ahead, we next have network, sync network related enhancements. The first thing is SCTP support for services, pods, endpoints and network policies. So it was added as an alpha, I think last release or few releases back and it graduated to beta. So this feature is now available without, the feature gate is enabled by default so that you don't need to make any changes when bootstrapping the cluster so as to take, use SCTP protocol ports. So if you see, I put a screenshot of a service resource where you say that, hey, talk to Maya, but then the protocol is SCTP. So this is very useful in the telecommunications world where they use SCTP a lot for switching. And one interesting thing is this feature is also slated to go to GA in this release, the current 1.20 release, which is like a great win moving ahead. We have the endpoint slice API. So this is a very substantial change. So what traditionally happens is every service resource has a way to track pods to which it has to direct the traffic coming into the service. It used to do using something called endpoints objects. So you can think of endpoints, endpoint objects as basically areas of references to pods to give a very 1,000 feet view into it. What happens is, let's say if you have like 1,000 pods which are pointed to by the same service, what happens is when you want to update that reference to the object, it becomes a bulky data transfer across the network. You have to send like around a megabyte of endpoint blob that you need to modify and then patch back to the resource. Now instead of endpoints, what you can use is something called endpoint slice. So it basically chunks out endpoints into slices as simple as that. It is enabled in Uproxy by default with this release. And there's a beautiful blog on the website again which shows you a scenario, a real life scenario which actually explains why this was needed. I urge everyone to actually go ahead and read it. Obviously, you can also go to the enhancement proposal to see the intricate details of the same. Going ahead, we have graduated Ingress to V1. As I was saying earlier, that Ingress was in beta since Kubernetes. I think it was alpha in 101 and then around 2015-ish, fall 2015-ish since then it was in beta. But then with this release, it has reached GA. A very important change here is that earlier in backends, you needed to put service name and service port as keys, like attributes of the structure. Now they have been like shelled out into a service structure and then inside that you have name and port attributes. It more or less remains the same, just that it's like better. Going ahead, so adding app protocol to services and endpoints. So this is a feature which I think did alpha a few releases back and then I think in one dot, in one dot one seven, it was added to service port and endpoint ports as beta. And now this has also been added to services and endpoints. So now you don't need to basically have those arbitrary resource annotations. Let's say you have some controller which actually sees those labels and then acts upon them. Now you have something called app protocol which actually makes things much easier for you. So there have been instances where users have reported that it actually creates incoherences. There's an issue linked, I linked an issue like the link called user, where I hyperlinked user frustration too. You can go ahead and see, it's an issue on code access communities, the main code base repo. Going forward, we have signaled updates with that I'll hand over back to Taylor for something. Thank you, Navarine. So quite a few signaled enhancements. The first one of which is Seccomp which has a lot of people. I've seen a lot of demos on this actually and worked with David Racco about one of these on a different stream as well. And what this does is it provides you the ability to set a Seccomp profile for pod using pod security policies. It also allows for that control of privilege giving two pods so you can, again, put a Seccomp profile onto that pod and include that in. And you could either define one via the local runtime or you can set your own and configure that. I wish you all lots of luck in configuring Seccomp profiles. That's something I usually do, but typically in my nightmares, but very, very critical. And that's something that you should do, but it is no, it is quite an effort. Moving on to node topology manager. So for this feature that has moved into beta, the use case is teams that have to spin up a lot of compute and have a low latency kind of response time. They need that low level of latency and they prefer just one core on the CPU. They don't wanna break it up across those multiple cores and kind of risk that overhead in that time. So this is really just giving more control about how to burst out and work within those clusters, thus providing get prefer to allocation and get pod level topology hints. The next one is building Kubelet without Docker and that's exactly what it does. Really just about removing that dependency on the Docker, Docker Golang package and then allowing Kubelet to compile and work without that Docker dependency. However, that doesn't mean that this feature is not focused on that removal of code in tree at the current point in time. Next one is allow users to set a pods hosting to its FQDN. We talked about this a little bit in the highlights and really so this is very much to help out with interoperability with legacy systems and very easy to set for your pods, just hosting FQDN, true. Those are my favorite types of features are the ones that are a little bit easier to enable than not moving on to the Kubelet feature, disable accelerator usage metrics. What this is really is so the, with the third party device monitoring plugins, separate issue and pod resources API about to energy a, it's not expected for the Kubelet to gather metrics anymore. So really this enhancement is just about that deprecation around Kubelet collecting those accelerator metrics. And with that, I'm gonna kick it over to Nabaroon to close this out on these SIG enhancements. And with that, you're up Nabaroon. Thanks Taylor.  So with scheduling, we have, I think five features that they have shipped. The first of them is graduating the cube scheduler component config to V1 beta one. To give you its small context on what component config is. So as you saw in the QVDM updates too. So using component config, so the idea of being component configs is like what if you can configure the Kubernetes components themselves with Kubernetes resource manifest kind of things. So it has been, this effort has been going on since the past year, I guess, under the cluster life cycle, say WG component standard. So here in this specific enhancement, they were focusing on cube scheduler. I have put in a small snippet, a very basic snippet of how a component config looks for cube scheduler. So this went on beta in 1.19 and the cap owner wants to soak it for at least two releases and hopefully it will go GA in 1.21 or eventually. So next up is run multiple scheduling profiles. So this is a very interesting enhancement, I would say, like from a personal point of view, like we face a lot of problems when scheduling workloads in a Kubernetes cluster. The problem comes up when you have heterogeneous workloads. Let's say you have long-running jobs, let's say you have batch workloads which you can't really interrupt. If they are not interruptible, what if you have jobs which are very ephemeral, like web servers, which don't store state, you can basically kill them all. Now, you could also solve this problem using multiple schedulers, but there's a big issue with that is race conditions and scalability concerns. So what multiple scheduling profiles does is it actually introduces profiles in a single scheduler. So you can have different algorithms for different kinds of workloads. It went alpha, last release, sorry, in 1.18 and in 1.19 it graduated to beta and is eventually stated for GA in 1.21.  So if you see, there's a feature called, so you can basically set up affinities or anti-affinities or you can basically kind of to a certain extent model your workloads, what do you say? Spreading criteria across a cluster. Let's say you have like a web server running that and you don't want them to run on the same node. You can say that, hey, please don't run on the same node. You can say that no two parts should run on the same node. They will get spread over in your cluster as much as possible going to other restrictions like if you have like more replicas than there, there are nodes, obviously this can't be satisfied. Coming back, so there's a feature which added like more controls at the end of the end user to give scheduling heuristics like this and also achieve high availability and resource utilization. With that said, there's a very important thing we should see here is that you actually have an option to say that, hey, this heuristic is a hard requirement or a soft requirement. Basically you can differentiate between a predicate or a priority based on that, whatever you set, whatever you configure your scheduler to or your workload to, your workloads will get scheduled in that manner and it went stable this release cycle. So it is here to say, going ahead. So adding a configurable default constraint to part topology spread. So this is kind of related to the previous feature which went GA, this release, but this was added as a new feature in this release. So what can happen sometimes is in your pod specification, if you have like many different, like let's say thousands of workloads, thousands of different kinds of workloads, it may be tedious to go ahead and specify topology spread constraints for each resource. What this enhancement does is it allows you to set a default spreading constraint. After that, you don't actually need to like set on everyone unless and until you want to overwrite the default. This went alpha in this release and hopefully it will go to beta in the next, I think this release on next release. I'm really excited about the scheduling features, they're like really boon. So coming to the next feature, adding non-preempting option to priority classes. So priority classes have been a GA feature since I think 1.14 which impacts the scheduling and eviction of pods. So what happens is if any pod has, so pods are actually scheduled in descending priority. So lower priority pods are preempted or killed if there is a higher priority pod coming in and there are resource of exhaustion in your cluster. Now this enhancement actually adds a non-preempting option. You can say that, hey, this priority class can like it may or may not trigger preemption as in like you can disable the preemption feature. So what this will do is it adds a default, it's as an attribute called, I think it's called, sorry, I, so this is written in the enhancement proposal. You can go ahead and see the cap where it is written, but the default value right now is false. So it will still follow the previous behavior of preemption, but then if you want, you can go ahead and enable like non-preemption. So you can say that, hey, don't preempt pods. Going ahead to the next thing, storage. So storage also has a lot of updates coming in into this cycle. The first of which is immutable secrets and config maps. This went alpha last release and in this release, it's just graduated to beta, which implies that you can use this feature without any switching of feature flag.  So the default behavior is you can, if any secret or config map gets changed, it directly gets watched by Kubelet and then updated on the pod. Let's say you have like thousands of those objects. Now watching those objects becomes tedious job. This actually tries to solve that problem. So going ahead, so we have a few CSI driver migrations in this release to be exact too. First is Azure disk entry to CSI driver migration. So if you are using Azure disk for storage in your cluster and you have the CSI driver installed, you can just turn on the feature gate called CSI migration Azure disk to basically use the out-of-tree code. Same case for vSphere. So you have the feature flag called CSI migration vSphere which actually enables out-of-tree code usage. Going ahead. So we have two again kind of related enhancements. So one is storage capacity tracking. So what happens is often the Kubernetes scheduler has literally no information about whether a CSI driver can create a volume in a specific node. This feature, what it does is it gives a attribute called storage capacity which is seen by the controller and then determines whether you can schedule the pod or not. There's a feature block again on it which describes this very feature. This is alpha right now. So you have to enable the feature flag so as to use this feature. Next up is generic fmrl inline volumes. It is also kind of related to the previous one and it gives you a beautiful way where you can extend Kubernetes with CSI drivers but which provide lightweight and local volumes. So there's a new resource called fmrl volume source which contains the fields that are needed to create the volume plane. And another thing if you see here is the pod which creates that resource gets tagged as an owner of the resource. So if you delete the pod, the resource gets deleted automatically. There's a default garbage collector scheme using Kubernetes. Again, reiterating all the alpha features need to be enabled explicitly with the feature flag. So the last enhancement in storage is allowing CSI drivers to opt into volume ownership change. So to give you a short background, what happens is if you specify FS group in your pod security context in a pod, any volume that you mount gets masked with that FS group. Now this is really not necessary that the back end, the CSI type that you're using supports ownership modifications using FS group. For example, NFS, it does not support. So you now get a feature called supports FS group where the CSI driver can say that, hey, I supports up FS group or not. Based on that, your FS groups would be honored or not. The one that you said in the pod. This is again an alpha feature has to be enabled so as to use it. Going ahead, so it's the last thing in the roster for us, Windows. So we have a sole enhancement in Windows which is supporting CSI containerity on Windows. What it tries to do is basically improve the metrics of Kubernetes features that you can use on Windows by going through this containerity spec. So users cannot choose to run only see containerity CRI instead of Docker Enterprise. Now this change going to stable gives a path to the implementers to actually implement Kubernetes specific features that are not available in the Docker API which are available just on the containerity API. And with that, that's all on the announcements. And I will hand it back to Taylor to talk a bit about the release team shadow program. Hey, so release team shadows. With each new Kubernetes release there is a new Kubernetes release team that is comprised of Kubernetes members who handle the day-to-day logistics of the release itself. The team is broken down into seven different roles. So for those interested, I definitely recommend checking out the Kubernetes SIG release repository. Inside of there are roll books and it talks about each of those different roles. You know, we could see them here depending on what you might have an interest in. So personally, I started in similar shoes to Max and worked through the communications roles and then in the Kubernetes 116 release was the communications lead took 117 off came back in 118 as a release lead shadow and then led the 119 release. So the program is really fantastic in that you just show up and you learn and you gain a lot of information from being part of the shadow program. You aren't expected, you know for those of you nervous about having the world see your contributions whether it be code, documentation or what have you. No worries, the Kubernetes community is really fun, friendly and engaging. And just, you know, if you have questions that's the best place to ask them. Again, the team is fantastic and very easy to work with. And as you read through roll books, if you're interested you can kind of see what might be a good fit for you or something you might want to learn might be something you don't do in your nine to five job or just something you have a innate curiosity about. And then we walk you through that shadow program and then kind of try to get everyone set up to potentially be a lead in some capacity. So again, the goal is to train new leads to when leads aren't able to make it, you know they have a conflict, you know life event happens something stuck at the stuck at the motor vehicle, you know place then, you know, we typically would call on shadows to help out with that. I leaned very heavily on Jeremy and Bob those are my release lead shadows. I went through a job transition so that just yet another example of a life event coming up and Bob and Jeremy were always just really keen to help out and really appreciate that from both of them. For each role, there's one lead and typically three to four shadows that are selected via the shadow application process. The application typically gets advertised near the end of a release or just before a release starts. And typically you'll see that shared out on LinkedIn, Twitter and several other venues and avenues. The release cycles generally last around three months but with 119 being a prime example we went quite a bit beyond that. Weekly workloads, ebb and flow as some teams are a little bit more busy than others. So like Enhancements, Nobarun and Max I'm sure after this I'll turn it back to you but I'm sure you can attest to this where Enhancements was very busy during the beginning of the release cycle and communications was very busy near the end of the cycle as an example. So that is also covered in the role books just with the weekly breakdowns gives you a really good understanding of what you're in for and what time commitment you can, if you're willing to make that put in to the shadow process. For more information, please click on the release team shadows GitHub repo link here once those slides are all shared off. So with that, I'd like to open up for questions and turn it back to Max and Nobarun if you wanted to say anything about the shadow program or your experiences on that front too while we're waiting for questions to come in. I would like to say a few words about the program, like it's a great program. I would say anyone looking at like many people ask me like how to get started contributing to humanities but then there's this beautiful program, right? Release team shadow program, you can just come in and say like, hey, I am interested in working in this vertical, this really interests me. Can I work? And then you get to meet so like so many awesome people who actually help you get started and then grow into the community. So I started nearly one year back with the Kubernetes 1.17 as an enhancement shadow. Then I shadowed again in 1.18 because I really liked the role. Then I led the 1.19 enhancements. Then again, I am shadowing the release lead this cycle. So this is really fun. And you get to feel the responsibility that is bestowed upon you and that, hey, you have some important role in the community. You are looking after please. And the team is like very diverse folks from the community, like there is like huge times on diversity, like Taylor and Max can also say like right now in this call, we are like 12 and a half hours span in time zone. Me from IST, Max is from Sierra Leone time and then Taylor is from Pacific time. US Pacific Coast. Now, so if you see like, there are literally no barriers other than you just going ahead and applying to the program. Even if you are not applying to the program, just go ahead and just come to the Slack channel and say, hi, I want to work on this. Nobody would say, literally nobody would say no. I assure you that. Absolutely. And it's really great to see how all the massive contribution from this really huge fantastic community all get brought together in this step by step. You see more and more getting this version, it's quality and then it's getting ready for release. And then everyone's sitting there and it's getting nervous and then you see like the countdown and then in the last moments I'm writing, now we are going to release it. And then you see like what's all going behind the scenes, it's really great to see this. Gary, how much time do we have left to potentially go into some of the questions? We have right now no open one, but we can at least highlight one or two of the questions which we answered already. We have about four minutes left. Okay, that sounds like we at least can have a look at the one or two things which we got so far. So one question which I really liked is about that. It talks about actually the endpoint slices with the question that there are some issues with the demon sets and a really huge cluster in the update cycle of the demon sets. So the answer to this is yes, with the endpoint slices, this problem is also going to be solved in future. There's a really great blog post about it from Rob Scott who drafted this and worked mainly on it. And why does so every of the communication within Kubernetes goes through the Kubernetes API server and not just something which comes from the outer world, but literally every communication. And that's why the huge area cluster is getting the, well, not slowlier, but sometimes a little bit inconsistent performance you will find through the API server. And this is exactly what the endpoint slices will solve in the future. So if it's growing, then you have smaller chunks and the update cycles shouldn't be that much infected from it. Then there was another question in the beginning actually about the alpha and beta features which end up in the CKA and CKAD. So officially we cannot give the best answer to it because we do not write down the curriculum and what should be included, what shouldn't be included, but they're actually answered perfectly. Increases a really specific baby because it's so old. I mean, it's actually it's like, it should go already in the retirement action section. But no, it's a stable thing even though it was so long time and better. Now it has become officially stable. So that's why there end up some alpha and beta features. Normally shouldn't happen. Except we find something else which is super duper old and stuck in a better alpha version. Also really interesting is about the Qubectl and the client rotation. So with a certificate client rotation if implemented or if configured, it will does this by its own. Yes, you can force it also if needed, but actually it just takes care about it. And then maybe the last comment, this release is cool, thank you. It's matching with our mandate of resilience. Thank you very much for this comment. As I said, it's mainly about the contributors out there who spent their most of the time free time for contributing to the Qubectl release, giving their heart and blood and sometimes sweat even in this difficult times to the community keep contributing and support this really great open source project. That's just about all the time we have for today. With the support, the presentation and the slides, we would like to thank everyone again for joining us today. Have a wonderful and safe weekend and we'll see you next time. Thank you so much everyone. Thank you. See you around the cluster. See you around the cluster. Wait a minute. Bro, where did they don't know? They're in his own business.


Okay, we're back here live in Las Vegas for Splunk Conference, dot-conference 2013. This is theCUBE, our flagship program. We go out to the events, extract the symptoms from the noise. I'm John Furrier, Joe with Dave Vellante. What a run, we have Oracle Open World Day, VMworld before that, now it's a Splunk Conference. Just a great run here. Our next guest is Robert Osborn, Director of Application and Development Systems for Homes.com. Robert, welcome to theCUBE. Thank you, glad to be here. We love having folks who are in the trenches. We were talking before we came on about your site, Homes.com. Sounds like you're really excited about some of the site activity, site thing technology. Great name. Great name. Got the best name in the business. I was just playing with the map resizing. Really good, nice job. So congratulations. Thank you. Application, web-based application, obviously a lot of JavaScript, a lot of new frameworks coming out there, cloud computing, a lot of development frameworks. So the application market's exploding, but a lot of the stuff on the back end is needs to be managed, right? So Splunk is one of those. So first, talk about your relationship with Splunk and let's get into the how you're using Splunk because you have a lot of data. You have millions and millions of pages a day. If users don't like your site, they're going to go somewhere else. So you got to keep a good value proposition. So talk about Homes.com and as an app guy working with Splunk, what are you guys trying to do? So last year we experienced 40% year-over-year growth. We had a bit of a tough time scaling to support that level of traffic. We were saturating everything in our data center from NetApp IOPS to switches on the A6. You name it, or A6 on the switches. If you name it, we were probably saturating it. So we really needed to bring in a technology that would allow us to aggregate all of our logs and better monitor what we have. And not only were we growing then, but the plans were to continue to grow. We recently spent $4 million in TV ad campaigns on an HDTV network and DIY network, product basement spots. So our key focus was let's get our Homes.com architecture and infrastructure to be able to scale. And Splunk was going to be a huge part of that. So talk a little bit more about your environment, paint a picture for us so we can sort of connect to what's there. Sure, we use for our backend storage NetApps. We have five load balance everything. Everything's virtualized using VMware running on Cisco UCS blades. We also are working on bursting to the cloud where if we were to run into the problem of saturating some points in our data center, we can burst new 10, 20, 30% of that access traffic out to the cloud using Amazon's AWS. We positioned our data center and the same data center that Amazon uses and one of their availability zones. So we can run fiber directly into the cloud for low latency lengths. Okay, and then talk about your application, part of your job is application development systems. I mean, that's pretty fundamental. Talk about that, the application development organization that you're involved in, that you manage and how that all operates. Sure, we're a very small team. So what's cool about homes.com is we're a smaller business that's owned by a bigger business. Homes.com is owned by Dominion Enterprises and Dominion Enterprises is an umbrella company. Under there we have about 45, 46 different business units, homes.com being one of them. So what's so cool about our environment is that we run very lean. We only have a team of five programmers working on the homes.com portal. We have three systems administrators and we have about four or five different products people developing ideas for the platform. So we run very lean and efficient. At the same time, it's also very exciting. So your business is changing quite dramatically.   What if we could talk about that a little bit and how that is putting pressure on your technology infrastructure? The whole landscape is changing within the real estate portal. The amount of inventory that's on homes.com now is far different than what it was five years ago. We just have a lot more listings on the internet and that means our data footprint is growing. That means we have more data analyzed and as we start growing more and more and we get more and more page views and visitors, we have to really analyze, well, what's engaging to them? What are they most interested in? How can they be more engaging? It's all about determining the engagement factor of the customers and how to improve that. Now, is that where Splunk comes in? I mean, what role does Splunk play in terms of helping you guys understand the engagement metrics? Well, if we step back just one small step, when we were looking at purchasing Splunk for purely our operational data, our CIO challenged us to think outside the box. You know, sure you can use Splunk for operational data but what can it do for product? How can Splunk drive revenue to homes.com? So we took that challenge on and... Literally, your CEO asked you, how can we use Splunk to drive revenue? He was that close to the situation and the technology. Yes, and Joe Fuller really encouraged us to innovate and he saw something in Splunk that maybe not a lot of other people saw and that this product can drive revenue and he really wanted us to step up and figure this part out and so he did and he kind of made it not a full condition of purchasing Splunk but a pretty big partial condition. Part of the business case. So how did that all come about? You guys said, okay, we'll take on that challenge. You had no idea how you were going to do it and then just how did that manifest itself? So big data, the whole concept is new to homes.com. So our first challenge was explaining to our product people what big data is. Here's the types of data that we have. Here's what we're not doing with it. What are some things that we can do with it? So if we talk, if we start thinking about what's the most valuable data that we collect in the operation side into Splunk? Well, that would probably be our access logs, the footprint of our users, the tall telling sign of how a user's engaged with our website and then how can we drive product value by using that data and I think probably the coolest idea that we have that we came up with and which we implemented mid Q4 is that we're going to develop a recommendation engine. So the idea being when you look at a detail page on homes.com, you're looking at a property, you're looking at the price, how many beds and baths. Well, every event that you do on that page leaves some type of engagement footprint. For example, if you look at, if there's 10 images and you look at all 10 images, well that means you're very engaged with that website. If you only look at four images, we might not be as much engaged with it as a person who looked at all of them. If you print a listing, well that's a very engaging factor because you're actually printing on physical medium and to use it for later. So every click that you do on homes.com leaves an engagement footprint and what we do is we calculate that and determine an engagement value on that property and then recommend listings based off of that. So one follow up, I just want to flip it to John after that. So in terms of how you get paid, you have some advertising in the site but what you're talking about is other back end monetization strategies, right? Sure, so one of the ways that we really monetize the website is we match real estate agents with serious home buyers. So if you go to homes.com and you're in the market for a house, you look at a property, you like the property, you want more information about it, we have forms that you can use to contact the real estate agent. So then what we do is we collect that data and we sell subscription plans to real estate agents and we'll send, we call them leads, 10 leads to you per month or 20 leads, whatever package you sign up for and that's our big value driver, just marrying real estate agents to serious home buyers. So I got to ask you about the mobile conversation. We had the guys from New Zealand on this that said 40% of the traffic's mobile. You're probably obviously seeing a mobile object depending on the demographics, they'll be shifting and growing depending upon which segment of the market you have on the site at any given time, but mobile will be a part of it. That brings the whole data log question, what kind of data exhaust are you seeing? Are there new types of data that's entering into your purview that's now part of this blunt equation? Absolutely, mobile's huge and it's just getting bigger and bigger and it's important that we really think outside of the box and figure out ways to innovate in that space and how can we make our product better and we just have a bunch of great ideas. The amount of data exhausts that we're getting I think is most interesting with the geospatial data because with a device, with the mobile device, we can pinpoint where they're located geographically and then we can marry that data to our listing data and maybe you can have a real estate agent send an alert to someone when they're near their property saying hey, you're near this property, you're in the market for a house because you have our app and you did some recent searches and according to your recent searches, this is a property that you're interested in. Why don't I buy you a cup of coffee and let's talk about this property? This is where the application framework intersects with web design so can you share with folks out there that are looking at the convergence of mobile and web apps? You know, obviously web apps has been evolving very quick. Obviously you're seeing Mozilla, Chrome, native browser integration. Obviously that's always been a hassle, the different browser types but now you've got mobile apps, right? So you've got native apps versus frameworks. How are they colliding? Because many in the industry are saying web and mobile are one, will be one in the future. So how do you get your arms around that? Well I think the first important problem that's tackle in this space is you're dealing with a bunch of different technologies. Developing native apps on a mobile device is a lot different than developing web applications. So our first strategic position is to unify our programming language. So we're going to a complete node.js architecture where JavaScript is going to be the core competency that we require of all of our developers. And from there we're going to develop dynamic feature rich backend and front ends using JavaScript and then we're also using titanium to develop mobile applications written in JavaScript as well. That's awesome. So what are the future things you're seeing with Splug outside of the challenge from the CEO which by the way is a great testament to the value proposition that Splug brings to the table because hey you know go solve some problems but now it's driving revenue. That's the holy grail, that's what people are really tasked with and that gets IT folks excited. But what's next, what else are you looking at? What else are you thinking about with Splunk? Specifically around, obviously with Noble the node is going to be some great stuff. How are you thinking about the next leg of the journey? So we really remain focused on developing products features around big data. What I would like to see from Splunk is more direct connect features into our databases primarily the ones that do MapReduce such as Mongo. I think, I'm really looking forward, I know Splunk's tackling this problem and I think when they do it's going to bring a tremendous amount of value to homes.com and I'm sure other business units as well. Give an example of what you mean by that because a lot of folks don't know the new ones with Mongo. Sure, so Mongo is a non-relational database much like Hadoop. Well the challenge is and the challenge that we have right now is when we're building a recommendation engine, we store all of this data in Splunk and Splunk's very good at aggregating the data and sorting and shifting through it very, very quickly. But what it's not so good is handling 10, 15, 20,000 concurrent connections because for every query it uses essentially one core and a CPU. So you have to move that data aggregated into some type of transactional database which would be Mongo. Right now we need to have jobs run once every minute to do that for us. I think going forward from Splunk we're going to see more of a seamless integration that they're developing now with things like Conquere. The data just goes directly, goes right into Splunk and then directly into our Mongo database. You know we've heard that from the Splunk executives. Integration is a big part of it. You got the ecosystem partners here. Final question for you for me is I want you to just take a step back and share with the folks at home. What's it like here? I mean obviously it's our second year at theCUBE here at dot-conference. We've been following the company for many years in Silicon Valley and watching it grow. Explain to folks a vibe here. To our right we've got the partner of Pavilion. You've got the keynotes going crazy. What's the vibe here? What's it like here? It's a lot of fun and it's centered really around learning. I've gone to a lot of the different sessions and I always learn a lot. It's just amazing. It's a great place to be. I really enjoy it. I look forward to it every year and I hope to keep coming back here after a year. Robert Osborn inside theCUBE. This is what it's all about, learning. That's why theCUBE exists. So we want to go out and get the extractive ceiling from the noise and share that with you. We're open source content at Silicon Angle and Mookie Bond. We love that last line, epic sound bite. That's a tweet. I shouldn't put that on a tweet because it was so good. All the best conferences these days is about open source, learning and sharing. So congratulations for taking questions for that comment. This is theCUBE. John Furrier with Dave Vellante. We'll be right back. We have this short guest to wrap up day one of the Splunk Conference. This is theCUBE. We'll be right back.


My husband has died and I have no son. They say that you have many sons. You might give me one of your sons to then become my husband." This was a snippet from a letter that was written by Tutankhamen's widow. If you remember from our episode last week on Mystery Monday, King Tutankhamen died in 1325 at the age of 18, leaving no heir. Yes, he and his wife had two children, but neither one of them survived. This, of course, left King Tutankhamen's widow in a very precarious position. And so in an act of emergency, she wrote a letter to the King of the Hittites, which is now modern-day Turkey, asking to marry one of his sons so that she might remain safe. But before we go any further, you know what to do. Hit that subscribe button and give us a like. Also again, thank you so much to Tiffany Monroe, our producer. Tiffany is a Reiki master and teacher here in Atlanta. We are working on a very special episode with Tiffany coming up around what Reiki is because I know I've had a lot of people asking me about that. But if you would like to get in touch with Tiffany yourself and arrange an appointment with her, even if you live elsewhere in the world, something can be arranged, just shoot her an email. Her email is listed down below. Also, thank you again to all of our patreons.  If you would like to help our channel out, you can follow the link below. Welcome to Esoteric Atlanta. My name is Bryce. And today on Mystery Monday, we are going to be talking about the unknown man E, aka the mystery mummy, aka the anti mummy. The museum in Cairo, Egypt, there lies an unidentified dead body. No, it's not like a CSI, a dead body of a murder scene. In fact, this body is thousands of years old. However, this body was mummified in a very peculiar way and was left with a bunch of royalty. The only problem is we have no name and no idea who this person actually was. The tomb of this mummy was found in 1871 in the Valley of the Kings, as we spoke about last week. Now, the person who originally discovered this tomb was not an archaeologist or an Egyptologist. He was an average everyday goat herder. And for 10 years, this goat herder, along with his brothers, used this tomb as their personal bank account. They would go and rob the tomb and take out all the gold and then sell it for money. I can't say I don't blame them. I mean, desperate times do call for desperate measures. But by 1881, they were found out and they led authorities to the tomb in a return for a lesser sentence. Now, the Egyptologist working on this case had the tomb immediately excavated. Now, we talked about this again in our last Mystery Monday episode regarding Howard Carter. You see, they needed to or should have tracked everything within the tomb. They would usually take an artist and have an artist draw everything so they knew where everything was located in the tomb once they got it out into the museum or into a lab. But with this particular tomb, the archaeologist in charge was so paranoid about other tomb raiders coming around and raiding the tomb that he had this tomb excavated within 48 hours, taking no notes or having no artist there to sketch where everything was. This, of course, did not make it any easier for us to identify, even today in 2020, who this mystery mummy could be. Now, this mystery mummy was not the only mummy in this tomb. In fact, there were other mummies, more famous pharaoh mummies along with this dude. These mummies included Ramses II and Ramses III, along with Todd Moses III. Now, all of these pharaohs were pretty famous in their own right. A lot of them great rulers and great warriors. And to be honest, a lot of these pharaohs had gone missing. It seems that these pharaohs had originally been placed in other tombs but had been moved into this tomb that was found in 1871 sometime along our historical timeline. So needless to say, it was pretty exciting for the archaeologists and Egyptologists to finally find these missing pharaohs. Again, the only problem was who the hell was the other guy? You see, for Egyptians, they plastered their names on everything. It was part of their ritual of death, of knowing who they were, having an identity in the afterlife. So for this mummy to have no name really was strange. By 1886, the first archaeologists and doctors started to unravel this mysterious mummy. This mysterious mummy was important enough to have been buried with royals but yet his mummification was unlike any other mummification they had ever seen. For starters, most of the mummies have very peaceful and tranquil looks on their faces in death. But this mummy has one of the most horrific facial expressions you will ever see. There's nothing on his body to indicate that he was murdered. However, the look on his face tells a totally different story. When a mummy becomes mummified, or when the Egyptian priest would go to mummify a person, they did everything they could to keep the person's body intact. You see, the ancient Egyptians believed that the body they had in this life, they would need to carry over to the next life. And so when they went to go mummify a person, first they would remove the brain through the nose. This was to try to keep the skull intact. Then on the left side of the stomach, they would place an incision to remove all the organs. The only organ they typically left was the heart. After this, they would stuff the body with herbs to keep the body's shape. For 35 days, they would use salt, placing salt all over the body to dry the body of fluids. After this, they would famously then wrap the body up with very expensive linens. At this point, they would invoke a sense of magic. They would wrap ambulance, and they would place certain spells around the body itself. They would also release incantations or prayers to their gods. Within the tomb itself, there would be almost a cheat sheet of directions for the person to rise up out of the dead and make his or her way into the afterlife. Well, none of our mysterious mummy had any of these ambulance that he had none of the magic. It was almost like he was screwed once he was to arise from his tomb, with no way to get to the afterlife. The Egyptians took this process so seriously that they even had animals to mummify, so that animals could make their way to the afterlife as well. I'm a huge animal lover, and you best believe that I will be pissed if any of my beautiful dogs from the past aren't waiting for me on the other side when my day comes. But you see, it wasn't just the missing ambulance or names or sacred prayers that were weird for this mummy. It was almost like his whole mummification was in violation of the sacred side of Egypt. For example, this mummy was not stuffed with herbs to keep the shape. And in fact, what they put on his body was like a lime formula that made the body smell horrible. It appeared that the body was wrapped very quickly, not like regular mummies that sit with salt for 35 days, and then are wrapped with precision. Even though there was quite a bit of disdain for this person, again, we do know that he had to have been someone very important, important enough to be buried with pharaohs. And we know that even though, again, there was disdain for him, he obviously was a royal or some form of a nobleman because he had on gold earrings. At the time of this boy's death, he was no older than the age of 25. And again, we have nothing on his body to indicate that he was unhealthy or sick or even murdered. So what happened? And do we have suspects? Glad to ask. Many people might not be aware of this, but the Egyptians did practice at one point human sacrifice. There is an area in Egypt called Abidos. And 5,000 years ago, it appears that people were sacrificed with the king or the pharaoh.   We know this because of their burial plots. The graves the human sacrifices were found in appear to have all been dug up at the same time. The bodies all seem to have been dropped into the graves at the same time. And given the age of some of the bodies that were found, it does not appear that any of these people died of a sickness or a natural cause. A lot of them were quite young. It does appear by the food left behind in their graves that they were, yes, indeed, sacrifices. Now we know from archaeologists that eventually the Egyptians did stop doing human sacrifice because they started running out of their best people. I guess they realized there was no use having a civilization here on this side of the veil when all your people are getting sent to the other side of the veil before their time. So even though a lot of the archaeologists have kind of scratched off human sacrifice off the list of suspects, some archaeologists are still leaving that a possibility. Was our mystery mummy a sacrifice for one of our great pharaohs to join him in the afterlife? Is that why he has no name? Because he didn't need a name because when a pharaoh rose from his tomb, he'd be able to take our mystery man along with him to the next world. Our next suspect is the son of Ramses III, Pentaware. Now Pentaware seems to be the most likely suspect although I'm not so sure. Pentaware is a fascinating character in our history and I'm glad I stumbled upon his story. I do believe that Pentaware himself was a victim of his mother. Yes, Pentaware was the son of Ramses III, so this would have made Pentaware a royal. However, he was the son of Ramses' second wife, Tea. Ramses III had three wives and it had already been agreed that one of Ramses' sons with another wife would be the heir to his empire. Well, Tea, Pentaware's mother was having none of this. And so she, with some other people in Ramses' inner circle, created what is now known as the harem conspiracy. You see, they were going to ambush Ramses and have him assassinated, forcing Pentaware on the throne. At this time, Pentaware was only about 18 years old and it does seem that he was kind of innocent in all of this. Like, he didn't really know what was happening. Anyway, they got caught and of course they all got arrested. Now again, for the Egyptians, the afterlife was really, really important. And it doesn't matter how much you didn't like a royal or someone of the royal bloodline, they still were going to have to preserved for the afterlife. After all, the gods had ordained them royals. So of course they needed to maintain this royal body for their next life. Well, when they had the trial for this harem conspiracy, all of the people involved were found guilty. Now, some of the people involved who were not royals were set off to be burned alive. Now, to be burned alive meant that you had no more body to speak of. So therefore, this was a punishment worse than death because this punishment meant that you had no afterlife. Your body was gone. So for Pentaware, for his punishment, he received death as well. But because he was royal, they could not burn him alive. So they allowed him to kill himself. Now we know that poison is big in Egypt. Hell, it's big everywhere. It's a very common way to murder yourself or somebody else. They had Pentaware poison himself and this is apparent by the mummy stomach. The mummy stomach has absolutely nothing in it as if he had been poisoned and threw everything up before his death. The look on his face shows someone that had been poisoned because perhaps maybe the poison stopped him from breathing. This would also explain the hastiness of the mummification, the disrespect shown to the mummification. Even though Pentaware would have his body in the next life, it would not be as pristine as the other mummies coming back to life. He also had no name to go into the next life with. And worst of all, he was placed in the tomb with his father, Ramses III. So now his father, the one that he conspired against, was going to be the one responsible for pulling him into the other side. Now there have been some DNA tests done and some people say that it looks like this mummy might have been genetically related to Ramses III. However, some archaeologists say that this testing isn't 100% accurate and that might be a biased conclusion. I would accept if it was Pentaware. However, I believe that it was somebody else entirely different. A royal, yes, but not a royal of Egypt. Why do I believe this? Because the mummy had blonde hair. This mummy was also about 5'9", 5 feet 9 inches tall. And even though that's not that tall for a man today, back then that was really tall. So here we have this blonde-haired tall young boy in Egypt. Who could this have been? In the opening, I read a snippet from a letter that King Tutankhamun's widow wrote to the king of the Hittites. Again, the Hittites were located around where Turkey is located today. Now when we think of the people of Turkey today, we don't necessarily think of Nordic-looking people. However, at this point, they were pretty Nordic-looking. They would have definitely stood out in Egypt. Well, the king of the Hittites did respond to Tutankhamun's widow and he sent one of his sons. A son named Zaniza. It seems that since the beginning of time, marriage has been used as a political alliance. And perhaps for the king of the Hittites, sending his son down to Egypt to marry the Pharaoh's widow was a good move politically. Did this mean or did the Egyptians possibly feel like having Zaniza in their country and married to the Pharaoh's widow meant that the Hittites now owned them? It's hard to tell. All we know is Zaniza never meted over the border. He seemed to have disappeared. Disappeared from our history books and from our records. However, we do know that this mummy had blonde hair and was very, very tall. This mummy was also bound. His arms and his legs were bound together and it could be possible that if this is Zaniza, he was poisoned by some of the Egyptians he ran across coming into the country. Egyptians that didn't want their homeland sold out from under them through a marriage. If this is Zaniza, many archaeologists believe that it was the intention of the Egyptians to ship his body back to his father. They did what they could to try to honor what appeared to be the Hittite ritual of burial. However, something happened and the body was never returned and ended up sitting in a tomb with pharaohs for all these thousands of years. Frankly, I believe this probably is the Hittite prince. It just makes sense with his physical descriptions. His blonde hair, his tall height. That to me makes sense. However, I am open to it to also being Ramsay's son as well. You let me know who do you think this mummy is. And I thank you again for sitting through another fun Monday mystery. Again, many thanks to Josh McKay for doing our music. Once again, to purchase his opening song, you can follow the link below. And also a very special thank you again as always to Todd Roderick for helping me put together this video and get it onto the computer and out to you guys. If you would like to follow Todd's band The Flying Mystics, there's also a link to their band as well in the description box below. All right, I hope you guys have a wonderful day, and I will talk to you soon. Bye.


What's better one take down here. Welcome back to another flipping for profit video today. I'm gonna be sharing with you the most Expensive lots of inventory. I have ever purchased to flip for profits This was a lot. Let me show you what we have so you guys remember a couple videos ago I went and cleaned out this entire room and now we have boxes and boxes Fills here, so we have a ton of inventory now and what is inside is a bunch of these NHL McFarland's I picked out some of these ones here to put off to the sites I am a collector myself, but I don't know what I'm gonna keep so I do have some gritskies here I do have a Sydney Crosby here as well Which I think I'm gonna be keeping that because that's him in his winter classic But we do have tons and tons of boxes so far. I've been through this box here box number two three and four I did go and write on them because I do have a strategy of Going through box by box to see what there is especially when it comes down to time to list So yeah today, I'm hoping to go through box five six seven eight Maybe even nine. I do have my girlfriend's grandfather who is kind of an expert whenever it comes to NHL McFarland's But there is a lot to go through so luckily the seller did send me pictures prior to me making this massive purchase And I did find there is a lot of really top players some really expensive ones that I'm really excited for so in my opinion I did pay up because I did post questions in a Canadian reseller group on Facebook Marketplace asking What kind of profit to expect? Everybody was telling me to pay just five dollars each this one here this whole lot of 260 to about 280 I don't have an exact number right now There's about 260 to 280 of these McFarland NHL figures all sealed in the package. This cost me $3,500 which is about $12 to $13 each now that does sound like a lot especially the $3,500 part But you have to remember that a lot of these are going to be selling for more than what the average one sells for So whenever they're telling me to buy them at $5 a piece That would make sense if it was a lot of lower-end ones what I found in here Is there is a lot more higher-end ones as well? There is a ton of Gretzky a ton of Bredor a ton of goalies in general and goalies usually fetch a lot more I did buy about 20 of them at three years ago And you guys loved that video but now I have a lot more of them in my inventory That's it's gonna take me a lot longer to sell these probably longer than it took my last comic lots And this is the most money I've spent on stuff On average when I'm looking these up, they're selling anywhere from on the low end about $25 Like I said, I do have a lots that are around the $40 mark I have found some that are 60 all the way up to $100 plus for one single one So I know this profit to be made. I'm expecting hopefully within a year. I'll be cut down Hopefully by half But there is a lot of work to be done to go through each box listing it's taking photos And then posting it online as well And kind of my strategy to organize everything by me writing on it. For example box one here I have went and listed each figure that is inside that box So I have all the players names here the jersey color that they have on it because certain ones are worth more The team that they played for because if it's a player that's wasn't known for playing on that team Sometimes it's worth a little bit more. I found out. I do have some notes that's gonna be separate So this one here for Martin Bredor It is some of the plastic is separating on that one and one only and then I do have the prices on the side here So for the first one here There is a lot of $25 ones there's a lot of $30 ones, which is mostly the goalies in that but this one here Doug Gilmore in the Calgary flames was $50 which is one that I was not expecting to be that high So today like I said, I'm probably gonna go through maybe six boxes or so and list some more I went through four yesterday I'm hoping to do the other six today And then once I have everything written out and then I check the prices on everything Then I'm going to start converting it over to Excel I already started that with what's listed here the first four boxes already transferred on to Excel way easier to organize And I just take a screenshot of each Excel document that I have One per box or one sheet per box that takes screenshot of that whenever I'm listing them And then people can basically go through the list and also check on the photos as well I find that's way easier and that's what other sellers are doing I did join a bunch of McFarland collector groups and they were telling me that's on average I should expect $25 each and I a lot of people message me for certain ones So I do have some that are pending right now and some very cool ones as well Just off the top of my head and also double-checking with my list here one that I didn't Wasn't aware that I did have was Wayne Gretzky the 1984 team Canada one which I guess is a chase. It's him with the red jersey that one there is a $70 one I didn't even know it was worth that. I thought it was gonna be around the 30 maybe $40 mark But it's around $70 because it is a rare chase So I did find that one another one that I was really excited that I did find I knew about it But I didn't know exactly how much it was going to be and that's in box four I would show you but that's at the bottom box right now And that is Roberto Lulongo all four variants of his McFarland So it has him with the white jersey blue jersey dark blue jersey and the alternate jersey for the Vancouver Canucks Those are about a hundred dollars each so finding that I'm very excited I do know there's some Patrick Waw that are expensive that are in there because he has variants helmets on I Know there is two Kerry price one is a plain white helmet which I guess is rare and then there is the habs one which is also rare So there's a lot of stuff to go through a lot of rare ones a lot of ones that have an error I know there's one figure. I have yet to find it physically. I did see it that David I was picking these up But to go through and for me listing everything I haven't found it yet in the first four boxes But it has the wrong arm on him and it was manufactured like that so that one skyrockets for some reason and then there's others that have Little key details that are different for example if a goalie has the team logo on his water bottle That figure alone is worth a lot more just because the little water bottle Just that little detail on the water bottle makes it worth a lot more than just regular ones And then there's others for example if they were a captain There's a version without them with the sea and there's a version with them with the sea this guy had both of them So I do have both One is obviously worth more than the other and then if they made it into the playoffs There is a little patch that goes on the jersey one of them does have that as well So a few with the Stanley Cup and a few other great ones. I'm expecting some profit, but Exactly to figure out a number. I'm assuming around double. I think I'll easily double my money on this I'll make probably around thirty five hundred dollars profits But it will take some time and it is going to be a lot of work looking in this room If you guys remember that video I did recently clean this out So it does sadden me a little bit to see it full pretty much to the ceiling again of Boxes I did love that this was all cleared out, but this space was cleared out to get more inventory It's just this is stuff that's gonna take longer to sell I don't know if I should have waited and found a comic lots or a ton of video games I had a great deal again, but I still have room for other things as well But yeah, just boxes and boxes of these figures to go through so like I said I'm gonna be going through these next Hopefully I find a bunch of the other ones or also ones that I wasn't expecting to be worth money Look them up and if they are even more money for me So hope you guys enjoyed this video This is gonna take me some time not only to go through but also to list price everything out make the excel documents for each box and Start hopefully selling like crazy if I can at least sell more of the higher-end ones I do have some people that are interested in buying it as a lot, but they're offering about $5 each So if I could sell off a bunch of the more expensive ones and then for other people sell off and lower my price Maybe to around $15 each that's still me making profit off of them if I paid 12 to $13 and then whatever's left over Selling to the ones that are offering $5 each if that's a hundred ones at the end And I'm just having a hard time selling those then I will take $5 each for those and just get them gone But for now, I think I'm just gonna be listing them as the price is Seeing who's interested in what and then just going from there hope you guys enjoyed today's video It's gonna be a lot of work, but I know there is profit to be made Hope you guys enjoy this series, and I'll see you guys in the next one. Please take care peace


All right, so this video is going to be on sync thing sync thing is a very nice program you may have heard of this You may not have but it's definitely worth trying out It is it's a kind of well. It actually answers a lot of questions. I get Some people want to know how to sync files between computers. They don't want to run our sync or something like that They want something that they never have to touch they never have to think about they don't want to set up a cron job Or anything complicated They just want files to sync sync thing can do that Another thing sync thing can do is it can actually run on these odious devices It can run on phones So if you want to keep the files you have on your phone and sync with your computer Sync thing is a great thing You don't have to do any tethering or something like that In fact, this is what I use to keep if I you know download a file on my phone It will automatically through sync thing go to my computer and I can modify it or do whatever I want with it Now sync thing works both ways if you make updates on one device it updates all the other devices connected to it So it's very useful if you just want to never have to think about keeping basic files and sync So sync thing pretty much is in any Linux repository For any distro if you just pretty much Install it. It's usually it's in the main repository in arch. I already have an installed So obviously I don't need to reinstall it But pretty I'm pretty sure it's in Ubuntu and Debian and stuff like that But if not, it's in you know a PPA or something But anyway, I already have sync thing installed. In fact, I actually have it set up now to run sync thing Just throw it in whatever command prompt you have And the interesting thing about it is that sync thing actually runs in your browser by default Which you might like you might not like it's not actually a command line interface by default But you know, it's actually pretty useful to have this So this is what it looks like now. I already have mine preconfigured But I'll tell you the basics of it now down here. I'm gonna get rid of my face for a second down here We have remote devices. This actually is an old device. It doesn't matter I could probably actually delete it But this is my phone right here my LG phone or something And of course you can see it's not connected now to add different devices Sometimes sync thing can automatically detect devices on the local Network, but the typical way to do it is go to the actions tab click show ID And you have this this is the ID for this particular computer So if I give this to my phone and I add this device on my phone If I go down to this and say add remote device and I copy and paste that device ID in there I can add any device and once you add a device on another device It's sort of a reciprocal or reciprocal adding because all devices Automatically sort of add each other So anyway, that's really all you have to do to set it up set up remote devices And you'll see over here that I have folders now all of these folders are the local folders that exist on my computer That are syncing with other devices now the relevant one here is actually phone So you'll see if I pull up My directory structure here. I actually have this folder phone And this is really the entire SD card or I might I might be more than that of my my phone my Android device right here So the nice thing is, you know, I basically have the entire thing if I need to do something If I need to get a file or if I need to do some kind of file operation that I'd like to have a computer for I can actually just do it right here and syncing will automatically sync it up with my phone So anyway, how you of course do this is if you check you can of course add folders. Actually, let's add a folder as an example So let's say I want to add a documents folder The folder path is going to be you know my actual documents folder and you can select What of the which device is you want to share it with and then you just click save and that's going to be fine Now, of course It's actually not transferring files yet. Just because my phone is currently disconnected But it scans through them make sure is every sure everything's okay See there's some error in one particular file. It's not really important for us at least, you know for our example here But it takes a little bit of time to scan all the files depending on how big they are But we don't have to worry about documents now once everything is in place Once all the files have been scanned. I'm actually going to log on to the Wi-Fi on my phone and Autumn what automatically happens if you you know look at this folder phone here And if you look at the remote device in a second, it is going to pop up Give it a second. It might actually be a sec. Yeah Sorry, my phone's a little the local internet's a little slow But what you're going to see is that this is going to be marked as connected And oh, yeah, you see now it's going so it is now transferring files from the my LG device my phone To this actual folder here and there are two items actually the reason the things I'm transferring is a video I just recorded on my phone So that's all that that's doing And that will be done. I might want to pause the video until this is done. So I'm gonna I'm gonna do that All right, it looks like everything's done actually I removed the documents folder because it was taking too long But all the phone folder is now synced. It was actually a little more than two files I forgot I had some other new stuff, but yeah, sometimes all of the files will be staggered And I will say if you want one of the other things you can do is go down to the edit Option here and you have some more advanced things you can do like for example By default it's just going to choose what files to sync in a random order But one of the nice things is that you can if you want only small files first There's a reason you might you know need that You can set that setting or largest ones first or sort them by what's newest or oldest or stuff like that So you have a bunch of different options. I I don't have anything special set here But that's something you might want to look into which is pretty nice No, oops do not remove that, please. Oh, yeah, there it is. It's behind my head. That's the option. I want Yeah, so I should say there are other settings that you can set Of course, I have a different gooey. I use the darker gooey and stuff like that Just be sure to explore it But ultimately this is all you really need to know to use the web interface now if I go to my phone folder I think it's in the DC. I am yeah down here and you will see that I have some videos down here that I actually just recorded So that yeah, so that's what I needed So that's about it. That's all for the main interface I will say you can look at the manual for sync thing and there are like again It's primary interface is through the browser, but you do have some options for manipulating it by command line if you need to You know one thing that I occasionally Need is to get my device ID.  I don't think I said this before Notice the address that it's projecting on so it's gonna be you know To a hundred twenty seven point zero point zero point one, you know your local host or whatever And then the port that it uses is eighty three eighty four and that's all I think you can change that But that's what sync thing is going to use by default So if you tell sync thing not to pop up automatically not to pop up a browser automatically which you can set in the settings You'll have to put that you'll just have to remember this port or look it up by command line or something like that But that's the one it uses So anyway, that's about it. I hope this is helpful. This is something. This is a tool that it's really nice using Just because it can save you a lot of effort, especially I mean the main reason I use it nowadays is just for my phone. Sometimes I keep computers in sync I'm not using another computer right now, but it is a very helpful tool just because you know, it very When you use something like our sink sometimes there's a problem or which is a great command I actually I don't think I've done a video on that Maybe I should do one But one of the things that our sink I don't feel does as well as sync thing is Integrate like if you are making changes on two different devices Sync thing will be able to you know sort of sort through the changes and stuff like that and make it You know nice and easy for you But anyway that that's about it. So I hope you guys learned something and I'll see you next time


A black hole is just a region of space where gravity is so strong that nothing can come out of there, right? Not even light. The boundary of the black hole is called the event horizon. And the history of black holes is a great study in humility because we've kept discovering over and over again that we were all wrong about them.  And then for decades and decades people thought that actually the event horizon itself was some kind of singularity, was something that was really weird with space. Then it turned out that was just a math error people had made. There's nothing special that happens if you fall through the event horizon, except that if you're keeping track, you have a sinking feeling that you're never coming back. It's like the event horizon of a black hole is like if you're swimming in the Niagara River upstream from the waterfall, there's one particular line through the river where the water accelerates to go faster than you can swim. You're not going to die there.  And then people thought well you're going to only die when you come into the middle of a black hole where there is this thing called the singularity, either a point or a ring, depending on whether it's spinning. Then it turned out actually there is another thing called the inner horizon where you might actually die earlier by hitting things that come at you at the speed of light. And then very recently there's a firewall hypothesis saying actually maybe you do die after all at event horizon. And the short answer as to what the truth is is we really don't know. We're studying and it's a key in understanding the theory of everything. Yeah because it turns out that they're really rigorously answering these questions. It's not enough to just work with Einstein's theory of gravity. You also throwing quantum mechanics into that. And those are the two theories we mentioned earlier don't get along so you don't ultimately know. So the way I see it is actually as an opportunity. If we can figure out what's going on with black holes and maybe even get some clues by looking at them, then that can actually maybe be the master key that can help us unlock some of the deepest mysteries of quantum gravity and get a unified theory of physics.