The music turned off. Is that any time to talk? All right. So welcome to storage vendors are killing Cinder. Don't tell anybody what's kind of a misnomer. So who am I and why should you listen to me? I can answer the first question. I'm Corey Stone. I work at Rackspace and have worked on this cloud block storage thing since it's been a project. And I'm a self-admitted rabble rouser in the Cinder community. I like to hang out in Pound's open stack Cinder. I'm guitarzan. And I like to answer questions. But even more, I really like to play devil's advocate when people start introducing interesting conversations. And I'm always on the side of simplicity, even at the cost of maybe something being less than ideal. And I found out the titles are super important. I put my name on three summit proposals, hoping that one of them would get in. Hoping that more than one, but it turns out. The first one was going to give details on the back story and the current story of Lunar, which is Rackspace's own homegrown LVM back in for Cinder. People have been asking that.  And they've been asking about it for a long time, not accepted. Also, a co-worker of mine submitted a talk about how we deploy our environment. Salt stack's all hot and stuff like that. And our transition from working straight out of the Ubuntu archive to our own deployments. But I found out that if you propose an antagonistic sounding topic and you put a BuzzFeed title on it, you are in for sure. Here's a few examples if you need help with your own sessions next summit. And they do say, like, vendor X and vendor Y. If you've been around Cinder long enough, you may know who the inspirations were for a couple of the things that will show up. So it's interesting, but I've heard half of my talk being given already by other people at the summit. So apparently this is a big deal. People are all about interoperability. And these questions I find are very important from Cinder, Cinder's perspective. So I'm going to ask those questions. They may not have good answers. And then just some crazy tangential stuff at the end. This is the example of a terrible PowerPoint slide, because it's just a wall of text. It turns out that this wall of text is actually Cinder's mission statement from the Wiki. If we want to digest that a little bit, we say that we access block storage resources. I put that in quotes, because in our mission statement, we don't define what that is. And we use the term that everybody likes, software defined storage. Nobody agrees with what that is either. So this is a marketing speak. Somebody came up with a pretty good, put pretty good words together for our mission statement. Bad slide number two. This is the open stack mission statement from the Wiki. I can leave it up there if you want to read it, but this one's pretty easy. And this is an amazing mission statement, actually. OpenStack really wants to be the ubiquitous cloud. It wants to be everything for everyone. But it also wants to be simple to operate and implement. And it wants to be scalable, regardless of if you're a public cloud down to just a little company that wants to build a lab. I'm immediately reminded of the project management saying, you can have something fast, good, or cheap, pick any two. So I find that mission very inspiring, but it seems very difficult. And last, this is some text off of Def Core's Wiki. It's actual mission statement was very recursive, so I didn't think that was very useful, but it's very simple. Def Core's entire goal is interoperability in these three areas. So we have OpenStack and Cinder wanting to be everything for everyone, but we also have Def Core that wants to battle that a little bit and have everyone conform to some set of standards. And as a Cinder community, because we have 50 drivers or whatever the huge number is now, I find this directly important to us and we need to have a really clear perspective for our own reasons. So the first question is pretty obvious. How much interoperability makes sense for us? It's a loaded question. Everyone has their own opinion and it usually involves whatever I want, that means interoperability. We've had several discussions in OpenStack, not just in Cinder, but where someone will come up with some case where one cloud or one install works slightly different than the other, and the statement is, well, they need to fix their cloud. Like there's some objective source of truth that says, this is what it should be. And thinking like that, I don't find helpful or useful in any conversation. Well, let's see, but so we have, then we have this little battle between Def Core versus vendors versus OpenStack. Vendors obviously want Cinder to do whatever they, their stuff can do. OpenStack wants to be everything and still be uniform. So I think for Cinder, it's pretty obvious that the answer isn't gonna be 100% or 0%. Everything, there will always be a difference and I think we need to just embrace that attitude. Your cloud is not gonna be exactly the same as my cloud. My storage backend will absolutely have different characteristics in yours. You will have some features that I don't have. So we need to decide what does it mean to be interoperable. So the next question is pretty simple, but the answer is not. What should Cinder do? Well, at its core, it's just another OpenStack API. So it does everything that everything else, every other OpenStack API does. It presents you this set of objects and it has a DB schema to control that and all that crazy RPC stuff. But the question really is, which parts of the interface between Cinder and those back-ins, like what should that be and what parts of that interface should we care about? This is hilarious. John had almost this exact same idea earlier. One idea is we can have a very minimal set of things that are part of the interoperability discussion. I don't wanna put, I could make up a statistic on the spot, but I would just say most of our users, at least in the public cloud, they just want a volume. They just want storage. They would be almost fine with, hey, Cinder, create me a volume and tell me how I can attach that volume to my instance. And really, all of those guys would just go away. I'm done, that's all I need. We have a few more really common operations and some just default implementations in the volume manager that I don't think there's gonna be a whole lot of disagreement about. And then on the other side is there's the attitude of, well, I can fix this problem in software so I'm gonna do it. We are devs and we like to solve these edge case problems that we imagine that never actually happen. So we can take the other approach and take the, you have to do absolutely everything that we can support or we'll kick you out of the tree. I love that argument, it's so useful. So the problem with that idea, one of the problems with that idea is as we start to implement more and more advanced features, our reference implementation is completely left out in the cold. We have LVM and what that means in most cases, it's just local LVM on a small Linux box. There are people that I assume are doing LVM on big back ends where they have lots of space but LVM really falls apart on small storage nodes. From Rackspace's perspective, I would say that the LVM driver, you can't even really use it.  So that's kind of, that would be bad for us, we wouldn't really like that. In fact, the main difference between our driver and just the basic driver is we just don't let that happen. We're not gonna have snapshots blow up our storage nodes. That would be, I would get lots more phone calls. But we've added these new features like replication and consistency groups that are completely foreign to that implementation. The next slide is the best slide ever. People know what this is? All right. So the minute that I proposed this idea, I knew that I would have a slide with the center compatibility matrix on it. And it took me like three or four browsers to actually get one that would let me zoom it out far enough to fit it on one slide. So there it is. It does show that there is a wide swath of features that are very widely implemented and a newer swath of features that are very, very sparsely implemented. The problem with this discussion is all these vendors can do more stuff than sender exposes. The whole point of vendors is to sell themselves. This is my value add. This is the thing that I do better than someone else. That's why you need to buy my product. So for them, they obviously want, they want to have that thing in sender. The problem is, even though those features will be comparable, like so my vendor X version of this feature, I'll still say why it's better than vendor Y's version of this feature and here's the differences. Whenever someone proposes one of these new features, we just get lost in the weeds. We immediately go down to details and terminology and everybody disagrees about what those things mean and the discussion is just usually die out. So how do we reconcile that idea of the ubiquitous cloud? I want to do everything for everyone but still conform to some level of interoperability. I wonder if the fact that we do get into all of these ridiculous arguments every time that a new feature gets proposed. I wonder if that in itself is a good excuse to say that those features probably shouldn't be first class citizens in sender. I wrote my outline long before I wrote the slides out and planned out what I was gonna say. So I had this question, what shouldn't sender do? And that's actually a really hard question to have any sort of concrete answer. Again, the vendors would absolutely say, well, why wouldn't you implement shiny feature X? I don't have any good arguments for them. I mean, that's their whole point of existence, right? So the question is, is there a way for us to make everybody happy? Probably not but implement some of these things without making sender just horrible and huge and impossible to understand and catch on to. Switching gears a little bit. We like to talk about configuration all the time and I will admit that the docs around all of the configuration options aren't amazing. This is compounded by the fact that OpenStack loves to deprecate things. OpenStack loves to rename configuration options and move them into their own sections and do all the stuff at will which makes it really difficult to keep up with that stuff. If it happens to be a topic that you're passionate about, I know the docs team would absolutely love any help trying to keep this stuff straight. So I have a trick question, obviously. People complain about the number of config options. Anybody know what my answer's gonna be? Damn, Duncan, thank you. Not enough config options. I am strongly on the side of operator choice. Maybe that's not obvious but for a long time we made a focused effort to ask the center community to have independent snapshots, for example. We wanted to be able to say if your back end can let you have a snapshot without having a volume, let go for it. So that was a fight where we were asking for a config option that would let us do what we want. We lost that fight, whatever. And then there's also this discoverability dream. The idea that I would go out and purchase some $100,000 pieces of hardware and plug it into my cloud and just flip a switch on and expect it to work the way I want it to work out of the box seems a little misguided. I think it should probably be a big deal when I add an entirely new storage back into my cloud and it's in my best interest to know how that thing works and to know how to twist any knobs that I'm concerned about twisting. And I think the vendors should have that same mindset. You want your customers to know how your product works and help them to do the things that they want to do with that. And leading into my next topic, it's not really that difficult to set up a volume type in Cinder. My favorite topic by far, volume types. What's a volume type? In Cinder it's just a label, nothing more. All a volume type is is, hey customers, here's a list of things that you can try to create. We keep trying to apply more semantic meaning to these things and I'm not convinced that it's actually making our problems any better. As I said before, most of our customers just want a volume.  In the second case, you have customers that absolutely do care. They want feature X, they want QOS specific, they want these characteristics, they want encryption because they think that your DCOps texts are gonna rip the drives out of the boxes and run. All of these features can be solved with just volume types. We don't actually have to do anything for them. Things started getting really complicated when we decided that in some universe we were gonna have a bunch of different back-ins in our cloud and we were gonna try to expose these comparable but very different back-in features and we were gonna expose those through the same volume type. Maybe someone's doing that, but if so I think you're kind of crazy. Those customers that actually want those very specific features, they're probably not gonna be convinced by you saying what we have is good enough. They're gonna say what is the thing and trying to map those things to multiple back-ins just seems like you're asking yourself for a lot of trouble. And about volume types, I'm of the opinion that Cinder should care a heck of a lot less about those things. Quick story time, we were running Cloudlock Storage on Grizzly for a long time. Like I said, it's basically just a simple LVM back-in so there's not a whole lot of features that we needed. However, Grizzly had a whole bunch of terrible performance problems once you got over a lot of volumes. So thank you to whatever Devs helped us out by fixing some of the API N plus ones and the DB N plus ones because upgrading from G to H to I made a huge difference. However, when we upgraded from G to H, we found out that you could no longer even attempt to create a volume from a snapshot that came from a different type. It just, the API is like, no, go away. So before upgrade, everything's all happy, has all passed, after upgrade, the world blew up because the API is just like, no, and I'm like, why? So we did the API hijacking to work around this but then we upgraded from H to I. Before H to I, clone from one type to another type. After H to I, bam, the world blows up. Whatever, I don't know why we want to care about things that are not necessarily, I don't know, these are features, these are API validations that just came out of nowhere. So the thing about volume types is, as I said before, all of these things can be handled simply by keys and values on your volume type. Encryption is already an option in a bunch of drivers. I think most of those are actually just back end turned encryption on for everything but you could actually do that on a per volume basis if your back end would let you do that. QOS is one of the huge rat holes that we get into every six months or so. We had a great discussion a couple years ago when capabilities first came up, where we were arguing about what an IOP was. We were arguing about throughput metrics, what they were. We were arguing about what is a full read. It was absolutely bizarre. John's been putting QOS on volume types forever and there didn't need to be any code and centered it, do any of this stuff. Replication is another case where I think you could simply set up your back end to be replicated. Your customer could buy that replicated volume type and they'd know that if a meteor hit your building, their data would be safe and that's really what's most important. Any of these volume characteristics can just be configured. And lastly, there's this other push which has kind of slowed down but why would we want to expose these maintenance operations on your back end and sender? Is it that hard to use your product that you don't want your customer to ever touch your storage device? It seems like, again, you as a vendor want to help your customer out and help them learn. Help them know how your product works. I do have some sympathy for this replication failover thing that seems pretty common but the problem that I see with that is simply that if something really bad happens, your customer's guest VM already finds, like it already crashes because it's not magic, right? The guest, your customers already know you have to wake somebody up in the middle of the night anyway and they're the one that has to perform the action and sender. It's one of those features that sounds nice but when you get down to what it actually means to implement, I don't know what the win is. The guests already crashed because they're read-only. It's just, I'm not sure. It seems like we should, we as a center community should want to push back just a little and help the vendors understand that it's actually good to have knowledgeable customers and it's also good to write products that your customers can use. So this is where things get crazy or I thought they were gonna get crazy until I heard a comparable comparable suggestion about this whole experimental API thing. So my immediate, my version of this before the summit was what if instead of starting at the top and doing the whole design by committee thing and trying to get everybody to agree on what things mean, what if we did the opposite and gave a playground for vendors to be able to experiment, let them try things out, see what sticks, let vendors learn from each other's experiments. I wonder if we could get some better, maybe just a better opinion if people see what actually has been implemented, let code talk a little bit and just see what happens if we let people play and we just have less fear of people doing things that we may not understand or agree with. I ripped this quote out of OpenSec Cinder a couple months ago. I don't remember who it was, so I can't attribute it. Is this a person here? Anyway, I just wonder what would happen if this wasn't the case, right? What if people felt like they actually could make changes and do cool stuff on any reasonable timeframe? And then there's some last thoughts about vendor stuff.  Nobody likes code reviews. I think the pain is probably felt by the vendors more than anyone else. We always have this argument about when does your driver have to be in in order to be considered for that release? How do I get someone to actually review my driver? I mean, these questions are not new and they are clearly a pain point because they keep coming up. And I do recommend reading that spec, make plugins, external webs. I'm not convinced it's a good idea. I probably don't think it's a good idea at all, but I do recommend reading it. CI, CI people gripe about it, but really it's the only way that any of us know that any driver code actually executes. There are some cinder devs that are really good at reading code. I'm not one of those. But none of us can actually execute any of that code. So just mad props to all the in for people and all the focus on the CI stuff. So in closing, OpenStack as we keep hearing is trying to become this big enterprise thing. I still don't know what that means and I'm not convinced that I like it. But as it becomes more and more and it grows up more and more, I think that us as a center community need to have a very clear picture. I think we need to have it out in the open and we need to know what it means to be interoperable for us. I think we should be able to help make that, drive that discussion for our part in the deaf core stuff. We could just continue to be more designed by committee and just say no all the time, but I really hope that we don't and that we make that interoperability set as small as we can. As small as is reasonable and let people experiment and try to do awesome things with the rest of their stuff. Thank you. And I definitely, yeah, definitely want feedback and yeah, he's got one right here. So have you tried buying Monty Taylor three whiskies and they're telling me you want clouds to have different API behaviors like can move between two types, you're not with the clone. Because I guarantee that we're in explosion. Explosion of vehement disagreement as Infra already having a nightmare with all the tiny differences in APIs. They want the lockdown and fixed, not more of them. Like as Infra one of the biggest cross cloud users, cross cloud, cloud design, co-design now over the moment and they're already with the limited differences we've got having an absolute nightmare. They're saying if difference is spiral they just won't be able to write cross cloud apps. Now there's lots of, lots of customers who want to go cross cloud and we're gonna tell them basically no. Wait, wait, how did you make that leap? Just saying no. Well, because they won't be able to do it. The people who are trying to do it are saying if more difference is creeping you won't be able to write the code. It'll be too difficult to keep it up to date and et cetera. That's only if they want to use that feature that only works on the backend. But how do you tell what features work on what backend and what don't? I mean, the idea of locking down things like cross type clone in Cinder was that it didn't work on most backends. 90% of the time it failed, 90% of configurations it failed totally. Well, I'm not gonna argue with that. I mean, I'm just saying the things that I think we should care about is a smaller set than everything, right? And if volume type cloning between types if people really think that that's number one, a huge deal and really common if it's a really common thing, then why not make it work? If it's an uncommon thing, why would you care if it's not a standard or if it's not enforced? And like I said, there's no, I claim that there are no objective truths here but I will fight for, I will always be on the side of vendor choice or operator choice in this discussion. So the answer from Infra and Monty had been jumping up and down quite literally saying this in a couple of talks already in the last two days is the little things do matter because if somebody writes for them, all of a sudden that code doesn't work in all the other places. I will absolutely let people have their opinions on that. I mean, I'm not gonna say that they're right or wrong. I'm going to say cloning between types is reasonable and if it doesn't work, what's the pain of it not working? It means you have to work around that or it's a shortcut, right? You can either have the shortcut or not have the shortcut. And if you don't want to have that option, that's fine. Again, I'm not saying it's true. It's like, I'm not saying this is absolute truth. I'm saying I tend to be on the side of operator choice and configurability. People like Infra are not on that side. They're very much loudly. Correct. Monty is actually where I got that quote from go fix your cloud. I don't want to answer for you. I want to say that I think you did a great job and I agreed with a lot of the statements that you made. You know, the cloud compatibility thing. One thing that I think is often forgotten in that is the whole reason that we use types and that we used to recommend the use of types to do that sort of thing is because that's left to the operator and the admin to actually configure that properly. And it means that you don't have the compatibility problems that Duncan is saying and stuff like that. In my opinion, if you have multiple types that aren't compatible and that doesn't work, then you screwed up.  That is not an open stack problem or a cloud problem. And it certainly would never show up in Infra anyway because Infra doesn't even do anything with types. It only creates arbitrary types that don't do anything. So it doesn't really matter. But anyway, I thought you did a great job and I think you're right. Thanks, John. You heard it here, guys. He was on camera, on microphone. Hello, oh, sorry. Okay, thank you for your presentation. I have two questions. Sure. Do you know what happened with shared volumes on Cinder? I think there was a blueprint. The multi-attached stuff? Yes.  Oh, he's right there. So the short answer is it's really hard to make that drastic of a change in Nova and it's taken a lot longer than we expected. Is it planned to work in any time? Yeah, I mean. Yes, I'll be back in the morning tomorrow. Okay. It has to be discussed with the Nova. Okay, and one last question. Sure. Okay, do we have a do nothing driver because I see a lot of customers saying that, well, Cinder, it's not gonna work on our environment. We're just gonna do it outside of Cinder, just attach it with our regular, I don't know, maybe web GUIs. And if we do that, now OpenStackDB doesn't know about this drive and when it tries to delete, it says, oh, I failed to delete because there's something attached that I don't know. Oh, I see.  And but do nothing. Just. Gotcha. Yes. Yeah, such a thing doesn't exist. That's actually interesting. I've never thought about. I've never thought about doing everything, like doing everything outside of Cinder except the Attach and Detach. I mean, I see where it's coming from, but I don't think anyone's too interested in implementing that. Oh, I want that. Hey. But if it's a do nothing driver, it will be extremely easy to write. Yes. Yeah, that would actually be extremely easy to. But seriously, I do see a lot of customers saying like, for example, Hyper-V, it uses iSCSI for LVN, and a lot of customers say, no, iSCSI, I want SAM fabric. Gotcha. And then we have to say, well, sorry, then we have to do it outside of Cinder. So no one's implemented the fabric stuff in the Hyper-V? Yes, so now we have a problem saying that, okay, so let's do it outside of Cinder, and now when we say NovaDilly, oh, it's gonna. Can't detach because it crashes. Yes, I got you. So I really want that. Well, so there's two answers, right? So there's, you could write a very simple do nothing driver, or you could try to talk to the Hyper-V folks to make the other fabrics work. As long as you write CI for it. What? Yeah, CSI. True. Okay, so. Oh, there you go. What? He promised it. Oh, okay. Thank you. Oh, thank you very much. Sure. So the one thing I totally, not to agree with you on is we need a way for experimental APIs and playing and trying things out. Sure. A couple of people have proposed that you even make that really explicit and you have to put a header in your client request. I know this is experimental and it might go away. And if I'm relying on this and I come and cry at the summit, then you're allowed to laugh at me. Yeah, yeah, yeah, sure. There is somebody else saying, well, as soon as you put a feature up, somebody will build something on it. So I very much think those people are wrong. And I agree with the safety margin of putting experimental and I'm not allowed to complain in a header kind of thing. But I think we really do need a way of doing experimental stuff and that would have made things like replication. We could have iterated that in the experimental space for as long as it needs until people can agree. I think if the general case of executing random code in your driver had come up before replication or consistency groups or a lot of this stuff, it would have been really interesting to watch the ride. I don't know if there is a next one planned. Unfortunately, replication was the big one that is now going through its second thing. But yeah, I totally agree. I think if we would have solved that problem and allowed that initially, we could have saved ourselves a lot of pain. And like I said, I'm not really a storage guy. I don't know what the next one is, but hopefully we can use it. So I was excited about the title of the presentation. Yep. I had maybe something else in mind. I think a lot of the times when someone proposes a new feature, they're coming from a vendor, they speak from experience, you kind of have your own storage in mind and maybe not really focused on what the API should look like, on what the behavior should be. And you kind of make it work for your own thing because that's what you know. And then every other vendor will come and say, well, that doesn't, my storage doesn't work like that, so let's change the API. And then my storage doesn't work like that. Let's change the API. And it would be great to just do it reverse. Like let's decide what the API should be. And then if your storage doesn't work like that, we'll make your storage work like that. The problem is that's exactly how it works. That's exactly how traditional open stack stuff works. And we get things that, so the problem is that doesn't allow you to, that doesn't allow you to quickly change things, right? So I'd like to say that we're really good at that, but we're terrible at it. Like we just don't do it well. We've never been able to agree on anything, right? So to then go and say, you need to change the way your storage works is also pretty unfair. Maybe that thing is just something that isn't easily abstractable. While you can do anything in software, right? That doesn't mean it's gonna look good. And since we've never tried it, I just think it would be very interesting to see what happens if we try the other way around it. Because that has been the way that it's gone all the time. We implemented this QoS specs thing after two months, two years of talking about what it looks like. Instead of just, well personally that's an example of something that I don't think does anything, but that's a case where we argue and try to come up with a solution. And I don't know who's happy with the solution ever. So I'm just suggesting trying it the other way around. I think given the fact that we haven't had the ability to do experimental APIs, the fact that it's sometimes taken quite a while to get features implemented is not necessarily a bad thing either though. Especially since now the TC is saying that we can't ever change the APIs. We can't ever remove things from APIs. So if we had the experimental APIs back in the day, then I think we would have been able to do things a little bit more quickly and experiment and try to get things in. But to simply say that we've never been able to agree on something and never been able to get something done is not actually accurate. I mean, it's obviously an extremist statement, right? So yeah, that's true. I know. We're still committing code. Right, it's an evolving process. It's an evolving process. And with things that are as complicated as replication, a lot of us, including John and others in the room, we've spent a lot of time trying to make it work for all of us. And it's vendors obviously have a motivation to get those things in, right? But I don't think we've ever come at it from a perspective like, hey, I'm gonna really put it to solid fire because our array is so much better or whatnot. At least the developers in the community really wanna make Cinder work. Sure. Yeah, I'm not attributing anything to malice, right? But replication is a great example. There's a replication V1, right? How many drivers implemented it? One? So I just wonder if we're just not really honest when we say that we do cooperate well and come up with something that we all like because there's only a couple of good examples and unfortunately that's one of them. Sure. Totally agree. Since he doesn't have a mic, he, Duncan pointed out that an amazing example of a counter example where just recently backups from attached volume just like got in. And it was, yeah, like you said, it was actually an amazing example of where a feature could get added that was pretty much universal and with like, because we have Cinder doing all the work, the generic implementation for that just works and everybody wins. So I mean, that's a great counter example. Another pretty good example of that is the work that Pure Storage recently did with the image caching capability. I did a lot of testing of it. It didn't work for our driver, but I wasn't gonna block it. I filed a bug and I committed a fix to our driver and we're still working on that, but it definitely helps the entire community to add something like that. I think that's probably true in these cases where Cinder's kind of doing automation, workflow-y type stuff where it is absolutely not necessarily a driver thing. I think you did have some sort of image cache thing, right? But the general solution, the general purpose implementation for the image cache thing, yeah, is another good win. Yeah, that's pretty spectacular, I would say. Yeah, yeah, right, yeah. The copy and write image stuff, yeah. One more comments to example, for example, replication. You just mentioned in replication view one, only one driver implement this version, right? That is why we have a version two that simplifies the replication. I believe that more and more drivers will support replication v2. Yeah, so no, that's kind of my point though, right? So iteration works. I mean, I don't think there's any argument that iteration doesn't work. The question is, could it have been quicker or maybe I'll just say more interesting if multiple people had tried to implement replication and we could have seen which solution people preferred? Yeah, oh, I totally agree. So one thing I'd be curious what you think, especially from an operator's perspective. My belief is that one of the things that makes this difficult is the insistence that we have all of these APIs and all of these API calls. There's actually a replication v0.1 that I did back in Essex. Sure. That is in production, that is nothing but volume types. It doesn't use any API calls or anything. No, not that. And one of the things that I question is, do you focus more on putting those custom things in a type and encapsulating them as opposed to requiring that there are all these APIs added all the time until you're ready? Replication is a great example. That's why I spoke about it. I see where it comes from, but I question the need for this failover thing in Cinder. I mean, replication failover is already human intensive and customer impacting. So maybe we make it slightly easier by having a Cinder call, but how much easier really is it? I don't know the answer to that question. So one thing I can say with absolute certainty, having spent the last three weeks and meetings with them, is that our customers absolutely want this abstracting and that is a huge sale point for OpenStack. There are customers who are moving to OpenStack because of all this abstraction. They don't want to go and train up on... The replication failover? Replication is one of them. They really like to see replication work, but in general, no, they don't want to log into their storage front ends and web GUIs and do things there. They absolutely don't, because that locks them in with training, it locks them in with all sorts of things. And it's a sales point for them. I mean, it's okay saying, well, they're not saying tough, that's an option, but it's definitely a value proposition for certain customers and there are some fairly large, slow IT crowds, you know, civil service, et cetera, who are looking at OpenStack now. And the value proposition of OpenStack is the fact that they can move between solutions in a couple of years' time or on the next cloud or the parallel cloud and require far less training and far less... Not zero, but far less... Yeah, I do have sympathy for that case. I understand it. It sounds really good. And if people are happy with replication V2, hey, more power to us. Way to go, go team. I'd love to sit in an experimental API till we're happy with it, because it makes iteration faster and easier, but there is a definite value proposition to things like replication being somewhat baked in December rather than having to go and poke a web console that's specific to NetApp, specific to SolidFire, specific to EMC. So there are customers who love that, and we'll hand over Bigbox to OpenStack vendors to do that. Who doesn't like Bigbox? So in defense of the replication API, and not the API itself, but its existence, I think it's necessary for a user who wants DR, a full DR solution, to be able to go to the destination cloud and be able to clone their volume and to run a VM off it and to see, okay, my DR really works. And sometimes in the real world, that takes 10 or 15 or 20 tries until you configure everything right on your VM to get it working. And you can't rely on the admin at the destination site because your storage is replicating your data and there's no Cinder on the other side and there's nothing else on the other side. You can't rely on the admin to test your DR for you if it's a cloud. Sure, but that's still, it's not something that a customer can do, right? That's something the admin does. No, a customer can do it. A customer can do the failover? That would be... Okay, well maybe then that's a flow on V2 and we need V3. Yeah, I can't believe we're still talking about replication. But, you know, so I, oh geez, but I'm, let me say something here. I'm a little confused through the process of the presentation here. I think I see what you're trying to get at and you're concerned about vendors that have functionality that everybody can support. We're talking about the importance of replication, but that's an example of one that doesn't work in the reference platform. So it kinda, it seemed like you were saying two different things there. But what I wanna get at, let's move beyond replication, let's talk about the next thing, whatever that may be. We have customers who want to get into the cloud who have been using storage for years and who have had functionality that goes far beyond what Cinder is doing right now. And I don't think we can say, no, we're not going to do it for them if we're gonna continue to have open stack to be relevant and move forward. So what we have to do is we have to figure out a way to work out together as vendors, as developers, as cross-company people. I don't care whether I'm from IBM, whether I'm from NetApp or HP. We gotta figure out a way to solve this. I think maybe that's what you're trying to get at in this presentation, yes? So more clearly, what my real point was was simply that the interoperability discussions should tend to shy away from those complicated abstract, complicated abstractions and those features that are not global. That was the main point. So what that means, and then the idea that we can have this set of experimental APIs where that vendor that wants to implement that thing, they can just do it, right? But then how do we actually, so we've got to experimental, we still have to get beyond the point where we agree that that's gonna become part of the product, or are we saying it never does? I'm saying that vendors may have their own things. Whatever that thing is, right? I'm saying your vendor may not agree with this feature at all. I'm saying it is okay for there to be features that are outside of the interoperability discussion completely. Yeah, I think that touches a little bit on what John was getting at earlier today with the ability of doing plugins that are external. Yeah, yeah, the whole contrip thing, and the experimental APIs. And the contrip thing, I think that works really well with the perspective. That's why I was kind of both happy because I thought they would be more well-received because a couple other people have very well thought out opinions about this already, and mine was just yet another, you know. And without any, without actually implementing a plugin mechanism within Cinder, there's no real way for a vendor to actually start doing those things without some major, you know, calisthenics within the code base, which is kind of painful, you know. And then. I'll look at my Gifos repo. I was gonna say, so if you want my absolute crazy idea, and this may be a terrible idea, is to have one generic API RPC driver call that the vendors can do dynamic dispatch.  So if you wanna perform an operation on a volume, that way we could have even Cinder client have a generic command, right? Just pass down whatever the heck you want to your driver. Send it JSON. Yeah, just do stuff. Here's a package, do stuff. And then you could pass it down to the driver, the do stuff driver for that volume, and just. You've got to do nothing driver in the do stuff. Yes, I mean, so I mean, I don't know if that's a good idea, but that's one way where, you know, free rein drivers, or vendors could have free rein to play around to try this stuff. And that's fine, but that doesn't necessarily get Cinder off the hook here, because then you've got. Off what hook? Well, I'm curious because, you know, we just had a, you said there's all these wonderful features and everything that Cinder doesn't do or implement. Well, a couple hours ago, I said, what are the features that we're not doing? Because from my perspective, I agree with Corey's slide, create, delete, attach. It's really kind of the key, right? So I asked that question and nobody answered, including you. Yeah, I have a second example. Hold on. We have a static connection, but you know, maybe we have several parts. So some parts the customer want to use by OpenStack. They want to just set a restriction about the part range. So this is maybe a feature. I'm not sure this is a general thing. No, so I agree with that. That's a big difference from saying we're missing all of these great features that they've had for years. There's a big difference. I agree with that, but I want to focus on the fact that if we have some great advanced feature that we need to put in there, it should still be outside of the interoperability discussions. That's my whole point. It doesn't need to be agreed on. So the only one downside that I could see to this, which is kind of a little bit of a red herring, but if you upfront allow people to do what they want, they want in the experimental, which I think has a lot of value and I definitely support that. The downside to that is that you don't upfront require you to actually talk to other people to see if it makes sense to do it a certain way. Agreed. And that there is value in the community there by forcing yourself to talk with others in the community to do those things. Sure, I mean, so you will still get, I mean, you still have to go through Garrett, right? So people will still have to look at your code. But it is totally true. Maybe we would or wouldn't require blueprints for stuff like this, where people would actually say, you know, you're completely insane or, oh, that's a great idea. Why haven't we already done this? I mean, it's totally true that if we let it become more Wild West, it will become more Wild West. You were complaining about that feature chart and it's actually a very simple chart. You know, it's fairly linear progress. Drive is implement things later and later. So I don't think that's avoidable, given we've got 50 drivers and some things require driver changes. We can't change 50 drivers to get a feature in, I think. Otherwise, features would take forever to get in. I don't, I don't follow. You put up the slide with the feature matrix. To avoid the need for that feature matrix, you have to make everything standard. Otherwise, your feature matrix is going to explode. As soon as you allow vendors to support or not support something, that feature matrix is going to explode and probably become indimensional. And, you know, what releases the support on what driver is going to get more, that support matrix is way more complicated than it already is. I will say that's true to some extent. But I think it's slightly different when instead of having a standard feature and the people that implement it, you have a list of, this is my driver and this is the crazy thing that I do with that driver. It kind of changes the way, the meaning of the matrix. Does that make sense? You have this idea of here's all the stuff that Cinder really cares about. This is the interoperability stuff. This is the stuff that matters. And then you've got this stuff. Oh, here's the crazy stuff that vendor X and Y are doing. And with these drivers, you can make this crazy call. So. But what's crazy today starts to become more standard. I mean, that's what I'd hope is that. Yeah, yeah, this is actually standard, Cinder design session stuff here now. Yeah. At nine tomorrow. I thought we're doing something else then, Dan. So yeah, if we've just devolved into yet another Cinder normal dev design session, I'll just say thank you guys for coming. Hopefully we just open the conversation. That's really the goal. We get lost in the weeds in, this is meta weeds.


