So let's go ahead and get started since we're at the top of the hour. Okay, well hello, YouTube and thank you, Gonshom. We want to welcome everyone to this week's episode of Open Infra Live. This is our new weekly hour long interactive content event series streaming live to our Open Infra YouTube channel on Thursdays at 1400 UTC. So today we are getting a very special behind the scenes look live at the PTG for the OpenStack Technical Committees meeting today. So we appreciate you all letting us join so Gonshom, I'll go ahead and turn it back to you. Thanks Ashley. Thanks everyone for joining. And in this PTG session, we'll be discussing about the release cycle things. First of all, I'll share my etherpad so that you can see the notes that I hope everyone can see the etherpad. So this is our today topic at line number 39. Let's move open stack to release cycle. So open stack is six month release cycle. And we are going to discuss about how we can make it yearly cycle or not. So I'll let Zulia to give some background about this topic and then we can start the discussion. Absolutely. So this topic really came out of a weekly social call that the Iran community runs which is geared at basically social interaction trying to keep us human relatable. And we were discussing one of our new features and one of the operators because the Iran community has several operators to also contribute. Basically said, that will be a very long time, if ever, if they were to ever get the upstream future that we just dropped or that we just added or though being a late release. And so we kind of got them to elaborate a little bit more and express things further. They started down this path of expressing how they felt demoralized by the six month release cycle, and that they were basically unable to ever catch up because their minimum turnaround time for certifying a new release of open stack was six months. That tended to be more like eight or nine months. So basically they are somewhere like six cycles back. And that means they'll never ever catch up unless they are able to make drastic changes in open stack or how they operate. And if you think about how that sort of problem space, that's really a business problem. But it should have some feedback into the technical process and development, because if we're moving too quickly, or we're trying to still move too quickly, then we're doing them a disservice and making it harder for them to adopt and use our software. And we're actually increasing their operator burden as an operator, because there may be some things or fixes that they absolutely need, but they now having to keep his back ports and they're having to build development around it when they could just get the latest version, but they can't get the latest version, because it has to go through the certification process. So this operator express this, and then additional operators kind of start chiming in like yes same same exact problem. It takes us six plus months to certify, and it's a risk management issue. And then developer start chiming in with frustration about the release cycle myself included. And a lot of this just that it's a driver of a lot of frustration both sides of development and operators that we try and scramble as much as possible to get a six month release out with latest latest new features. And when those features may never actually be able to be loaded up and used by some of the people even developing them for their own environments because they'll probably have to cherry pick them down and run them locally which increases their technical debt which makes it harder to certify things. You can get hopefully get the picture at this point. And I hear, I see Terry wants to speak. So by all means Jerry. Yeah, I just wanted to give some perspective on how we basically solve that discussion last time we raised it because it's not the first time we've been we've been discussing this and probably because it's not like there is no great solution to the problem and but maybe the trade off needs to be revisited and it's it's important that we ask that question regularly. Last time, the way we we solved it was by saying that basically fast forward upgrades would allow deployments to skip releases and to skip certification of certain releases. And therefore the pressure to upgrade would be less. I suspect that from the feedback you got that did not really happen or like people feel pressure to upgrade to every single release or like something is not working with the plan that we basically come up came up with two years ago or three years ago. I think it's part of it and I, I think it does come down to how organizations perceive risk management. Like I've talked with some non open stack folks over the years, it banks specifically. And they always go major version, major version, they never skip releases, or they never jump anything. Which means that they are basically stuck in this certification process constantly and having worked in litigation services for myself. A long time ago, we basically did the same thing.  You can't test everything in every matrix. So we ran into issues and as such we decided we had to slow down to do the right thing to keep our services reliable for our customers. And we at that point just couldn't skip anything. It increased our pain dramatically. And that's a real troubling. I mean, I like, I've certainly been burned by that as well in the past, but just because other other projects didn't take too care there and and make it difficult, I guess doesn't mean that you should lose all hope in the world and, and assume that it's always going to be that way but I guess I'm really not sure how like it's one thing to slow down to slow down but I'm not really sure how that actually ends up with people getting anything faster, unless, unless people are just like so dead set on deploying every release and you know they're working on Okada and they refuse to go through, you know, any skipping at all and so, you know, if it if it always takes them seven months to deploy a six month thing they'll never catch up but I mean like that's just that, you know, kind of bonkers. So if we if we double the time, or have our release velocity. So how are they going to get things quicker, like features and things. So. Okay, I guess there's a couple things we should probably consider open sacs not seen as the shiny new. It's more seen as a stable stable reliable useful platform. So they don't feel the need to, they don't feel the need they absolutely must consume things that quickly. So that's the it's a double edge sort of sorts there. But that's the people really need these things and there are a ton of Okada clouds still out there. There's a ton of rocky clouds still out there there's people slow are solely upgrading, but it's just if it takes them forever to get to the next version. And the solution as developers is to slow down. That does free some of our capacity up to be one more coordinated or possibly do intermediate releases and allow some of the operators that do need those new features to get those features much faster. It just it does come down to everyone's risk tolerance level and how they can mechanically move through their processes. And I, I can see the pain point that you bring from other users but I also see. I mean, this is like there's no right answer. If you go yearly you have the other issue of if I want to line something an open stack, and I'm an organization that 100% relies on upstream doesn't like to cherry pick things down. It's a different way to year now before I see my thing arrive or show up in the upstream stuff so now the people that want to move quick are the ones that have to be the ones that sit with back ported stuff. Meanwhile, the kind of slower people, are they actually going to start getting faster. I mean, like I said, Terry mentioned fast forward upgrades was like a thing or like a framework that was trying to help them accomplish that. And it didn't. So is the problem, the resources or is it like the framework like maybe even if you did three year release cycle so it's still like, it's still not people not upgrading. It doesn't sound to me like FFU. I mean FFU is just a plan anyway it's not like a thing you download and install. But it sounds to me like there's some sort of fundamental misunderstanding about whether it's safe to do that or not, or, or whatever I mean basically I think what we said by by declaring that plan was that we understand that people are going to do this we're going to do our best to not burn you and just randomly change something in the middle of of a thing that doesn't fit. You know, these things like we expect you're going to run database migrations and data migrations for each thing, but outside of that, you know we're not going to completely hose you. That should be our declaration that, you know, if we break it, we, we own it so it's it's safe to safe to take this approach and that that gives us both ways right it gives us the fast way and the slow way and so I guess somewhat tested to I think that's like how the red hat open stack product, like, I think it relies on that or does something like that. So, yep, and and and triple O I think has that stuff built in so yeah you could you could certainly choose your releases carefully to align with somebody else that happens to be doing a lot of testing and, you know, maybe do a maybe do a good job but you know even even we don't like always have the same granularity between our jump points so I don't know it seems that if I worry based on what the way Julia described it and maybe it was just the wording but I worry that it's a perception thing and not like well we tried this for six cycles and you know we got burned three of them so we we don't want to do it anymore. I don't think it's it's necessarily gunburned by us, but I think it's a business processes have become such that especially when the business is basically built upon the platform that the risk must be managed very carefully. And so then you end up in, you must only go major version to major version or coordinated release to coordinated release. There's, we could conceivably allow for a more flexible release model where we go okay everything's coordinated once a year, and things can move independently and we keep a sort of sort of a tested matrix. And that way there's still the delegated delineated. This is open stack as a release named release and then there's okay there's these projects are moving at x speed with these version releases and these fixes or changes. And as long as projects as long as projects test at that matrix them, I would think it's okay but again this is it's not necessarily anything technical pattern or process is going to fix it's going to say comfort level of the business that uses the software. I've heard this from operators last couple of years where it's just there and they become so risk adverse that any major thing is perceived as risk and thus is deferred or drawn out as much as possible, so that they are comfortable with it. And usually those processes take months. So, I mean I literally had a platform I was using a prior job. We were two years behind. Part of that was businesses risk management the other part was our certification process to get that that hardware and software combination into the into the data center. So, it's not like we're the only people with this problem to As an operator, I relate a lot with what Julie is saying. So, in a large organization that that deploys a lot of open stack projects, we basically say that every day is an upgrade day, because we are always trying to keep pace with all the releases of the different projects. And we try to do this by project so try to not overlap upgrades. So, this is very hard. However, I also understand the other side that when your release maybe will not solve the problem for all the other clouds that are still running or cut the rocky. For me, the question is why these deployments running these old releases still keep doing it. It's mainly because they are afraid to upgrade. And it takes a lot of time to test all of these things. One thing that as an operator I eat a lot is that the deprecation period of something in open stack. It's usually to release the cycles. Am I correct? And of course, if you lose the boats, basically then it starts to be very complicated. And when we are upgrading and we see that some of the configuration options were just renamed, but they still keep there. This creates a lot of friction for operators to to upgrade. Because then they need to deal with all these different things is not just upgrading packages. It's all these different configuration options that they need to figure out, even if it's in the release notes. But this is very, very hard for large infrastructures with a lot of projects. So for me, easing the continue to try to simplify the upgrade process will be the key for all of this. I tend to agree with that. And I think a big part of that is the fact that we've been very liberal in how you deploy open stack. We don't have like an open stack deployment tool, and that is the tool to use. And I think the other projects like Kubernetes has a QBDM and that's just like something that just like takes care of everything for you. So you don't have to know about all the details and everything. But having said that, I think the sticking point to what you're saying is maybe an idea could be something where, you know, you're doing upgrades, you know, projects can automatically. But that's the thing, right? Like if a project could rewrite its config file to have all the updated values, that's great. But guess what? Everybody's using config management at large scale and your stuff is going to overwrite it the second that the project does that, right? So it doesn't help that much more. I don't know. It just seems to me like, you know, open stack is work. It's not, you know, just put it on and it just does its thing. It is and it's not necessarily technical problem. It's a more of a human and perception problem that we have. And ultimately comes down to risk management in the business and their tolerance for it or intolerance. And at the same time, I know as a developer contributor, the six month cycle bothers me to no end. It's frustrating, but What's frustrating about it? Like is it the coordinated release process and the lack of really basically get told we have to do X, Y and C and it's like, seriously, we're doing it and we're adhering to trying to coordinate as best as possible. But you didn't you didn't look at the thing and see our other other things and our processes and how we're actually different cycle really cycle model. And it There's a lot of a lot of context that gets lost in that. And it's, it's for me as a as a project leader, it's frustrating to Yeah, so from from our release management perspective, one thing we could do is encourage everyone to do intermediary releases and then only do a coordinated release every year. Because that would have the benefit like we've we've not listed all the benefits of switching to one year releases. It's not just like reduce upgrade pressure or certification burden, but also from an upstream perspective, it would result in less stable branches could basically support older open stock releases for a longer time because you would you would have less branches to maintain and all our efforts to have like longer term specific releases be more like a long term support and others be short lived is not really worked either. Like everyone is maintaining a bit everything. So in the end, if we did Like what would be the main throwback if we adopted something right there would be only one coordinated to release every year, but we would still encourage projects to release more often so that features can be put out for the people that are waiting for features they could upgrade just one component and get that feature pretty fast. And then you could you would still have like a good cadence in terms of engagement of your teams, but you would be free to define it however you want rather than have to adhere to these six one cycle which might be too, too often or not often based on on the stage of the project and so I guess the drawbacks we would still have with that model is is the tested upgrade matrix because you would basically have like two styles of upgrades people that would do all the intermediate releases and people that would upgrade from stable release to stable release. But I guess that's already the case for like all the project that are already in intermediary releases release model. So what's your, like, what would be the main drawbacks of that, like, trade off, I guess. I have a small kind of question of your my theory like I, I like that idea but how does that work when it comes to integration, because if let's say, you know, ironic wants to have a quicker pace and really specific feature. Now all of a sudden like I don't know ironic 12.0, which was not the coordinator release version it's 11.0 is compatible with Nova 11, but not exactly anymore. How do we figure that part out like can you make these intermediary releases but they have to be still compatible with the rest of the stack or So take the Nova case because Nova consumes everybody right so you've got, if you've got basically two versions of Nova that people can come from right. You've got to you've got to test upgrade from the last coordinator release to master and the last intermediate release or whatever you know your six month unnamed thing is to to master. And then you've got all of the projects that Nova depends on that also have those as well so, you know, sender starts to go off and, you know, has released a thing but you know we need that new attachment API for our new code but we have to be able to operate you know with you have not upgraded the old one yet and maybe you came from the older older last named release of Nova so you haven't run the data migration yet that fixed the connector in our database for the new, you know, sender it like super much The testing matrix, whereas right now we have, you know, everything coming from last coordinator release to master and, you know, last master but that delta is really small and I just, while I have the green box around me I wanted to unpack one other that Terry said which was about the number of stable branches I that argument doesn't resonate with me at all I guess because that the ability for us to support back a certain amount of time does not really match to number of stable branches to me. But it's just Delta right like if nothing has changed in the Nova console service, I can backport stuff to, you know, full some no problem right but but if if stuff has changed is when it starts to become a problem and so you're still going to have two years worth of change. You're going to have fewer, you know, get cherry pick commands to run but that's not the difficult part the difficult part is. Okay it was a big conflict here I think I've got it resolved but I'm really not sure and the tests that run on this two year old release have been pared down so much that I'm not getting a lot of coverage anymore because of all the external dependencies and risky so I guess I'm not sure that that really gets us much in terms of, you know, more more stable branch support. I actually agree with what you just said rearing stable branches. Still branches are my nightmare of sorts. The delta is not that much it's everything else breaking. Well, yeah. That's purely time based right like yeah that stuff be breaking. Yeah, we go if I try and go to Queens it's good luck. If I need to go to train. That's usually pretty easy, pretty reliable. But yeah, it's, it's all the other external dependencies changing and breaking. And the, the test, you're right about testing model that's absolutely something but it doesn't necessarily have to be required or mandated. It could be you're on your own voyage at that point and the community could be doing the best possible job, or the community can have the tenants, or the project have the tenants where they, they do not break things or they communicate how they break things or change things. So it really comes down to what this project do, and how do they do it. And as a project that has been doing this for a while. It's actually not horrible. We, we, we really live live and operate by tenant of not breaking things. Well, I think we all do. I really, I really don't think that all the projects going off and kind of doing their own intermediate schedules and confusing the, what the picture looks like is going to increase the clarity for operators and I also think that none of the projects that I have a strong say in what I recommend that we claim to, you know, have these intermediate releases and a coordinated release and not test the upgrades because that's where the stuff gets really hairy and it just 100% will massively increase our testing footprint and our CI infrastructure requirement footprint because grenade jobs are expensive and, you know, we're going to have to, we're going to have to blow that out a little bit in order to have any sort of confidence for operators that, you know, this, this works. So, I have an idea which maybe kind of relates to some of the stable branch discussion that we were talking about or the stable policy. Maybe we could allow projects to backport features and allow them to have to make like not a major release so the middle bit is that I'm completely forgetting right now. It's a minor patch update. And so they can go ahead and do it up and release that. And so as long as they continue to integrate properly with the rest of open stack within that coordinated release then they're fine, which then allows projects to ship all the features that they need. And not ship anything that breaks any other part of open stack and if they want to ship something that breaks another part of open stack then they have to do it in a way that's backwards compatible so if let's say ironic wants to publish something that breaks the version of Nova, because it has a different API or something then Nova needs to have some sort of compatibility, so they can interact it with both, or something like that and they can only remove it. Once the next coordinated release would happen and so that way project to move at their own velocity and they have that kind of like two points in time in a year where they got a full reset on being able to start with stuff that break, because they'll they'll assume that it'll be the same kind of serious project that's running. I don't know if that. I don't know if I explained that in a good way or somebody can tell me if that was a clear. I think I lost you there. Isn't that what we already have with projects that that go with a non coordinated release they release when they want and they can get stuff out. I think they can't, they can't backport and add like features to older releases. Oh, you mean backport features to stable branches. Maybe I'm not too. Maybe I'm not into the whole stable branch stuff in this specific case but I'm assuming they're kind of releases off the stable branch or like for intermediary releases, you basically just release features and whatever, like whatever you want and then we pick the latest intermediary release to be part of the coordinated like six months release. So you can do that what you can't do right now is backporting features to like a previous stable branch, a previous release. That's more like a choice I guess it's it's a bit orthogonal to this discussion but it's it could clearly be changed like we we just said we just communicated that stable branches would only contain very safe patches so you should be able to upgrade those really safely, but we could also say that they're more like moving objects and but then the pressure to backport things would get potentially messy. As everyone would want their pet features back to their pet 20s. In some cases like, like no IPI wasn't in things we have like, like, it's not possible. Well, for API later things to backport right and RPC and database and objects, so I mean, if the goal is is not to make Okada, you know, live forever. I don't think that backporting features back there is going to help that right because that's that's what people are just going to do they're going to. And yeah, they're going to be like look I'm on Okada I really really need you to backport this thing from Zena and sweet now I can stay on Okada for another 20 years. Yeah. It's not a good idea to enable that. But there's there's there's somewhere we need to find a happy medium to in all these different contentious things. And that's kind of why I wanted to bring the discussion. So noting. Oh, sorry. Yeah, if I like to say like moving to feel for that topic but if you have a little bit of the things related to go ahead. I actually had a comment in the YouTube stream. Basically, if I'm interpreting the comment correctly. Basically, they end up putting efforts to upgrade on hold when they're building something on top of open stack, because they need a stable and changing platform. And then they run situations where they cannot afford the time and resources to do the upgrades with the regression testing while they're doing the other work. So it's kind of there are many people with multiple moving pieces all at the same time, but that that's exactly projects. That's going to be exactly the same thing with one year releases except the releases are going to be twice as big and have twice as many destabilizing things per release right so they're still they're going to be even more afraid to upgrade when they need things not to move when when we've got a year's worth of stuff packed into each scene right potentially potentially I mean it everyone's risk level and tolerances completely different. I don't see how that doesn't. I mean that that all that does is raise risk, it just makes the risk less often, in my opinion, I rather than having smaller stepping points that you're like okay this is a reasonable chunk that I can, you know, consume and upgrade to I feel like you'll end up with a huge chunk of stuff. So instead of a six week upgrade cycle twice a year you'll end up with one 12 week cycle and everyone will hate you. I think the problem is people are running six plus month upgrade cycles. No I understand doing their regression test. But I think this is where the where things, the disconnective work, a size of units and effort versus the way a entity being a business or an operator operates is if they, they can't necessarily consume the smaller chunk because of policy. Like I know, I know people that live in organizations where you cannot do a minor release, you must do major releases only. And you can only do major releases once a year. And these, these things seem like arbitrary crazy things, but how the business has chosen to manage its risk. So that cascades into everyone's daily life of how do I manage my cloud. And when the, and when that moves to two years should we slow down to two year cycles. I mean, we've provided a way to not have to consume every every granule, and we've, you know, we've said that we will own it if it breaks. Obviously we're not going to meet everybody's everybody's really I mean I have at least one customer who can't hit a 12 month certification cycle. And it's very specifically just not going to happen. And they're doing FF use so it's not the six month thing is not a thing but I mean like that's a significant chunk of even a slower coordinated FF you to FF you cycle. One year release isn't going to help them either in terms of fitting in all of their certification stuff. I guess I just not sure where it ends. I think the conundrum ends up being once an operator is at such an infrastructure size where we're talking thousands of machines. Their risks starts just dropping to nothing. They have no risk tolerance. There's goes to the roof and they have no risk tolerance because we have two of two people with thousands of boxes here. Right. I mean, Muhammad and Belmiro have a few boxes each, I think. Yeah. Time check we have around 20 minutes left so you're discussed a lot about upgrade and stable thing. So let's cover a few other points we have on etherpad. I'll go one by one and if I miss anything, feel free to interrupt me. So first is on line number 160 about the foundation marketing effort. So just something the current release model creating a support foundation marketing effort or it's just idea like it can be more aligned and can be helpful. I think that something that will be hard. I mean, from the marketing point of view, I don't know if it's going to be, you know, probably not a thing to say but you know marketing will always have things to talk about throughout. But I think one of the hard things is when you have such a long release cycle. It's kind of hard to keep people engaged and have some sort of like exciting news or like hey this thing came up or this thing just happened or we're going to do this thing. So it kind of just slows down the things you can talk about and especially if we're not also releasing new features then well you know there's not much to talk about other than like, here's this thing that we got released eight months ago that we're talking about today because we don't really have much to talk about. I feel like that's one thing the other thing is also the PTGs are also going to like be much more split out and we lose that continuous cycle of like staying up to date. That one is the marketing version of my comment below about release notes right the release notes becomes so large, double the size, your marketing thing becomes half as often and twice as much right so you probably, you probably only get to like put the a certain number of bullet points in front of whoever reads the marketing stuff every time you do that right so you you just literally, you can't be like alright guys well. Instead of reading this one sheet, you know we're going to ask you to read two sheets because we've slowed down our thing right now they're going to. There's going to be one sheet and like half as much stuff is going to get mentioned to people because we're doing it half as often. We actually see that today with ironic we have lots of smaller features that go in and when it comes to marketing it we get three or maybe. Yeah, kind of do a high level mention of rough of things but it's like the list of release notes is already a book for us. Yeah, yeah, so I mean it. If we end up doing intermediary releases then we could we could like explain some of the features that were released during. Like I wouldn't I wouldn't sweat it too much with the marketing part because it feels like first like today we're pushing less changes than we used to back in 2015 where when we had like features all over the map so in terms of quantity of features to like present in at the at the end release marketing meeting. I don't think that's that different. It's more like how do you keep the engagement throughout the year than the massive amount of marketing news you have at the end of the year. So it would be more that like people lose sight of open stock for one year and all the people that think it's dead will will only get will wait a year before realizing they were wrong where rather than six months. And the other thing is like what when you do those. Those intermediary releases we could have like if there is one feature we want to we want to hype or project we want to show that they are making quite progress we could we could basically talk about that project in particular, but that brings us back to the testing metrics and if it's really a no no and there is just no way we can make it work then then then I would definitely not support switching to one year releases if we can't have like intermediary releases to get features out to users and get keep the news cycle on exciting and people in the cadence of doing things. It's difficult to do one year releases without nothing in between for keeping the excitement outside but also inside. That news cycle is not just important for engaging people via marketing stuff it's also important for keeping the community engaged and and whatnot right I mean like this is why this is why two weeks sprints are an agile thing right to like keep everybody moving keep everybody synchronized keep the the goals, the goals and the achieving of the goals kind of within. Within you know you're kind of like temporal frame of reference and everything and a year is a long time you know I mean to go between. There's milestones, and even if you see like the number of full time contributors are reducing the first day by day so if say for example in my company I say okay I have one year for open stack to do all these features and all. They will obviously ask me okay let's do some of the other stuff for downstream. So that's the very much valid point for non full time upstream data. Yeah, and thinking a lot as well as like well. Sorry, I know we're talking about the marketing stuff that definitely I think is important is. You know, people, most folks that are working on open stack or salary and they're working on things. And so, if it takes a year if they're working on something and you know they decide to move on and do something else. If they're working with a year, you might end up with a bunch of stuff that's half baked, whereas with six months it's more likely for things to be driven and finished up in that six months cycle but I don't have related that is. Yeah, that's true. In other respect we see, like there are few comments on the pad like for the, how much process we might need to change if you move to the one release cycle, like deprecation policies or stable policies you already talked about, and maybe about the testing and how much like we support as per the stable versus extended maintenance and all this stuff. And obviously the ETL and TC term that's also leadership is one of the big question for us, because in every cycle we face the leadership issues for many projects, and in many of the project peoples or ETLs are volunteering with their extra effort. So with one year release needs a one year commitment from them. So that's also one aspect. Maybe leadership because we can have more issues with this one year release of maybe less so that's my point I think we might face more issues in that. Yeah, I mean that's that's a very reason that's a reasonable point but you know no one's forced to stay for a year if they decide that they want to move on and things over they can. So I think that that should be the. You don't like take a site you don't like take a stand for ptl thinking I'm going to quit halfway through right you're like, am I going to do this right now it's a six month thing and we're not able to get people to even commit to that or or stick around for it. I think it's a big problem I think that you know it's going to be a it's going to be something where we have to fundamentally change the mapping if if we're going to, if we were to do something like that and then of course TC is twice as long and you know we know how that went so yeah I feel like coordinate it again if we do in intermajority releases you could have like a ptl that is tied to a shorter cycle doesn't necessarily have to be one year. Again, I'm not sure it. It's definitely a problem if we just do one year releases, but if we manage to somehow make intermajority releases work across the board then it's it's not that much of a problem because the only thing special about the coordinated release is that it's it create we maintain a stable release out of it it's the only thing that makes it special. Well, it's also the high impact. Most important potentially, you know, getting all the ducks lined up on the important release so. Yes, please, please pressure because that's the important one and you need your future in that important one. There is like friction everywhere. I'm not saying it's the miracle solution, but it, I just don't see the like moving from six months how we do things currently to one year. I don't see that working for all the reasons you mentioned. And I could see like a model where we would, we would have intermajority releases and one year stable releases I could see that work. And it has drawbacks, but maybe the metric testing metrics problem is just not something we know how to solve in which case that's also a no no. Well, so me as an operator now if that's what we start doing and I need to upgrade. I'm running a survey and I want to go to Victoria. Do I go to tip of Victoria, or do I have to go to the intermediate release then like victorious first release like, what's my plan at that point because right now it's very straightforward. You just go to the next release, and you're good to go. And also do you. Are you willing to upgrade just your sender to one of those intermediate releases to get a feature or in reality do you wait for the fully coordinated fully tested.  If you do. We've got all the potential, maybe additional documentation or gotchas with like okay well how do I do I need to tell Nova that you know I've got, or you know, now I've got a new a new sender and old Nova so what's the what's the impact there. That's part of the testing matrix thing to Terry is like. And sender releases a new thing that they expect to be used as part of their, you know, more aggressive intermediate release they've also got to kind of assume that people are going to run that not with the kind of somewhat matching, you know they they landed patches and Nova and sender to go together but they need to make sure that the documentation and the, and the prescriptions also cover what happens if you didn't upgrade your Nova because I only upgraded sender to get that feature right so that's like the human testing matrix part. Well, as an operator, it's an operator justifying intermediated releases, it will be very difficult. So you have the stable release. If you have something then in an intermediate release that you really want. It's a huge risk. I think most of the people will just go for the stable one. Which, which effectively means we're doing that additional work in the middle for not a whole lot of gain. And if everybody slows down to the one year cycle anyway we've we've just slowed down our delivery. Yeah, and one more point in, sorry, in that we have to think about the hierarchical dependency that also like for no other depending on the sender for one feature but sender depending on someone else for another feature so that also make it more complex. Yeah. So here's a here's a possibility and I'm mentally going back in time. A long time, I'm thinking, one of the best things I ever did in the project was we create a tenant of the user or operator should always be able to upgrade from any version we release. Now, that's hard to actually test, of course, but somehow we got into this pattern of we only want to support have upgrades from within last from the prior release or two releases or three releases back. And that meant that upgrade code got deleted. And that's not ideal. I think one of the things that we could do is say we, we have a tenant of you should be able to upgrade from, say, say Victoria or train to whatever the next F releases or whatever, and be able to do it seamlessly and it just work. I would love to be able to say that too. But I mean, I know, I know it's it's it's an ambitious thing but that would also give people and organizations a much higher level of trust in the software. It will also change how we how we make changes, but it won't give them more trust if we can't test it and and if we can't test it it's not going to work. Nova, Nova has so much larger of a problem of this than everybody else because Nova runs on thousands of box boxes and a deployment where most of the other services run on like three and there's data that has to be collected from those boxes. Sometimes during an upgrade when we need topology information that only that box can tell us, like, not not being able to assume at any point in the cycle that we have got information collected in the previous cycle or the cycle before that. You know, just means that like all of our database columns have to be nullable forever and we always have to do, you know, an if none check everywhere and then, you know, you think you can make a call an RPC call to a compute node and that it's going to have this available and and it might not I mean it just it just introduces a massive amount of debt into the code and when you run on thousands of boxes and each deployment that's really really really substantial. I also also don't know if that will even like resolve the whole, it takes me seven months to certify in the release of six months like that's if that's kind of what we're like, I think if you focus on what are we trying to solve is, are we trying to help out some of those developers that can't keep up. Or are we trying to help our developers ship code faster or like what's the root thing that we're trying to resolve. Well, I I think that Julia is exactly right that we want we want to not lose trust right we do not we do not want to give them any more concern over the upgrade process and and to me. Any upgrade for any upgrades are hard anything that's not tested we should assume is broken like anything and the larger we increase the scope of things that we say will work but that aren't tested is trust is trust goes down in that equation to me. Yeah, no that's a good point and I mean if people were feeling already pretty skeptic about doing an upgrade. And they run into an issue that hurts, they're probably not going to do it next time or they're going to try to dread it as much as they can because it is as painful. Remember last time what happened. And, and so, because we were not testing it, then someone shows up tire see and is like hey I'm running to this issue and we're like whoops. There's nothing there's no test that are testing the upgrade that you're doing. Looks like you're going to have to figure out how to fix the code or something along those lines and so I feel like that might negatively impact. For sure, the perception that upgrades are hard and make it even harder, whereas now I mean, I understand people have the whole certification stuff that they're doing and all this other things that, you know, but for the upstream code it just works and we have tests that are testing upgrades all the time making sure that they're working properly. No, they're still going to be small things that show up but I think that I don't know. I find that what we currently have is working pretty neat. I think my only concern here is maybe that maybe we just need to talk to that organization and see if there's something else we can do to help them. Maybe not be able to certify faster, or talk through them through like hey maybe you could follow the FFU path. And that's the sort of thing that you can go towards and maybe do a little bit more of explaining and talking rather than changing policy to adapt. I think we could literally just start releasing major releases for every release and technically they could upgrade to anything at any time at that point. Right, we can just tell them anything will work and then wait for it to break. So guys we have just I think one minute left for our session so I'd like to conclude us like how we want you to go further on this to want to continue it on tomorrow or we have, if we have called pretty much all the topics maybe we can think about the X and I don't from here. Like as Mohammed mentioned, going towards the operator and get the feedback. So, can I ask a quick question. So, two of our two of our largest operators are here. And this isn't a concern for them is this is this an education issue perhaps that we could address it that way. And messaging, I think that what what Mohammed was just saying actually is maybe maybe a good first step is to let's let's communicate look I don't know if you guys remember or no maybe you have shown up since the full FFU thing but FFU is a thing that we expect to work and we take responsibility to make sure that it doesn't break and that allows you to do the following thing we expect that to work if you want to not deploy every release, or certainly every six months. This is what we expect you to do. We expect it to work, you know, communicate what that means again and again communicate the support that we have for it and see if that helps people be less. So, I think it makes sense and we can start with the mailing list, let's discuss on and hopes meet up. If we still have hopes meet up things. But I think as a first step, I think we can conclude this on mailing list and keep continuing the discussion where we have operators and other operators channel also like hopes meet up or meetings. I think we can come up with some action items tomorrow on this so we can help. Yeah, I think so say tomorrow we can get the action items. So, yeah, we'll continue with that item tomorrow so we have one minute left so I'll handle to Ashley to wrap up the things and present for the next week. Great. Thanks. Well, thanks to you and the entire TC for including us today and letting us see a little bit into your world during the PTG. It was awesome to get behind the scenes look from some of those conversations and thanks for interacting with our YouTube audience. That was great. I'm also hoping to do and ask me anything episode with this group soon as well so stay tuned for that and be sure to join us next week for a recap of the PTG. We'll let y'all get back to your meeting. Oh, thanks Ashley and thanks everyone for joining and this ends our today TC PTG so tomorrow we are going to meet at 13 UTC for for our discussion. We have a break in between. So join us tomorrow for further discussion or anything you'd like to discuss what we have on the iPad. Thanks everyone and have a good evening and night. Thank you. Thank you. Bye bye.