The narcissist kept your relationship secret. They kept your relationship hidden the entire time. You may wonder how this could be possible. You may remember meeting their friends. You may remember meeting their family. You may have been seen with the narcissist on many occasions. Their friends and family saw you with them. But it was never a relationship. You were just their supply. They understood that at some point. The supply would lose its potency. They understood that at some point. You would no longer be of any use to them. So they had to make it so that you were able to be replaced when the time comes. And they arranged this by managing other people's perceptions of your relationship. Behind closed doors. They may have told you that you are in a committed relationship. They may have confessed their love and devotion to you. They may have given you false promises and future faking. They may have promised something about your possible future with them. You went out with the narcissist. They took you to different places. And sometimes it was fun. Other times there were a lot of arguments and disagreements. But you're left to believe that you are with someone who really wants to be with you. You're left to believe that it is a real relationship. But when they're around other people. They're playing it down. They're making it seem like it's not as serious as it looks. As though they're still deciding whether or not they want to be with you. They will tell people that you have a lot of issues and problems. They will say that something is wrong with you. But this is just used to trick people. It's designed to mislead people from the narcissist's true intentions and objectives. It's used to justify why they're not fully engaged with you. So they will make it seem like it's not a serious relationship. Which is why when you meet their family and friends. They might not give you the recognition that you deserve. They might not see you as being anything significant to the narcissist. Because the narcissist has already downplayed your relationship. They've already told people that you are less important than they've led you to believe. They led you to believe that you were something significant. But the narcissist only said that to you. They fed a different narrative to everyone else. So you may have thought that they were deeply involved with you. And you were a significant part of their lives. But when they were away from you.  They were downplaying your position. They made it seem like you were lacking the required qualities and abilities. As though you were insufficient for a purpose. As though you were unable to deal with life. They made it seem like you were the one with all the problems. While they were just trying to help you. It's all a setup. So that when the time comes. They can dispose of you. When they find someone who is more suitable for them. Because then no one is going to judge them for getting rid of you. No one is going to question them. No one is going to think that your position was anything more significant. The narcissist has already been downplaying you and complaining about you. So people will already assume. That the narcissist just didn't want to deal with you anymore. Because you weren't good enough. You had all of these problems. So throughout your relationship with the narcissist. They made it seem as though you were not important or significant.  And without having to explain to people. Why they're treating you like that. It helps to conceal and protect them. From looking like the person who is bad and wrong. It's very effective. Because you never knew that they weren't serious. They made you believe that they were deeply invested in you. They made you believe that they were deeply involved with you. If there was ever a problem. They would always be there to help you. They would always try to correct the situation. But that's only because at that time. They didn't have a suitable replacement for you. But at some point you realize that they were never really committed to you. You realize that they were never really on your side. Which is when everything starts to make sense. Because there's one side that they show to you. While there's another side that you never see. There's another narrative that they're feeding to everyone else. Because in reality they have no regard for you. They were just wearing a mask whenever they were around you. But to everyone else. They're downplaying your relationship. They're putting you down. But then they're also making it seem like they're trying to help you. Because they know how to balance people's perceptions. To where people outside of your relationship. Have no idea what is being done to you. They've already made up their minds about you. Which is how it's so easy for them. To start smear campaigns against you. Because they've already gone around. And told people that you're insufficient for a purpose. They've already told people that you have issues with problems. So that when the narcissist no longer has a purpose for you. No one is really paying attention to you. No one really cares. And everyone is on the narcissist's side. They will justify the narcissist's behaviour. Following their preparatory measures. You may have believed that you were in a relationship with the narcissist. But the entire time they kept it a secret. You were never anything significant to them. They just had a use for you at that time. They had a suitable position. And they will protect that position. So that they can keep you there. Where you can continue to serve them. But it's not anything significant to them. They don't really want you. They're not really trying to save you. They just want the qualities and abilities that you possess. They don't want you. They don't care about you. It's just the way that you are. The way that you do things.  It's the things that you do. That's what they like. Which means that if someone can do things the way you do. They will replace you. They will take that person. Which is why it's so easy for them to get rid of you. Once they've ran you into the ground. Because at that point you have no value. You have no purpose to them. Which is why you have to be careful. About who you choose to share your qualities and abilities with. Because when you're given these things to a narcissist. They're not going to consider you to be as valuable or as good as you actually are. They're only going to underestimate and under appreciate you. Because these qualities and abilities. Are meant to be reserved for those who are truly deserving of them.  When something has value. It shouldn't be so readily available. It should be reserved for those who have the same amount of value to bring to it. You can't just make yourself available to anyone. Which is how narcissists manage to get away with it so easily. Because you can't just sell a new McLaren or a Lamborghini. To someone who has no credit. Someone who can't even put down the deposit for that type of car. But what happens in these relationships. Is that although they don't qualify or meet the necessary requirements. We still choose to engage with them. When you need to recognize that they have no equal exchange of value. Whenever you sell yourself short. It will only get you in a lot of trouble in the end. Because you're dealing with individuals. Who cannot reciprocate the amount of value that you are bringing to them. Which means that you will be the one who has left paying the price. Thank you for watching. I hope this video resonates with you. Please like, comment, share and subscribe. If you were like this Nate. My PayPal link is in the video description. Coaching Inquiries. You can email me at coaching.narcsurviver.co.uk Thank you for watching and I'll talk to you soon.


Hey guys, welcome back to my YouTube channel. This is Daniel Rose Hill. I want to do a short practical video today on how to look up a zip code in Israel. So I've seen a couple of YouTube videos that have actually already been done on this subject and they recommend using these English lookup tools. And I just wanted to make sure that there wasn't one and I could not find one from Doar Israel, which is Israel's official postal service. And in my opinion, you're much, much better off at deriving information for something like this from the actual postal network. So therefore, in the absence of that, you're going to have to jump into some Hebrew. So this is the lookup tool I've been using for many years at provided by Doar Israel Itur Mikud. It's extremely reliable. And basically, you just need to put in an address and it'll pop out a zip code. So let me do a demonstration for a random bank. So firstly, Yishuv, that's the city or really mean settlement. So basically any town, kibbutz, etc in Israel. So I'm going to go for Yorosh Shalim. And as I've recommended many times, learn to type in Hebrew. My Hebrew is not wonderful as anybody who's watched this YouTube channel realizes, but one of the first things I did after moving to Israel was learn how to touch type in Hebrew. And it was literally the best investment of time. I think every single Alpan in the country should teach typing in Hebrew as a fundamental skill. Anyway, rant aside, next we need our Rehov. So it's Hat Nufah. So this is just a street and talk. I'm actually choosing the address of the bank in Jerusalem. So this is an autocomplete feature. So if I type that little bit more slowly, Hat Nuuu. And then we've got our option Hat Nufah as a second option here, Hat Nufah Shmone. Now, sometimes addresses in Hebrew have a knisa. So they have all those letters listed. I'll do another video explaining how it addresses in Israel work because there's a little quirk. It's good to know about you. And that's all the information I need. I click on hapes. And here's our zip code 9342208. That's all there is to know. So if you are shipping something to a family member or a loved one here in Israel and you need to get their zip code and they don't know their zip code for whatever weird reason, use this website. I'll put the URL in the description. And you just need to know their city, their street, their number. And if they're binyan, if their building has a knisa, sometimes you'll see, you know, it's on street eight knisa, because it's just a reflection of the fact that most people in Israel live in apartments. And therefore, apartment numbers and different entrances to apartments are very, very common in addresses more so perhaps than in other countries. Thank you guys for watching this super short video. Hope it was useful for somebody. And if you want to get more videos from me, please subscribe to this channel.