Welcome back for the last talk of the day, which will be given by Mike Hagan from Brandeis, assembly budding, and then encapsulation by Polyhedra Schell's Mike. OK, thanks, Christian. And thanks to all the organizers. I'll join everyone else in thanking them both for bringing us to this wonderful place and bringing such a wonderful group of people together. And so what I want to talk about is motivated by something I think many of us are interested in, which is in how do proteins that start out in disordered positions like this get into this well-organized shell? And in looking at one of these beautiful structures, it's easy to give the proteins all the credit for driving this process. But as I think we've heard many times over the past couple of days, if you have a substrate like, say, RNA, then you have to ask what role is the substrate playing in the assembly process? So what I'd like to do today is look at two different substrates with different architectures than the RNA and ask how are they affecting the assembly process and how does the pathways and the outcomes depend on the properties of the substrate? So the first substrate we're going to look at is when the proteins are assembling on a fluid membrane, like a lipid bilayer, in the context of assembly and budding during the egress of an enveloped virus. Then the second one we're actually going to step outside of the virus world and into the bacterial world and look at a system in which icosahedral shells assemble around a cargo consisting of many unconnected particles and those particles are encapsulated in the shell. Okay, so to start with the assembly on a fluid membrane, as I said, this is in the context of enveloped viruses which need to acquire an outer membrane envelope by budding through a membrane in their host cell. And this includes many of the nastier human pathogens. The particular family of viruses I'm going to look at is the alpha virus family and this is motivated through many discussions with Tuli. And so here I'm showing a schematic of the alpha virus or this is Cymbus virus and it has two layers. On the inside you have RNA that's surrounded by capsid protein and this is called the nucleocapsid core and then you have an outer layer which consists of the membrane which is shown in green and then these transmembrane glycoproteins which span the membrane and interact with the nucleocapsid on the inside, okay? The nucleocapsid may or may not have icosahedral symmetry but the outer layer is comprised of 80 of these glycoprotein trimmers that are arranged with T equals four icosahedral symmetry. So in general the enveloped viruses are thought to undergo or acquire their membrane by two different pathways. In one pathway the proteins, the nucleocapsid is actually assembling on the membrane and driving deformation of the membrane. In the other pathway, the nucleocapsid first assembles into cytoplasm, it then targets the membrane, recruits glycoproteins and drives budding. And alpha viruses are interesting in this context because the traditional view is that this is the pathway by which they undergo budding that the nucleocapsid first assembles in the cytoplasm then undergoes budding. And so the view is that this is very much driven by the nucleocapsid but why this is interesting and a little bit controversial is because there's been several works that show that you actually don't need the nucleocapsid in order to get budding. So there are several works in which the capsid protein is either impaired or completely knocked out and they still see budding of particles and in fact in this recent work they actually saw budding of infectious particles. So this raises a couple of questions. What is the relative importance of the glycoproteins and the nucleocapsid in driving this process and more basically what do you even need this nucleocapsid for? If you can get infectious particles without it why does the virus bother with this? So what if anything is having the nucleocapsid contributing to the budding process? So those are the questions that we wanna look at. We're gonna use rather simple computational models to try to answer those questions basically by comparing the assembly in the presence and absence of a nucleocapsid. So we're gonna have to use a simplified model if we want to look at the time and length scales relevant to this process. And so we're gonna try to make a model that is as simplified as we can make it while still retaining the essential physics and geometry of the problem. So it's believed that these glycoprotein trimmers are actually the basic unit that undergoes the assembly process because they're heavily intertwined within a trimer. And so in our model the elemental unit is going to be a model trimer. And to model the trimer we've basically stuck these three conical particles together and these are gonna move as a rigid body. So they roughly have the shape of the real trimer. Now we have interactions between the interior beads of these conical particles. And because of the cone angle when these come together they're gonna have a preferred curvature. And Guillermo, my postdoc who did this work has set the cone angle so that if you let these assemble in the absence of a membrane they'll very reliably produce capsids or shells in which you have 80 of these cones. And it's at least roughly has icosahedral symmetry. So if we want to have the nucleocapsid present again we're gonna model it in a way that's as simple as possible. It's been shown that the nucleocapsid doesn't necessarily have icosahedral symmetry or it's not required to have it. So we're gonna model it just as a rigid isotropic sphere and it has short range interactions with the base of the cones modeling the fact that the cytoplasmic domain has short range interactions with the nucleocapsid. How can you get 80 combining? So you have 80 of the trimmers. So it's 240 of the cones. So there's one other feature of the model. It's been shown in a number of systems that the viral proteins typically when they're free in solution are in confirmations that are actually incompatible with assembling into the capsid and that they have to interconvert into a relatively unfavorable confirmation to be active for assembly. And we've shown recently that this having this feature can significantly enhance the robustness of assembly to variations in the parameters. And we found that we needed to include this feature in order to have productive assembly at the very high concentrations of these glycoproteins that you see in the cell membrane during an infection. And so we've included that in our model. Okay, we need one other ingredient, which is a membrane. And again, we need a model for a membrane that we can simulate on rather long time scales. And so we're using this model from Cook and Marcus DiCerno which you have three beads per lipids. So one head group and then two hydrophobic tail beads. And there's interactions between these that you can readily tune to capture the properties of different biological bilayers. So then our glycoproteins are gonna span this membrane and the hope is that they're gonna undergo dynamics to make something like this. We're gonna simulate that dynamics using Brownian dynamics and to answer Dennis's question before he asks it. We also did other sets of simulations where we include all of the long range hydrodynamic interactions and we see qualitatively the same behavior. So what I'm gonna show you now is an example of a typical simulation when we have no nucleocapsid present. And again, the way we're gonna draw these is the active subunits are in this purple color and inactive subunits are in this brown color. So what you're seeing here is the initial stages of the assembly process. They're proceeding quite rapidly. By the way, here is the same thing as here. Here you're just seeing a cutaway view. What you'll see is that at first we see assembly proceeds very rapidly due to the curvature. It's deforming the membrane, but right about now it's starting to slow way down. And that happens just as we get to about two thirds of the way complete when we develop a significant negative curvature at the neck. And here we skipped over that process because we got tired of waiting and eventually we undergo a thermal fluctuation where a scission is gonna happen and then the capsid floats away. But so I think the most interesting feature of this assembly process was the dramatic slowdown that occurred after we got to about two thirds complete when we had that negative curvature. And I'll have more to say about that. Here I'm gonna share the same thing but with the nucleocapsid present. And what you can see is that there's actually very little visual difference in this process. Once again, we see that assembly is fast at first. We developed this inward curvature. Notice that the proteins tend to be absent from that region with the inward curvature. And that is, in fact, why you have such a dramatic slowdown at that point. Yes? We've made it so that they're commensurate. You could try other, but we focused on the case where they're commensurate. So what I want you to see in this is that overall the process is very much the same with and without the nucleocapsid. In both cases, you have this slowdown that occurs when you have the inward curvature. I'll show you in a little bit though that there are some differences when you have the nucleocapsid present. First I wanna focus on the case where it's not present. What I'm showing here is the typical outcome at the end of rather long simulations as a function on this axis of the strength of interactions between the glycoproteins. What you see is when the interactions are very weak, not surprisingly, nothing's able to nucleate and so you get no assembly. If we make the interactions moderately strong, so these blue points here, then you see complete shells as I showed you in the movie. If you make them overly strong, then you get kind of sort of complete but messy shells called the holy shells. And this is not unexpected when you do empty capsid assembly. If you make the interactions too aggressive, you'll tend to get poor assembly like this. So one interesting case is this narrow region at relatively weak interactions. What we find here is that the assembly actually stalls and we have what we think is an equilibrium state where we have this partial assembly and the proteins are never able to make it over this barrier. And I should say the reason why this barrier occurs is that it's actually unfavorable for the proteins to sit within this inwardly curved region and we tried many different protein geometries and we find that this is very generic. Yes? I'll show you what happens with a harder to bend membrane. So we think this could be possibly of some interest to the case of HIV because, so we're not including in these simulations any host cell machinery to drive scission. And if you think about a system that's sitting for a long time in this state and it recruits scission machinery, in that case, you would expect that you would be left with a hole on the bottom of the capsid and you do indeed see that. Yes? So we actually looked at that in previous simulations where we had a much more simplified capsid and we did find that if you have heterogeneities present that the line tension can help drive the assembly process in one of the ways in which it helps drive the assembly process is it actually changes the shape of this neck so it makes it more shallow. So I'm quite sure that if we go and put a heterogeneity into these simulations we also would see this probably being alleviated less metastable so they do play an important role the heterogeneities but just to simplify, I have fewer parameters we focused on a homogeneous membrane in these simulations. Okay, so one of the things that surprised us when we looked at these complete shells is that the size is not at all uniform in particular here I'm showing as I vary the strength of the interaction strength that the mean size of the shells that assemble and you see that it varies over a pretty significant range and they're always larger than the preferred size without the membrane which was the 80 trimmers. We see that as the interactions get stronger we're approaching 80 trimmers but we never actually get there and eventually it starts making these holy capsids. This is what's surprising to us because normally when you make the interaction stronger you expect to see your assemblies getting less similar to what you think is the ground state and here they're tend to get more similar and if you compare that to the case with the nucleocapsid you see that in that case the butted shells tend to be much closer to the preferred size. So what's happening here? We think that we can actually explain this with a very simple equilibrium model. These simulations of course are at finite time so they're not necessarily reaching equilibrium but we can still get insight from an equilibrium model. So what we've done in this model is we've asked what is the elastic free energy as a function of the bud size taking into account the penalties for bending the membrane away from its preferred curvature which is to be in a flat state having no curvature and that's pretty well captured by the health rich free energy which just says that the cost, the elastic energy cost is quadratic in the curvature and there's a coefficient which is the membrane bending modulus. We add to that deviations of the shell from its preferred curvature because if it's making these large shells then it's at something other than its preferred curvature and again to leading order that cost is gonna be quadratic in the difference of the curvature. Now if you consider a state that just before it undergoes scission, remember we're not interested in the scission process, you can integrate over the whole bud and you get this expression. This is the contribution from the membrane which is actually independent of the size of the bud but then you have this term which again comes from the deviations from the intrinsic preferred curvature. So here N zero is the 80 trimmers. So looking at this expression, you might think that this, you'll see that this free energy is minimized by having N equal to N zero but it turns out what's relevant is what is the equilibrium distribution of bud sizes in a system with a finite concentration of subunits so you can derive that with a simple density functional theory and you arrive at this kind of very familiar law of mass action here. This is the concentration of buds with different sizes N. It's proportional to a Boltzmann factor where this is the free energy of a bud with N subunits but then that's modulated by this term out front which is the equilibrium monomer density raised to the power N and this accounts for the translational entropy cost of putting the subunits in. If you optimize this, you'll find that the optimal shell size is actually that which minimizes the free energy per subunit and because of that you end up with an expression that says the optimal shell size is going to be the intrinsic preferred shell size but now increased by a factor which depends on the ratio of the membrane and shell bending moduli. And this is easy to understand physically. There's a competition between the membrane which would prefer to be flat and so wants the buds to be bigger and the glycoprotein shell which wants to stay closer to its preferred size and depending on the ratio of these you see as the membrane gets stronger the shell size is going to get larger. If you take this expression and you compare it to the simulation results you see that it actually fits them pretty well without having to introduce any parameters. And the key point here is that as you increase this glycoprotein interaction strength you're also increasing the shell bending modulus because that depends on the strength of the interactions as I tried to deviate away from the preferred curvature. We recalculated that increase is a linear in the interaction strength. And then so why would the nucleocapsid stay so much closer to the preferred size? Basically because the nucleocapsid is a rigid sphere so it effectively increases this shell bending modulus so that this whole term goes closer to one. And so this is just one parameter value so to get to Bill's question we ran a number of simulations over a range of different membrane and shell bending moduli so all of these different color symbols are for different values of the membrane and shell bending moduli. What we're showing here is the number of subunits in the shell as a function of this dimensionless ratio and you see that all the data claps on to each other and they pretty well follow this theoretical line up until we get to a threshold value of this ratio at which point suddenly they fall away from the line. And the reason why this fall away occurs is that at this point the membrane bending modulus is simply too large and the shell is not actually able to complete itself and you end up with these large holes at the bottom and in fact these points up here correspond to this metastable state I showed you earlier where it's never able to get past this point. Okay so I think this is an interesting prediction and it shows interesting consequence of having nucleocapsid present which is that you avoid all of this polymorphism in the assembly product. So I think this is a prediction that we hope to have tested in Tully's lab. At the moment there is experiments that are consistent with it but I can't say they really test it. So most relevant are these experiments from Rhyskian where they were looking at alpha virus and as I said they had buds that occurred in the absence of nucleocapsid. What they found when they analyzed those buds is that they are in fact tend to be larger up to twice as large as the case with the nucleocapsid present and they're much more polydispersed. So here are shown micrographs with the nucleocapsid present and they're pretty uniform. Here you have some example buds that occur in the absence of the nucleocapsid and they're larger and more polydispersed. Now there are some caveats with this because we don't know the bending modulus of the shell in these experiments and we don't know the preferred curvature either and there are some other systems where they don't seem to see this. So I think this is at this point an interesting prediction that we would like to see tested. So with that I'm gonna move on to the second topic. How much time do I have left? 13 minutes, excellent. So the second topic is now we're moving to this different substrate architecture where we have many unconnected particles that are going to be encapsulated. This is relevant of course in these artificial systems where groups are re-engineering viruses to assemble around some say enzymes in their components so that you can have a customizable nanoreactor. It turns out bacteria thought of doing this a long time before humans did and it's in the form of something called bacterial micro-compartments. So what these are is internal compartment within bacteria and their function is to sequester a particular metabolic process within the cell. And I'll show you how that works in a second but these are found in about 20% of bacteria and there's many different metabolic processes that are facilitated by these structures. What I'm showing here is an example of one well-studied bacterial micro-compartment which is found in cyanobacteria. So these are the so-called blue-green algae. It's a picture of them here. They're responsible for these toxic algae blooms.  So they're pretty important. And what you're seeing here is an example of a micro-compartmentist as black blob that you see here. And this micro-compartment is known as the carboxysome. That's because its function is actually to facilitate carbon fixation by the cyanobacteria. And these are popular enough that if you look on Wikipedia you can see examples of purified shells. And from these you can get a sense of what the architecture of this shell is. It's roughly icosahedral, which you can see from the facets. And here is a schematic of its structure. And so the shell is comprised of hexameric and pentameric protein oligomers. Presumably the hexamers are tiling the facets and then you have 12 of the pentameric units at the vertices. And then inside you have a dense complex of enzymes. And in the case of the carboxysome you have the enzyme rubisco and then other components that are needed to convert the products of photosynthesis into sugars. And the reason why the carboxysome is needed is that rubisco is this very ancient enzyme and it's very ineffective at the ambient concentrations of CO2 in a bacteria. It simply is unable to drive the Calvin cycle. It needs to be brought to very high concentrations along with CO2 inside of the shell and then it can do its job. So this has been known for a long time but until recently I wasn't known how these things actually assembled to arrive at this structure. So recently there are experiments done in a couple of groups I'm showing here, experiments from Cheryl Kerfeld's group. And what's shown here is in red is showing the outline of cyanobacterial cells and they've labeled the rubisco in green. And so after they induced the carboxysome genes the first thing that happens is that all of the rubisco in the cell undergoes phase separation forming a single green clump, such as you see here. Then over the course of time you'll see these clumps will separate into multiple clumps. And so what's happening during this separation process you can get more insight if you look at a higher resolution. And so in these micrographs what's shown is if you look at these two clumps one of them is amorphous as it is at the beginning of the experiment whereas the other is faceted presumably having the structure of the carboxysome. And so the interpretation is that the shell proteins have adsorbed on this initial complex of rubisco which they call the procarboxysome and then assembly has taken place such that the shell essentially carved off a piece of the procarboxysome ending up with it on the interior. So the question then is what are the conditions under which this assembly and brutting process can actually proceed? What are the mechanisms by which the shell will undergo closure and what does the assembly product distribution depend on? What are the key factors? So those are the kinds of questions that we can ask again with relatively simple simulations. Okay, and so we're gonna use a model where again it's thought and there's evidence from AFM experiments that the basic assembly unit in this system is these oligomers the pentameric and the hexameric oligomers and so those are gonna be the basic units in our model. And I'm gonna start with a model in which these pentamers and hexamers interact with each other by an adjustable interaction strength but in the initial model we've made these interactions specific enough that this is the only complete shell that can assemble. In a little bit we're gonna relax that approximation. Okay, and then there's a, the potential is such that there's a preferred angle that these face-face angles that these interact with. Okay, we need also a model for the cargo. This is the actual structure of the Rubisco hollow enzyme for the simulations I'm gonna show you remodeling as a spherically symmetric particle that has short range attractions modeled by a Leonard Jones potential. We did also use a more complicated model that represented the eight-fold structure of this and we get similar results. Okay, it turns out in the real system there's an auxiliary carboxyzone protein that's driving interactions between the cargoes and also between the cargos and the shells. In both cases we're gonna represent that interaction by a direct pair interaction between the cargo or between the cargo and the shell subunits. And so in all we have three different interactions that we have to worry about, the shell shell interactions, the shell cargo interactions and the cargo cargo interactions. And the question is as we vary these interactions what kind of assembly behaviors do we see? I'm gonna here show you an example of a typical simulation and this was runout parameters where you see rapid formation of this globule of the cargo and then the shell proteins have started to adsorb onto it. And what you'll see is that at first adsorb onto it in a disordered manner, very reminiscent of the way the capsid assembly occurs in the Gelbart-Nobler experiments. But now they're starting to realize that they can interact with each other. The shell is gonna start to assemble. And if you wait a while you'll end up in this case with two shells that are separated by this kind of neck of cargo particles. What needs to happen at this point is shell proteins need to get in there, realize that they can interact with the open line and they eventually do and they'll cut the neck and now we've had complete budding of our complete functional carboxysome, five minutes, okay? So we can ask how this depends on the perimeter values in interest of time. I'll just show you one example. So here we're varying the strength of the shell cargo interaction. Here we're varying the shell-shell interaction strength. And there's a regime of modern interaction strengths where you get good assembly. If the interactions are too weak then you either get no assembly at all or it gets stalled at this globule state. The interactions are too strong you tend to get malformed assemblies. So one interesting feature is that this is all at a fixed cargo-cargo interaction strength. If you reduce the cargo-cargo interaction strength such that you don't get this initial phase separation of the cargo anymore, then you'll see assembly and cargo coalescence happening at the same time so you have a different assembly pathway. And this appears to be a pathway that another type of carboxysomes use. So we see here that the cargo-cargo interaction strength is the key parameter that determines the two different pathways that are seen in two different carboxysome systems. So what I want to do in the last three minutes is ask what happens if we allow the shell to form other shell sizes and how does the size of the product depend on, for instance if you have the cargo. And this is motivated by some experiments that showed in the normal situation in a cyanobacteria they have rather large polydispersed shells that form about 200 nanometers in size but if they assemble them in such a way that they can't assemble around cargo they're small and monodispersed around 20 nanometers in size. So an inference from this is that the presence of the cargo is driving the shell proteins which have this rather small preferred size to form much larger shells. And so we're curious, could our model show something like that happening? So to skip over some details we've made it now less specific so it can form any size shell but we're gonna use parameters where in the absence of cargo it still reliably forms these small T equals three shells. So here is what happens if we now give it cargo. What you're gonna see is that it's actually forming much larger shells. In this case they're a little bit larger. You see that this is maybe closer to T equals four in size. If we make the shell cargo strength even stronger what you're gonna see is that it essentially just completely wraps the globule and so we get a much larger shell. And the reason why in this case the cargo is making the shell larger is primarily because in the carboxyzoam system it's only the hexamers that interact with the cargo and the pentamers only come in once there's enough hexamers there so they can interact with neighboring hexamers. So as a consequence of that as you make this shell interaction, shell cargo interaction stronger it takes longer and longer to get those 12 pentamers in there and so you get a larger shell. The cargo-cargo interaction in this case is strong enough that it will phase separate. If it's assembling by the other pathway where they're assembling at the same time then you don't see large shells like that. So this is just quantifying what I said there. On this axis we're varying the shell cargo affinity and you see that as it goes up the mean caps and size goes up until you get to a point where this is too strong and what happens is these drop down now because you get nucleation of shells happening throughout the system and now they're starting to assemble by this other pathway and then we don't see large shells forming anymore. So I think I'm out of time. So let me just try to give this some context. How this fits kind of into cell biology. So it's becoming very apparent that liquid-liquid phase separation plays an important role in organizing cell interiors. There's a big question how the size of these phase separated domains is controlled. Here we see one mechanism where protein shell assembly can actually control the size of a domain but we see also that in turn that the presence of that phase separated cargo is affecting the size of the protein shell. So there's an interesting feedback between the cargo and the shell assembly. And so with that, we have some theory for this also but I will have to skip over that. And so let me just thank Guillermo Lazaro the postdoc who did the alpha virus work. The carboxyzones were started by Jason Perimeter and then have been taken over by my grad student, Fari Moherani. And thanks for your attention.