Hello, this is Nick from Laptop Media and today we will show you how to open the Dell Latitude 15 3540. To open this laptop you have to undo 9 captive Philips head screws. Raise the bottom panel close to one of the top 2 corners to create a gap. After that you can pop the plate with a thin plastic tool starting from the sides. Then you can work your way around the front and the back. Please remember, it would be of great help to us if you just hit the like button and subscribe to our channel. That would motivate us to make even more and better videos for you. Our laptop has the optional 54 watt hour battery, the default version is a 42 watt hour variant. To remove it, pull out the connector from the motherboard and undo the 5 Philips head screws that fix the unit to the base. The optional capacity lasts for 9 hours and 5 minutes of web browsing or 8 hours and 20 minutes of video playback. To achieve that, you have to apply the balanced preset in the Windows power and battery menu and select the optimized power plan in the BIOS. You can rely on 2 so dims that fit up to 64GB of DDR4, 3200 MHz RAM in dual channel mode. Below the cooling fan is placed the single M.2 slot for 2280 or 2230 Gen 4 SSDs. Below the NVMe there are two small thermal pads. The cooling system has a single fan, one heat pipe, a heat sink and a heat spreader.


If you get the number wrong you can still be close. If I say I'm about a meter wide, that's not great if I'm trying to make a well fitting suit, but it's fine if I'm trying to figure out how wide to make a doorway. But if I was to claim to be a vault wide, that is so deeply wrong that I couldn't possibly use that to do any kind of design. And the reason for that is that a vault is not a unit of length. So the idea of length is more fundamental than the idea of say a meter. And this more fundamental idea is called the physical dimension. So a measurement is describing some physical quantity and that physical quantity has a dimension and then we also describe it in a particular unit. So for example, one inch is equal to a certain number of centimeters. So the quantity on the left is a length and the quantity on the right is a length and length is the dimension. The inch part is the unit and the centimeter part is the unit and the dimension is length. And this equation is all right because it has a length equal to a length. You can't have a length equal to a time. That just doesn't make any sense. All right. And so this idea that all relationships between physical quantities had to have the correct physical dimensions, although it does seem kind of obvious, on the scale of human endeavor it's actually quite a new idea. It was only invented in 1822 by Joseph Fourier. And occasionally we still make mistakes along those lines. For example, in 2008 the Australian Capital Territory Government introduced the electricity feed-in bill. And the idea of this bill was to give people an incentive to put solar cells on the roofs of their houses by making sure that they got full price for the electricity that they generated. But in order to not distort the market commercially they put a cap on how many solar panels you could put on your roof and said that households would only get the full price if they had up to 10 kilowatt hours of generating capacity on their roof. The problem, a kilowatt hour is not a unit of power. It's a unit of energy. So power is defined as a certain amount of energy per unit time.  And a typical solar installation on a roof might have something between two to eight kilowatts of capacity. In other words, under full sunshine you'd expect to date kilowatts of electricity to be generated. And so this legislation was probably meant to say that you get full price for electricity provided your total capacity was at or below 10 kilowatts. But it's not really the done thing to just kind of assume that when people write things in legislation they probably meant something else and so we'll go with that. And so this is a real problem. Kilowatt hours does come up in electricity bills quite a lot. If we just rearrange this equation we can see that if we multiply both sides by time then the energy you get is just the power times the time. And just as kilowatt is a reasonable unit for power coming off a roof and hour is a reasonable unit of time it turns out that the kilowatt hour is the unit of energy that electricity companies use to bill us. And so for example you might spend 20 cents per kilowatt hour for your electricity.


Thank you. So I'm happy to continue the topic of Rishabha, on which we had a few papers now already. Being the first Tirthankara, biographies of Rishabha or Adinata are particularly numerous. Naturally, one finds versions in the complete so-called universal histories, compositions termed Puranas or Charitras, which narrate the lives of the 63 Shalaka Purushas, including the 24 Tirthankaras, 12 Chakravartins and 9 Triads of Baladevas, Vasudevas and Prativasudevas. There is, for instance, the Mahapurana of Jina Sena in Gunabhadra, and the Apabramsha Mahapuranu of Pushpadanta from the 10th century, or the Chalpana Mahapuri Satcharya of Sri Lanka, also from the 10th century, but of course the most famous example is undoubtedly Himachandras, from the 12th century. But Rishabha's biography is also found in Puranic compositions where one would less expect them, such as the Jain Ramayanas and the Harivamsha Mahabharatas. Most of these Jain Puranas strive to emulate the orthodox Puranic model, offering a parallel to its Panchalakshana model of five requisite subjects, so Sarga and Pratisarga, the creation and recreation of the world, Manvantara, the intervals of the Manus, Vamsa, the dynasties of the gods, and Vamsa Anucharita, the legendary royal lineages, especially of the solar and the lunar races. This explains why so many Jain Puranic texts do not immediately commence the story after which they are named, but with the description of the universe and the different time periods, so the Utt and Avasarpenis. This parallels the Lakshanas of Sarga and Pratisarga. We are now in a degenerative period of time, the Anavasarpeni, having started out in the best possible situation, a Bhogabhumi, when people did not need to make any effort for their upkeep, so everything was growing on wishing trees, on the Kalpavrikshas, there was no fear, no disease, etc. Gradually, things are getting more unpleasant and eventually the wishing trees disappeared. At a certain point, during this Avasarpeni, people became victims to evil, and there arose a need for the institution of law and punishment. Parallel to this, 14 Kulakaras, or seven, 14 Kulakaras in the Digambara sources, seven in Svetambara sources, which are basically parallels to the Orthodox Manus were born in succession to educate the people on the changes going on around them. The last of these Kulakaras, or patriarchs, was the father of Rishabha, Nabhiraja. This links the theme of Manvantara very nicely indeed with the biography of the first Tirthankara. Moreover, according to the Jains, Rishabha is a progenitor of the Solar Dynasty, the Ikshvaku Vamsha, connecting him to the Orthodox subject of Vamshan Vicharita. So, according to some texts, his lineage was named Ikshvaku because he drank Ikshu, sugarcane from Indra, which he received from Indra when he was just one year old. And according to other texts, this has to do with the fact that Rishabha taught the people to squeeze sugarcane for its juice, so as one of the many things he taught to the people during his life as a king. Here, Rishabha is portrayed as more than just a Tirthankara, continuing the work of his father, the Kulakara. The same can be said of Rishabha installing the varnas, except of course for the Brahmana varnas, teaching the people the professions, so this Asi, Mashi, Krishi, etc. It is safe to say that in the Jain Puranas, Rishabha is more than a Tirthankara who receives and teaches the eternal Dharma. As a progenitor of the Ikshvaku Vamshah, it makes sense that his biography is told in the Jain Ramayanas since Rama is here considered one of his direct descendants. He is moreover also linked to the ruler, to the lunar or Suma or Hari Vamshah, which was started by one Suma Prabha or Suma or Shashi, the grandson of Rishabha and son of Bahubali. So, this again explains why his story is told in the Jain stories of Krishna, the Hari Vamshah Puranas or Mahabharatas or Pandavacharitas. So, in effect the corpus of Rishabha biographies is very vast and goes back to the earliest examples of Jain Puranic literature such as Vimalasuri's Palma Chariam, which at the latest dates from the 5th century and Sangadasa's Vasudeva Hindi also at the latest around the same time. But also it is found also in Jina Sena, Punatas, Hari Vamshah Puranas from the 7th century etc. Predating these texts we also find his life sketched briefly in the Shwetambra Agamas for instance in the Kalpasutra. His life is basically as follows and now I am basically summarizing what we learned yesterday. So, my summary is after the oldest three Jain Ramayanas, but it is more or less generic for the older biographies differing only in the order of the events. So, at some point during this avasarpini the Kulakaras, so either 7 or 14, were born successively to instruct the people. The last one King Nabi was married to the beautiful Marudevi. They were destined to be the parents of the Tirthankara. After all sorts of divine occurrences, so you have the goddesses coming to service the queen, the experience of either 14 or 16 dreams, rains of gemstones and golds coming from the gods etc. The boy is born. When the gods become aware of his birth, Dhanada or Kubera, the god Kubera is instructed by Indra to build the city of Ayodhya also called Saketa or Vinita for them. And here there is some slight difference with the Svitambara versions where the city of Vinita is generally built later, but also by divine intervention at the occasion of Rishabha's coronation. The child is then taken away by Indra and the other gods to be consecrated on Mount Meru as is usual for Jinnah. He is then returned to his parents and named Rishabha. The reasons given for the name giving differ in the different sources. So some say it's because of the vision of the bull as the first dream of Marudevi. Others say it's because he is the leader and then Rishabha in the secondary meaning as leader is given as the reason for the name. As he grows up the last wishing trees disappear and people come to King Nabi for help. He directs them to Rishabha for instruction. Rishabha marries and begets many sons, 100 according to most sources, and he becomes the king. And here again there is sometimes a difference in the order of events or sometimes he marries first and then becomes a king. Then one day he sees an Apsaras, the Apsaras Nilanjana who dies right in front of him and then he becomes disgusted with the material world and renounces it. In a divine palanquin he is taken to a park which is variously named but mostly referred to Siddhartha or Siddharthaka. Another name sometimes associated with this park is Prayaga. So this is the origin of Prayag being a Jain place, the place where Rishabha renounced the world. And together with many other kings he becomes an ascetic. Thereafter he starts to roam the earth until he reaches a place Hastinapura or Gajapura where he breaks his fast with Shreyamsa by drinking sugarcane juice. Rishabha then proceeds to Puri Matala and enters the park Shakatamukha where after a long period of meditation he attains Kevalajnana. The gods arrive and a Samavasarana is constructed for Rishabha to hold his first sermon. One of these people attending is a king called Rishabhasena or Vrishabhasena who becomes the first of 84 Ganadharas. After the preaching the gods depart and the Jaina leaves the park to roam around with his following. Usually the Jain Puranas here now commenced the story of Bharata and Bahubali and their struggle and their battle. And then after this and the death of Bahubali, Rishabha proceeds to Mount Kailasa or Ashtapada where he reaches the ultimate liberation or where he dies basically. The texts may differ in certain details or in the order of events but most of the story is the same. So Rishabha is the son of the Kulakara Nabi and Marudevi. His city is Ayodhya or Sakhetta or Vinita and he renounced the world after seeing Apsaras die in a park called Siddhartha. He breaks his fast with Shreyamsa in Hastinapura attains Kevalajnana in Puri Matala, roams around with the following including 84, again we have the number 84 which is interesting, 84 Ganadharas first of whom is Rishabhasena and in the end he dies on Mount Kailasa. In the older stories there is basically no great distinction along the Gambara-Shwetambara lines except for the number of dreams of the mother, 16 or 14 and the number of Kulakaras and then the order of events. Now interestingly significant changes occur in Rishabhas biographies from around the 10th, 11th century. In the Shwetambara accounts passages are inserted describing Rishabhas visits and sermons on Shatrunjaya the greatest of all Shwetambra pilgrimage sites. They further describe how his chief Ganadharah called Pundarika here in most texts attains liberation on Shatrunjaya. For this reason Mount Shatrunjaya is also sometimes called Mount Pundarika. Strikingly none of the earlier biographies of Rishabha mention Pundarika as a Ganadharah to Rishabha, but instead agree on the name Rishabhasena or Rishabhasena as the name of Rishabhas first Ganadharah. The Gambaras continue to use this name after the 11th century whereas Shwetambaras from then on either name the Ganadharah Pundarika or alternate Pundarika with Rishabhasena. Now the best known description of Shatrunjaya associated with Rishabha is probably that of the Vividhatirtakalpa of Jinnaprabhasuri from the 14th century. A famous guidebook to Shwetambara pilgrimage sites, but an earlier account is also found in the Saravali, one of the canonical Pa'inaya prakirnaka texts or the mixed texts perhaps also dating from the 11th century. The earliest Puranic account linking Rishabha with Shatrunjaya appears to be from the biography of Rishabha in Himachandra's famous narrative of the lives of the 63 great men of Jainism composed in the 12th century, so probably soon after the composition of the Saravali. In the sixth chapter of the first parvan after Rishabha attains enlightenment in a park near Ayodhya, he travels to Mount Ashtapada where a sacred preaching hall of Samavasarana is constructed by the gods for him. His son Bharata who has just become a Chakravartin visits him on this occasion and hears his sermons. Rishabha then goes to roam the world, returns again to Mount Ashtapada for sermons after which Himachandra describes how he, and then I quote from the translation of Johnson, surrounded by Pundarika and other Ganadharas went purifying the earth under pretext of wandering, mentioning the places he purified with his presence until he reached Shatrunjaya in the land of the Saurashtras. Here the story shortly abandons the rather legendary geography for a more realistic albeit idealistic version. Himachandra describes Mount Shatrunjaya in 20 verses conformed with standard poetic conventions rather than reality. The mountain is described as being 50 yojanas in circumference at its base, 10 at its peak and 8 yojanas high. And so if you basically the same height as Mount Ashtapada which is also 8 yojanas high. Rishabha ascends the mountain and enters the Samavasarana constructed there by the gods. After a three hour sermon Pundarika named as Rishabha's supreme Ganadhar, seats himself on Rishabha's footstool and himself gives a sermon on the Jain Dharma. After some days of presence on Shatrunjaya, Rishabha left to wander elsewhere instructing Pundarika to stay on Shatrunjaya. And here I quote again, you remain here on the mountain surrounded by crores of munis. Here your omniscience and that of the followers will appear soon from the power of the place. This quote unquote power of the place is again stressed in the words of Pundarika when he instructs his crores of followers to engage in Salekana a fast until death. In due course all attain omniscience and liberation and the gods come from heaven to celebrate this. Himachandra concludes, just as the master, the blessed Rishabha was the first Tirtha Krith, so Mount Shatrunjaya became the first Tirtha. And then he describes how Bharata made a shrine on Shatrunjaya where he installed a statue of Rishabha in Pundarika. Aside from Himachandra's great epic, the Sarawali and the Vivida Tirtha Kalpa and other guide books to Shwetambra pilgrimage places, this account is also found narrated in the Shatrunjaya Mahatmya by Dhaneshwarasuri. Now despite having been dated to the 5th or 7th century by early scholars such as Weber, internal evidence seems to suggest a date no earlier than the 14th century. This certainly parallels the development of the Rishabha story in the corpus of Jain Puranic and narrative literature. Several scholars estimated that Shatrunjaya may have attained some status as a sacred Jain place from around the 5th century onwards because it is mentioned on several occasions in the Shwetambra Agamas, though none of these appear to be in connection with Rishabha. Yet even though the site is not referred to in the early Puranas in connection with Rishabha, Shatrunjaya is not absent in these early Jain Puranas and other narrative literature. Pre-11th century Puranic poets, both Digambara and Shwetambara such as Guna Bhadra, Jina Sena Punata and Sri Lanka name it as a site where the Pandavas from the Jain version of the Mahabharata attain spiritual liberation, final liberation. Because these characters are not really considered great men or Shalaka Purushas, the poets do not really spend a lot of words on the description of this site or of the event. After the Shwetambaras began to associate Mahon Shatrunjaya with Rishabha, for Digambaras it simply remained the site where the Pandavas attained liberation and as such for them it was still a Siddhakshetra and worthy of respect. What is further interesting to note is that some later Shwetambara authors appear to attempt to loosen this Shatrunjaya Pandava association. So for instance in Himachandra's account of the Emancipation of the Pandavas, he refers to the mountain named Vimalas. What we see is that authors seem to want to avoid the name of Shatrunjaya itself when it comes to the liberation site of the Pandavas. Likewise we have Devendra Gani in his Tikka on the Uttaradyayana Sutra dating from the 13th century. He refrains from using the name Shatrunjaya instead using the name Pundarika for the lotus of the liberation of the Pandavas. Nevertheless Vimalas and Pundarika are known as other names of Mount Shatrunjaya. Though neither Himachandra nor Devendra Gani are explicit about this. Maladhari, Deva Prabhasuri in his Pandava Charita also names the site of liberation of the Pandavas, Mount Vimalas, but he does refer to the Munis such as Pundarika attaining emancipation at this in which he quote unquote the greatest of all Tirthas. These additions and changes to the Shwetambara accounts of the Rishabha story namely one the inclusion of Shatrunjaya as a place he visited and two Rishabha's Ganadhara named Pundarika reaching final liberation there run parallel to the history of the rise to significance of Mount Shatrunjaya as a sacred site. Despite references to a sacred site Shatrunjaya before the 10th century the oldest surviving inscription on the site dates from the year 1006 and is found on an icon representing Pundarika located near the main Adishwara temple. The Gambara accounts stay the same throughout history both regarding Rishabha's Ganadhara and the sacredness of Mount Shatrunjaya as the mountain on which the Pandavas attained liberation. It was never visited by Rishabha whose Ganadhara was known under the name of Rishabhasena.