Sophie Endaba, People abuse the words I love you. It's no secret that Sophie Endaba has been through the most over the past month. From being body shamed to fielding off death rumors, Sophie has managed to not let it get her down. Today I'm my own hashtag WCW. Love and understanding begins with yourself. You are in no position to love anyone if you don't understand its true meaning. People abuse the words I love you randomly say it to others. So, I love you Sophie Lickable because God taught you the true meaning of love. Sophie also shared a series of pictures with the inspirational post.


Hi, my name is David C Jones and my learning experience is how to MC your life I've MC'd all around the world done a variety of different events some of them amazing some of them not so amazing and What I want to do is work with you on figuring out what distills and makes a great MC And also how we can utilize that in our own life and our own interactions. See you there


Good day, fellow investors. This will be a very interesting video especially for Alaser Gold investors because it will explain in the first place why I bought Alaser back in May 2018 and why I sold recently. So it will give you good perspective. The company from an investment perspective has changed. It was a margin of safety value investment and now it's more of a growth exploration story. So I'll give you why I sold, why I bought in the first place and then my view on the company. I sold but I think it's still a good investment. It's just different from what I like to buy which is safety value and then let the upside to whatever happens. Let's start with the discussion. So I bought Alaser Gold for Canadian dollars to 25 in May. I didn't buy more in September which now I see was a mistake but I was happy with the position that I bought then in relation to my portfolio and research process that I'm still building the portfolio. However now the company is up 70% from when I bought it and we are at what 3.9, 3.7 to 3.9 Canadian dollars, 2.8 US dollars. So the positive upside leads me to taking a look. Okay, why did I buy it? Are those catalysts still in place? Is that value still in place? Or there is something different? Now as I said Alaser is still a good company, has potential but I am confident that with what I do I will find better risk reward investment opportunities. Perhaps not in the gold sector because I have analyzed more than 70 gold miners in the fall of last year and only two Alaser was one and the other gave me a good business investment. I don't want to bet on gold prices. I have better investments to protect me from inflation or whatever might happen in the future. So why did I buy Alaser Gold? Well, they were investing a lot of money, 700 million in the Sulfide project. They had almost 1 million ounces of gold stockpiled at a high grade, more than 3 grams per ton. So stockpiled investments of 700 million, just a 350 million note on that and the market cap was 400 million, 450 million dollars. So we had 1 million ounces of gold lying there, stockpiled already. So not to be explored, not risk, no little risk with or grade or or hardness so you don't get an Eldorado or Guyana Gold surprise because it was there. So there is always operating risk but little risk. The Sulfide project was a complex one so therefore this might be a reason why I didn't buy more in September but if it happened well I analyzed the present value of the company would be closer to 3.74 US dollars, things could go wrong. I gave a 15% chance for that and things could go wrong in Turkey, again a 15% and my fair value came to 2.7. Compared to the price back then of 1.8, it seemed like a bargain. My sum of parts value was 3 dollars for Coppler, the Sulfide project estimating the value from the estimated cash flows from the technical report, then the explorations of Kakma Tepe or however 0.15 cents I added on value. I didn't even add Aldrich as it wasn't so important then but it adds also value. Now I will add later, change my model and add value there. The project Gedeke Tepe 40 cents per share which was a 3.54 dollars in value. The stock price was 1.8 when I did the analysis. However I added a 70% probability okay we will reach the fair value which is still a possibility even higher now than back then. 15% gold prices go down operating issues as Coppler etc. 1.5 dollar value and 15% really terrible situation in Turkey, low gold prices and we go to zero. My value average of this was 2.7 and we are close now to that value as the stock is trading there. Now what changed? Well the CEO said the following at the last conference call. So it was a transformational year completion of the Sulfide plant construction and production startup. So they expect that they now have an asset base that they believe can sustain production of 300 to 400,000 ounces of gold per year. This is really an incredible transformation but from 300 to 400 is a big jump and as I know management especially in the gold mining sector they are always promising promising so I'm a little bit wary of this 400,000 ounces. So let me see the facts. I like to invest in certainty like the stockpiles there were and the investment in the Sulfide plant. I don't like to invest in exploration promises and that's why that's one reason why I sold. When I look deeper into the 400,000 ounces the first problem is the grade. The stockpiled grade the certainty is at 3.2 grams per ton of gold. However the reserves for the future production the average of all the reserves is 2.47 so now they are mining they are using 3.2 golds in the Sulfide plant but later it will go to 1.5 which means much much lower cash flows and that's also projected in their technical report with much lower cash flows after three four years of Sulfide production. Just a funny note a few years I've been following Alacer there was usually only one analyst on the conference calls and nobody really bothered for a Turkish miner now that the stock is up 70% now there are suddenly five analysts and the stock is hot that's how Wall Street works nobody wants to invest in the business they all want to invest in hot stocks that go up okay be careful with that when it comes to gold miners. Then the second thing is the Ardic expansion that they are found some new mineralized zones and they announced the 300k ounces of resources so they will add that. If they find something in the mineralized target that might add another 600k of ounces but they are still waiting for permits and we don't know what is there so I am not going to invest in exploration I want certainty so that's the reason why I sold but if they find the same that they find in the resource pitch shell they might really add 100k 200k ounces per year as that is oxide ore and they can use and they can change the previous oxide plant. In any case if things don't work out that great I don't see much more that 100 000 ounces added for a few years so I have added those cash flows to my model and my fair value for the miner goes from 3.5 to 4 dollars per share let's give it a 15% risk of 2 dollars in case of whatever might happen 15% of very low gold prices at one and the fair value it gets to 3.15 the price when I sold was 2.91 so not much really value investing margin of safety and that's why I sold however this does not mean that alexa is now a bad investment there are still a few catalysts that might push the stock price higher if they in 2019 pay 50 million in dividends that would be a yield of about 5% if the market rewards that and gives a 3% yield there you have an upside of what 50 70% if aardage shows good mineralization good reports as the latest drills were really really good and if that continues then you really might have a 300 400 k miner the ounce miner with their margins with their low cost production 200 million of free cash flows per year times 10 that's a 2 billion company so that's still 100 upside of course if gold prices go up that that's the third catalyst that might really push this higher and higher however exploration gold prices it's not what I invested which was margin of safety of the investment of the cash 100 million on the balance sheet with the market cap of 400 million plus the stockpile so just a different perspective I'm just a different investor I like to invest in the businesses I like to find value plus just to note they don't own everything so they own just 80% of the mining district they are finding these things and just 50% of what is here in the red circles and depending where the mineralization goes we will see if they get 80% of 100% depending on the area so conclusion I think that the value investing money has been made with aletzer so now it is more about exploration growth potential gold prices which is something that I think I can focus on businesses focus on value investment I sleep better at this price I'm happy to sometimes just take the money be happier with the bird in the hand than two birds in the bush so thank you for watching looking forward to comments and I'll see you in the next video