Okay, we're gonna go ahead and get started. I'm just gonna invite those of you in the room to stand if you're able and would like to do that as we welcome the presence of the Lord in this place. Those of you that are joining us online, welcome. We're just gonna jump right in and just ask Holy Spirit to come and do what he loves to do this morning. So Jesus, we love you. And Abba Father, we love you. And we thank you for your son. Holy Spirit, we welcome you in this place as our helper, as our guide. We ask that you would just open the heavens over this place. I ask for just eyes that see the beauty of the Lord as we worship. I ask for ears that hear the heartbeat of heaven as we pray. Holy Spirit, would you just come and lift our gaze this morning, our eyes of faith into that invisible realm of incomparable splendor and beauty. I pray that you would pour out grace that we would agree with you, Father, that we would agree with the angels and the elders and the proclamations of the worth of your son, Jesus. Lord, let fingers prophesy on instruments under your prophetic anointing this morning, carrying the sounds of heaven across the airwaves, Lord, over Kalamazoo. I pray for vocal cords that will prophesy and agree with the declarations and the proclamations of the worth of Jesus in heaven that we would agree on earth. And that this sacred hour, this privileged hour where we get to be with you where you are, Jesus, where we get to stand with one another in the power of agreement, I pray, that by it, Father, your heart would be pleased and that you would be glorified, Jesus. We love you, Lord, and we welcome you in this place in Jesus' name. Yes, Lord, you alone are worthy and we love declaring your worth and agreement with all of heaven. There's nothing like your presence, Lord. We're gonna shift now into a time of intercession into our first prayer cycle, maintaining that posture of worship. We're gonna pray and ask the Lord to release the light of who he is into every sphere of society in Kalamazoo. We're just gonna hold our city before him as a remnant this morning and just say, Jesus, light of the world, shine your light in Kalamazoo. If you have your Bibles, I'm gonna begin praying out of the Gospel of John, chapter one. In verse three, it says, all things came into being through him and apart from him, nothing came into being that has come into being. In him was life and the life was the light of men. In verse nine, there was the true light which coming into the world enlightens every man. And so, Lord, we just thank you that you are the light of the world, that no darkness can stand before you, that no darkness can overpower the light of your countenance, the light of your glory, the light of your truth. And so, Lord, as a remnant of your priesthood in Kalamazoo, Michigan, we stand before you with our ear on the heartbeat of heaven. And we agree with you this morning for your plans and your purposes, your kingdom will for the city of Kalamazoo, every sphere of society, God. We hold before you now and we just say, light of the world, would you break in even now and shine your light that illuminates the darkness, that scatters darkness and shadows of compromise and deception? Lord, we pull upon the hem of heaven this morning and we just say, Father, open up the heavens over Kalamazoo, let light penetrate the dark places, let light overcome darkness, let revelation break into hearts even as we pray this morning. We declare light over Kalamazoo in Jesus' name. Shadows, the fines in the darkness and the darkness did not overwhelm it. Lord, I thank you that this is truth, that when the light of who you are, you who are the light of the world, when you shine, when you break in darkness, you cannot overpower the light of who you are. And so Lord, we just in agreement with your heart, we declare light over Kalamazoo. Can we just lift our voices and even just declare that? Light, light over Kalamazoo, light over your churches, light over the families, light over the education system, light over the sciences and medical fields, light over the government, light over the sports and entertainment, light over the marketplace, scatter deception, scatter rebellion and treason, scatter injustice, hearts of men in this city. Oh Kalamazoo, we see the glory of God, light to perceive rightly, to judge right light in Jesus' name. And you change everything, it's every man. And so Lord, we ask you to shine light into darkened minds even now, with darkened hearts. Lord, where the light has gone out in prodigies, where they've embraced compromise and sin, deception, and the light of truth has gone out. We stand in the gap this morning Lord, and we declare over these minds and over these hearts light, light that illuminates the darkness, suddenly exposing the agenda of the evil ones, suddenly bringing truth to mind again, bringing sons and daughters back to their senses, like flipping a switch, light breaking in. Lord, we stand and with the power of life and death that you have given to us in our tongue, we agree with you and we declare light over the hearts and the minds of prodigals right now, knowing God that our words carry the power Lord because they're your truth, they're your words in our mouths so we declare it light, light into the minds of sons and daughters Scott, where a spirit of deception has darkened the truth. We declare light breaking in prodigal children for their senses even now, taking Lord that in Jesus name. First prayer cycle, I just wanna invite you just to pair up in groups of two or three, choose a sphere of society that resonates in your heart and just begin to declare light into that, whether it's at the educational system, the sciences and medicine, the marketplace, the families, the church, just begin to just declare light as the team just sort of ministers to the Lord in music and then in just a few minutes, we'll go back into a collective time of worship. Let's just join this chorus now together. Shine light in the glory of God, bless the Jesus Christ. Love you Jesus. Little bit of time together. We're gonna go into a second prayer cycle. We're gonna go right into a rapid fire and that just means we're gonna just pull on the priesthood, our voices in the power of agreement and we're just going to pray for whatever is on your heart this morning for the city of Kalamazoo, whatever God has laid on your part. When we each pray our little part that we carry, we have a fuller expression of the great intercessor's heart and so I'm just gonna open it and if you all just wanna come, maybe 10, 20 intercessors, just come line up along this wall. These are not long prayers. These are prayer bursts, like 10, 15 second bursts for God to break in and move in some capacity in our city. And if you're joining us on the live stream, this is where you can take those prayers and just yes and amen them in application for your city.  These are short, just prayer bursts for Kalamazoo, whatever God has laid on your heart. And so Lord, I just thank you that there is no other name but Jesus and no other banner flying over the city of Kalamazoo. And God, I just ask that you would release a spirit of unity among the churches and among the leaders of the churches and ministries in Kalamazoo. God, that you would release grace for the walls to fall. Every divisive barrier God to love, I ask that you would release grace for it to crash, Lord, to hit the ground and that love would abound in your church in Kalamazoo, in Jesus' name. Lord, I just pray that you would be exalted on college campuses. God, that there would be no other false God that is exalted. Lord, in the hearts of the students, faculty and staff on college campuses, would Jesus be exalted in Jesus' name? Father, I just come before you and lift up the lost and broken specifically those who find themselves in addiction and substance abuse. And Father, I ask that your love would break in. Father, I ask that they would find you as the satiator and the fulfiller of their souls, God, that you would fill every void and everything that they're looking for and you would find you, Jesus. God, we just pray right now, will you just stir up the ground where it has been still and dry? Will you break up the soil, Lord? Will you pour out your spirit again and will you rain down on this land? Dear Heavenly Father, I pray that if there's any reconciliation that has to be done with the first nation that lived in this land, that that would be done in Jesus' name. The Padawan army lived here before and they were moved out 1830s, 1838. So we pray if anything needs to be taken care of, that that would be done in Jesus' name. Comfortable and sin, I pray that you would just open eyes of those who have grown complacent that they would just realize that there's more for them, Lord, and that what they're in is just not even as good as what they could be doing, Lord. And I pray that you would just open their eyes to the light of your glory, Lord, in Jesus' name. Amen. Ephesians chapter five verses eight and verse 14. For you was sometimes darkness, but now are you light in the Lord? Walk as children of light. Wherefore you say, wait thou that sleepless and arise from the dead and Christ shall give thee life. So Father, we pray right now in the name of Jesus. We pray for the body of Christ that we would recognize you. I pray that, Lord, that we would wake up and understand us, be alive in our conversations in the grocery store, wherever we must, God. And we speak to you. And ever shining on all the children here in Kalamazoo that have been led away in astray from God.  And I pray that each and every one of us here today grow out in this world today and be an amazing shining light like God wants us to be. There's one person today that you can touch and bring to the Lord. There's always somebody that you can make a difference in their life and show them how Jesus loves people. And we just, again, we pray for your light to shine bright in the prodigal children that have been led astray and they may come back home to you, Lord. In this, in your mighty name, we pray. Amen. I just pray for getting an abortion. I just really feel, I just feel like this is their only option or they feel ashamed of what happened or I just pray that you would open their eyes to the special life inside of them. And I just pray them to choose life. And I pray that they have the whole pregnancy that they would not regret their decision. Like you would just bless the pregnancy and the birth and just everything. And I pray that you would bless them for choosing life in this world where it's just so easy to get rid of a life or to just pray for all the people who are choosing to get an abortion right now, Lord, at whatever stage of the process they're in, I pray that you would help them just stop right now. I just really pray that you would help anyone getting an abortion in Jesus' name. Yeah, Father, we just thank you also for sending laborers to those girls to show them what it looks like to be a mom. If they don't know the ropes, Lord, teach them, send laborers to show them the way. Thank you for that. And I also thank you for Psalm two, Father. You said, why do the nations and the people plot a vain thing? The kings and the earth set themselves and the rulers take counsel together against the Lord and against his anointed, saying, let us break their bonds and pieces and cast away their cords from us. But then in verse four, you said, he who sits in the heaven shall laugh. The Lord shall hold them into vision and he shall speak to them in his wrath and distress them in his deep displeasure. Yet I have set my king on the holy hill of Zion. I will declare the decree the Lord has said to me, you are my son, today I have begotten you. Ask of me and I will give you the nations for your inheritance and the ends of the earth for your possession. You shall break them with a rod of iron and you shall dash them to pieces like a potter's vessel. Now therefore, be wise, oh kings, be instructed you judges of the earth. Serve the Lord with fear and rejoice with trembling. Kiss the sun lest you be angry when he perish in the way and kindle through. When his wrath is kindled but a little, blessed are those who put their trust in him. Father, we just thank you, Lord, that those who are coming against your people trying to break apart the bonds between us. Father, we just thank you, Lord, that you hold that in derision. And I thank you, Lord, that you will be magnified and lifted up. We pray for godly wisdom for our leaders and those in authority that your kingdom will come and that your will be done in Jesus name. Amen. We close, we're just going to pray a prayer together for the last number of days up until 30 days. We've been partnering with churches across Kalamazoo standing in the gap for a spirit of unity. And we have a prayer here written by Pastor Jeff, I believe from center point. And so we're gonna read this and prayerfully declare this over our city and over the churches. King Jesus, you can join me. Awaken the sleeping giant of your church in our city as we pray and collaborate to seek the common good for our region. Open our eyes and hands to the marginalized and our voices for the voiceless. We endeavor to live such counter cultural lives that our places of work and neighborhoods will experience the beauty and power of the gospel. Give us such an unquenchable passion for you and your word that we can't help but tell others about Jesus and his unstoppable kingdom for the glory of Jesus and the advancement of his kingdom. Amen. And amen. Well, Lord, we love you. We commit this hour into your hands, everything that has been prayed, everything that has been declared in agreement with heaven. We just say, Lord, would you multiply it many times over at this altar and all across our city and region and nation and the nations of the earth, God that you would find a mirror on earth as it is in heaven, your prayers, your songs, your decrees, Lord, as we gather as a priesthood and partner with you. We love you, Jesus. We welcome you in our city, in our homes, in our very hearts today. In your name, we pray and give thanks. Amen. Well, thank you for joining us this morning on the live stream as well. We are going now into a devotional worship set. You're welcome to stay and just soak in the presence of the Lord and in the Bible. If not, we just ask that all conversation be taken out. We're back here at noon and 6.30 tonight. God bless you.


Hello, my name is Burton M. Louis, Jr. I'm an associate professor of anthropology and African-American and African studies at the University of Kentucky. And I'm a cultural anthropologist who studies Haiti and the Haitian diaspora of the Bahamas. The author of a book called My Soul is in Haiti, Protestantism and the Haitian diaspora of the Bahamas, where I study issues of religious conversion to Protestant forms of Christianity and understanding the Haitian diaspora transnationally as well. I'm also interested in issues of statelessness, human rights, anti-Haitianism, and race and racism. And to answer the question why anthropology? Anthropology was kind of a way for me to understand more about my own heritage growing up as a... First, as a young black person in Staten Island, New York, I was subjected to a lot of racist bullying. And at the point in my life, I really internalized those ideas of anti-blackness. And when I went off to Syracuse University as a undergrad, I took an Intro to Cultural Anthropology course. And the Intro to Cultural Anthropology course had a very provocative statement within it when we were discussing race. And they talked about race being a social construction. And for some reason I had internalized the idea that it was rooted in biology. And it was a very profound moment. And then moving on, doing well in that Intro to Cultural Anthropology course, I ended up getting an A in that course. And I decided to declare an anthropology major. And then the next semester I took a course with Horace Campbell, a Jamaican political scientist, brilliant minds called Caribbean Society Since Independence. And the first book we read in there was The Black Jackalbends by C. L. R. James. And that book had a deep, deep impact on me. In Haitian Quill, we have a phrase saying, we flap M4. Which means it really hit me really hard to know that this was part of my heritage. To be part of this successful slave revolt and resistance to white supremacy and dehumanization was very inspiring. So I married my interest in cultural anthropology, specifically its methods of participant observation to help me kind of build a Haitian identity. And just learn more about the world and learn more about people of African descent and the African diaspora.