As Finance Chairman of the Republican Party, this lady is a real hard worker. I would like to add my welcome to all of you for coming here this evening, because without the help from people like you, we couldn't continue as a Republican Party of Florida. I'd like to say a special thanks to our General Chairman, Alec Cortellus, who worked very hard, along with many of you, on putting this event on and making it so very successful. I'm indeed privileged to introduce to you a great, great lady, but before I do that, I just have to say a very special thanks to the Finance President this country has ever had. We are very fortunate in Florida to have someone like this lady represent us in Washington. Without further ado, please welcome Senator Paula Hawkins. Thank you. Thank you very much. Mr. President, as you can tell from the wonderful response that you received from thousands of Floridians who gathered in the lobby of this beautiful hotel a few minutes ago, Florida is Reagan country and we're most proud to have you here. And I too would like to thank Jeannie and Alec and Jorge and Jeb and all of you who worked so hard and given so many hours and so many dollars to make a point that we need to make clear to Americans and especially to the people of Florida that Mr. President, Ronald Reagan, and Paula Hawkins, your senator, have a continuing agenda. There are some in this country who want to interrupt that agenda and we must not let them do it. Several elements in this country who want to stop the Reagan Revolution that was started in 1981. A Reagan Revolution that Americans across this great country are proud to claim as the turning point in a road that in 1980 was leading to ever higher and higher inflation, ever higher and higher unemployment, even higher and higher interest rates, and dropping ever lower and lower in national pride and patriotism. There are those who on any occasion whatsoever that they can conjure up to raise taxes on the American people. Mr. President, when I visited you in the Oval Office just eight days ago and you agreed that people in this country on social security and others on fixed income should receive a cost of living adjustment based on the inflation rate, I told you that everywhere I travel people talk about you and the great things you're doing for people and they talk about how important it is, how great the need is for you to be able to continue carrying out your agenda. Mr. President, we can do that and there will be no turning back. The word malaise can be removed from the dictionary and the United States of America will be etched in large bold banners in the hearts of free men throughout the world. The Reagan Revolution will continue. Your agenda will be carried out because you'll continue to have a Republican majority in the United States Senate to help you do that. Mr. President, this is your second visit to my great state of Florida on my behalf. Let me just speak for everyone in this room and Floridians everywhere. You're welcome here anytime you want to come. We appreciate everything you have done for Florida, for our children, for our families, for our neighborhoods, for freedom and yes, for peace forever. This is our continuing agenda. When the Senate considers its agenda next year, I want them to continue to work on the problems of preventing abuse of children. When the Senate works on foreign policy, I want them to continue to use that foreign policy to stop countries from shipping drugs into this country. When the Senate balances the budget, I want to be sure that it's not at the expense of people on social security. And when the Senate considers our energy needs, I want to be sure we're not drilling oil too close to Florida's beaches. And when the senators consider job training, I want them to help single mothers get the jobs they need to support their children. And when the Senate looks at health care, I want to help our elderly be cared for at home, not in an institution. Mr. President, I promise you I will always be battling, fighting, and working with you to continue our agenda. And I know that the people of Florida are going to make it happen and make your day. Ladies and gentlemen, the man who made so many wonderful things happen for all of us, President Ronald Reagan. Thank you. Thank you very much. Thank you and thank you, Paula. And, you know, I have to tell you because I understand that from the previous speech just a little while ago, it was piped into, if not all, most of you here. I feel like I'm in an instant replay. But I'll try not to say the same things twice, although I will say that it's great to be in Miami and great to be with so many old friends, veterans of hard fought campaigns and crusades. Political strategists think of Florida as a bellwether state. Well, you folks down here not only reflect national trends, you start them. I hope I can count on you to be in the forefront of a trend that will ensure that the United States Senate remains in Republican hands, and that means re-electing Senator Paula Hawkins. And if anybody can do it, you can. Florida's got top-quality party leaders like Genie Austin and Dali Cortellus and Jeb Bush bringing more and more Republicans into the fold. It seems like another lifetime when the South, including Florida, was considered a stronghold of the other party. There's a story about a candidate who was running for Congress in one of the southern states back in the 1960s, and he was out in the countryside campaigning, and when he told a farmer that he was a Republican, the old guy says, wait a minute till I get more. She's never seen a Republican. Well, he came back with Mao, and in the meantime, he was wondering, and then they told him that wouldn't he make them a political speech? Well, he looked around and needed kind of a podium, and the only thing there was a pile of stuff that had come out of the stable. So he stepped up on it and made a little short political speech, same thing I'll do as a short political speech. And afterward, the farmer and his wife told him that candidate this was the first time they'd ever heard a Republican speak. And he says, well, that's all right. That's the first time I ever spoke standing on a Democratic platform. Seriously, though, over the years, many articles have been written about a coming national realignment, and no one need wait any longer. It's here. Many Democrats are realizing that their party no longer represents those values and ideals in which they believe. That happened to me years ago. I was a New Deal Democrat from the very beginning, and I'll bet some of you were as well. And maybe there are some among you that you may not have gotten around to switching parties, but you sort of support the party that we now belong to. And when it comes to realignment, there's every reason to be optimistic. I say that because, and this may be true for you as well, I've been meeting a lot of Democrats recently who've become Republicans. I just met one who's running for office in Louisiana, and as of today he re-registered as a Republican. But you know, I haven't been meeting anybody who's going the other way. And if I could just tell you something that several years ago, an organization of political scientists were interested in what might be happening to the parties. This is really true, and they did a study, and they took the two national conventions, Republican and Democrat, first, and they surveyed those as the leaders of their two parties. That's why they were the delegates to the convention. And they surveyed them on the basis of a lot of major issues as to how they felt about those and what they would do about those issues. And they found, of course, that the Democrat and the Republican leadership, as by the delegates, was poles apart. Then they went out and did a survey nationwide of the rank-and-file members of the two parties. And to their surprise, they found that the Republican rank-and-file were identical in their views with their leadership. They found that the rank-and-file Democrats across the country were totally out of step with their leadership, and then they compared the poles of the rank-and-file members and found that the Democrat rank-and-filers were almost identical with the beliefs of the Republicans. So when you're talking to your friends, and some of them were still Democrat, you might point out that actually some of us that have changed already and a lot that should change is because we didn't leave the Democratic Party. It left us a long time ago. You know, Winston Churchill in the Parliament of England changed parties when he was a young man. And he said when people were looking a little aside at him about doing this, he said some men changed party for principle and some men changed principle for party. Well, that's what's happening today and that's why it's vital that we remain the party of principle, the party of a strong opportunity-filled America. Perhaps the most tangible reason for optimism is that young people are supporting our cause in numbers no one could ever have predicted a decade ago. As a matter of fact, when I first became a Republican and started attending some Republican meetings some years ago, I would go home to Nancy and say, you know, the only young people there looked like they couldn't join anything else. But not so today. I've been on the campuses of a number of universities. I've been in high schools very recently and talking to young people. I've seen these young people of ours in those places in shops and factories and on military bases and out on aircraft carriers. And I saw them at the rally when I came into the hotel. You were listening. I think this is one of the finest generations of young people this country has ever seen. They want the same things we wanted, a chance to live life to its fullest, to own a home, to have the opportunity to go as far as their talent and their hard work will take them. And when I remember back when I was governor and if I went near a campus in those days, they'd hang me in effigy or for real. But this, looking at these young people today, their patriotism, the spirit that they have, I'm convinced the 21st century is going to be in good hands. They sense that the reforms we've struggled to put in place, the efforts that we've made to invigorate our economy, and the commitment we've made to the security of our country are really for them, the young people of America, and their right. It's getting a bit hard to remember, but it wasn't that long ago. And this is when that other party was in control of both houses of Congress, the presidency, and all of the executive departments and agencies, that the so-called leaders of America were telling all of us, including young people, to lower our expectations. Do you remember? We were told that the problems plaguing our society were unsolvable. The refrain was heard that America's best days were behind us, and the picture of a bleak future was being painted. But America has left those bad old days, and the politicians who gave us those bad old days behind. And all I can say is, ain't it great? We may have every reason to be optimistic. Nevertheless, I hope that none of us will be complacent. This is especially true here in Florida. A tough race is coming up, yet I can't think of an individual who has done more for the cause in which we also firmly believe than your own senator, Paula Hawkins. Paula Hawkins is over at the White House the other day, and I told her she just simply had to be reelected. And I just added a few words to that in the lobby. Believe me, I could have gone on forever. As I mentioned out there, Paula is one of the hardest working individuals I've met in public office. She truly, truly is an inspiration to all of us. And while you're out working for Paula, please don't forget the other Republican candidates. You have some great individuals down here. Florida, for example, deserves a future-oriented Republican governor. I know that Craig Kaiser is running for state comptroller, and he is an inspiration to us all. We Republicans carry a special burden. We must keep faith with those young people I spoke about a moment ago. Instead of looking or lowering their expectations, we want them to dream great dreams. America's best days do lie ahead. By doing what we're doing, we're making certain of that. And if any of you here are of the other party and thinking of changing, don't wait and do it as I did.  But, and I campaigned for Republicans, and I did Republican fundraisers back when I was in that Hollywood world. But I hadn't gotten around to re-registering. And yet the Republicans began to take me for granted. And then one night I was making a speech at a Republican fundraiser, right out in the middle of the audience, a woman stood up. And she said, have you re-registered yet? And I said, no, but I'm going to. She said, I'm a registrar. Right down up here. And I signed up. Then I said, now, where was I? So, don't let up. Get with it and send this young lady back to Washington where we need her so bad. God bless you all.