I think one of the more impactful scenes when you're going through the timeline and you're starting to see the weight of the world on McGuire, and you see Sosa kind of leaning into it. Sam, he's like, I've been waiting for this, you know? And then they have that joint press conference. You just see a different Mark McGuire than you've seen for the past couple months, because he's like, there's someone else going through this, and this guy kind of likes it. It was a little bizarre. I was going to ask, I haven't made a documentary. Was it yet? Was it on your dream? Did you want to get them in the same room together to kind of see if they could do that? Or, and what else was kind of on your dream board when you started this that maybe you were trying to do that couldn't come together? Because I don't know, when that scene came on and those two guys are in the same room, you're just like, you felt good for Big Mac for like the first time in it, because he looked relieved. Yeah, when we started talking about this, it was 2017 and the homerun chase 20th anniversary was going to be coming up, you know, the next year. So I thought, well, maybe there's going to be some place where these two guys are together, you know, like that there's a reason for them to be in the same room. I kind of didn't want to do it myself. Every time I thought about how I would do it, it just felt really stagey in my head. So I thought like, well, if it happens for some other reason, and then we get like the other footage, like if they do an interview, but we're getting the footage of them getting mic'd up and like seeing each other for the first time, that would all be great. But that, you know, just that never happened. I wanted to hear them each individually to see if their perspectives were the same. If they had a different memories, different experiences. One of the interesting things is so many people talk about that, that they felt like McGuire's whole demeanor changed, you know, when he and Sammy were together.  But I think also you have to remember that for Mark, he always really set, you know, 50 home runs by September 1st. Like I'm not going to even deal with this until we get to that point.  And then by the time, you know, they're back together in St. Louis, you know, it's clear that this is going to happen. It may not happen during this series, but, you know, Mark's at 60 and, you know, he's going to get there. And so I think that that was made it a little bit lighter for him for a moment because he really felt like he was going to set this record. Of course, then it like picks up to a different thing because he doesn't know if he's going to have the record at the end of the season. And when he, you know, he talked about that, you know, in terms of just the realization of like, oh, wait, this isn't over.  So to like rest, they weren't going to the playoffs, you know, like it had been a hard season, but he had to keep going. That was one of my favorite parts of the whole chase was at the end when Sammy finally went ahead of him and here's Mark saying, I just put everything my heart and soul into this. I broke the record. But so did this ceremony. He's like, I can't be a footnote. I got to be the guy to see him like come back and then just go on a tear. You break a record. Then all of a sudden you have that realization. I got it like you said, I got to keep going.  And then he hits two more. Like, what a feeling that must have been just like, boom, boom, boom. Some of my favorite footage in the film is Mark realizing that Sammy has gone ahead of him on that Friday night. Last, last weekend of the. I'd never seen that. Yeah. I'd never seen that shot before. And it was incredible because you can see him do like a triple take. Yeah. What? What? And then I'll go, he just bends down. He goes, yeah. OK, got to keep going. I mean, I never seen that shot. It was awesome. I'm a self-proclaimed baseball snob. Love the best highlights. Love all the best players. That's who I am as a baseball fan. So when I look back at the record breaking home run, I wanted a majestic homer to break it so we could see him trot around the bases. I mean, he missed first base, which is an iconic shot. Oh, yeah. No, he wishes it was like an upper-decker. Yeah, for sure. Yeah.  Because 90 percent of them were that. Yeah. The moonshot, no doubters. And then here he is trying to leg out a double and missing first. Yeah. Yeah. Now, I mean, there's very few of his own runs that are just over the wall, even in in Bush Stadium, like hit into the upper deck in the outfield. This is insane, truly.


Bay 11-7082 is a drug that can be used to treat inflammation, cancer, and other diseases. It works by inhibiting several different proteins involved in the inflammatory process, including those responsible for the production of nitric oxide, prostaglandin E2, and tumor necrosis factor alpha. Additionally, it blocks the translocation of P65, a key component of the NFKB pathway, which is responsible for regulating many genes associated with inflammation. This drug also prevents the activation of other proteins involved in inflammation, such as activator protein 1, interferon regulatory factor 3, and signal transducer and activator of transcription 1. By blocking these proteins, Bay 11-7082 can reduce inflammation and prevent the progression of certain diseases. This article was offered by J-Wee Lee, Man-Hee-Wee, Yun-Jee Kim, and others.