VMware Tanzu Community Edition Community Meetings, 20 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Tanzu Community Edition - Community Meeting October 20, 2021

Description

Discussion Topics:
- Welcome
- Recap of last couple weeks
- Welcome back from KubeCon and All Things Open!
- Engineering Updates
- Opinionated Install progress
- Tanzu Local Discussion/Demo
- Thanks and signoff

A

Everyone welcome to our community meeting today is wednesday october 20th. This is our second public community meeting, we're still getting in the drill of everything. Here's how it works. uh We've got a hack, md page that I'm going to drop the link for in the chat, if you wouldn't mind putting your name and your company affiliation, there helps us know who's here, and then you can get a little preview of what our agenda is going to be today is not super intense we're going to do the welcome which we're doing right now.

A

Give you a little bit of recap of what's been going on, go through some engineering updates, and then we have a an item for discussion uh and a demo about tanzu local versus standalone clusters and then we'll thank you all and sign off. So uh starting with uh the recap of the last couple of weeks.

A

For those who weren't aware most of the team was in la for cubecon, we had a good office hours there, but yeah we've been doing a lot of traveling getting the word out about uh tons of community edition, hoping to get more people interested and involved in this community that we're starting here and then uh myself and one other person was at all things open this last week doing very much the same, so we're hoping to see some growth.

A

Some more use some helpful questions and interested folks getting their hands on with tons of community edition. With that, I want to pass it over to josh to go through any engineering updates.

B

Hi everybody, uh our engineering updates, are a little slim, as nigel put we were in. um Where were we last week we were in la for kubecon and uh we have set up our zero 10-0 milestone, which will be the next release for tce.

B

We keep the engineering detailed roadmap, which is a lot about like which issues we're going to burn down. What we're going to include inside of a pinned issue in our repo that you can check out I'll, also put a link to it in the chat here as well cool, um so just kind of as a high level. What we've started burning down since we've come back from kubecon.

B

We are primarily burning down a bunch of technical debt, as you can imagine, getting this project out had us uh had to strategically incur a lot of debt in various loose ends, so we're tying many of those up and we're largely trying to take feedback from y'all who are using tce fix. Some of those things fix major bugs we're aware of and kind of, prep ourselves frankly for the beginning of next year, when we start to really progress this project, even more.

B

So if you do want detailed on the slated issues, features that we have uh you know allocated feel free to check out these filters. It'll give you a list. If you have something that you've created an issue for, and we couldn't slate it for this release, it doesn't necessarily mean we don't want it. It just means that we don't have in our.

B

You know, team of four to five, the engineering capacity to do it, but we would love if you're interested having you help, contribute whether it be documentation, code changes, you know so on and so forth. um So please do make sure to let us know. If there's anything we can help. You help us move along at a very high level, um there's kind of three themes that we've got going on for this.

B

This um this release, one is going to be uh local cluster implementation and I'll talk a bit about that in a moment uh in a demo, we're gonna. Do we're also going to get some designs in place for how we're going to approach multi-package solutions. So the premise here is: we have a lot of really good primitives in place like you.

B

Can deploy contour and you can deploy cert manager and that's all awesome, but how do we actually start thinking about wiring these packages, together almost in like a higher order function where we can enable things like a platform that brings k-native serving and cert manager, provisioning and on and on and on together? So you do. You know one deployment and it wires these things together and gives you an experience, so we're not gonna implement that for zero. Ten zero, but we're gonna get some plans in place for what those higher order.

B

um Multi-Package solutions would look like and then we're gonna do some digging into air gaps. Some of you might be aware: you can technically do air gap today, but it basically involves a lot of like grepping and searching to figure out where the images are located, moving them and so on. um So we're going to get some plans in place for how we can make the ux around that a lot better, because we do know for both.

B

Just those doing you know local development, all the way to people deploying in their data centers um being able to deploy to a private registry or being able to like tar everything up and load it manually is definitely an important requirement and we want to make that process a little bit more seamless for our for our user base. uh So that's it and in future community meetings, we'll have you know better engineering updates because we'll actually be progressing on some of this stuff, but nigel that is about it from our side. Today.

A

Thanks so much, I appreciate that. um Did anybody have any questions specific to what was just discussed about the engineering roadmap and I've? uh I've put the info or the issue that josh linked into the hackmd file, uh so that you all can see that there for the engineering updates, but before we move on to the next thing, were there any questions specific to where we're heading with the 0.10 release or any other comments from other engineering. Folks that wanted to say anything.

C

um Hey this is karthik, not an engineer, but it was curious about kind of the multi-package uh solution that we were talking about. um Are there primitives in carvel that we will be leveraging to build a solution like that, or would that be something that would primarily be built with sort of in the tanzu in the tce world? And that's okay? If it's too early, we can we can park it. That's just curious, yeah.

B

It's it's a great question, so we will be using karvel to build these higher order packages. So you know one way and in fact you know one call out that I can give is we have a contribution in our docs from uh one of our? I don't know what jorge's role is anymore, so I'm not gonna guess at it, but uh one of our great contributors I'll call jorge that uh around building some of these higher order things. So, oh I'm not sharing my screen. I'm sorry give me a sec.

B

Here's my screen, so in our documentation under guides. There is uh something that kind of alludes to this premise, which is the idea of an opinionated installation package, and you know the the crux here is: how can we take those same primitives being carvel and the packaging apis and then wrap them around other packages to effectively?

B

You know make these again higher order functionalities available.

B

So the short answer to your question is yep it'll be still using the same karvel primitives and if you do want kind of a preview of what that approach might look like feel free to check out this guide. You can even make one of these. You know multi-package packages today, it's just uh quite a bit of work.

B

Hope that helps answer thanks.

A

Thank you for that question. uh Were there were there any other questions or comments on that before we move on to the next item,.

A

All right sounds good, uh all right, josh. uh Let's talk about standalone clusters and uh about uh tons of local.

B

Awesome um sorry, I was responding, something that scott said, so we will be looking at the new carnival apis too, so good call out. Okay, so one thing that we have actually uh done a proposal on and did a large amount of the implementation. Already we kind of got excited about this idea at kubecon and started hacking away at it.

B

um We are proposing a potential alternative to standalone clusters right now, we're calling it tanzu local, which is a really bad name, to be honest with you, because it kind of implies that we're like making a desktop solution or something like that- and that's that's actually out of the scope of what this proposal um talks about. But, as you know, naming is hard. The proposal will dig in and let me just put this in zoom chat before I forget.

B

The proposal will dig into kind of what we're thinking about here, which is largely that we've had the standalone cluster model for a while, and I think it's definitely scratched an itch that a lot of folks have. But I think, there's a couple things that we have learned in particular one is that standalone cluster users are almost always in our experience, using standalone clusters to bootstrap a single node or a local cluster.

B

So a vm somewhere or just you know something on their on their desktop, which is a very common use case, and that when users actually want to simulate more complex cluster life cycle stuff, they end up needing managed clusters anyways because they have to play with cluster api they're trying to do upgrades and machine health checks and in all the things that come with the more complex stuff and what we attempted to do to provide kind of a lower barrier to entry.

B

A way to really get tonzu and the package management stuff set up on a single node. A minimal environment is that we tried to reuse cluster api and tkg libraries inside of tanzu framework. To do this and overall it's been okay, but I think the experience, if we're being honest from the feedback we've gotten, is that one it's created a bit of a poor user experience around the single node use case. It's pretty heavy weight, there's lots of issues that can happen in the bootstrapping process and then for number two.

B

When you use a standalone cluster you're, pretty darn limited today, at least with life cycle management pieces. um Do you want to scale? Do you want to delete stuff? Do you want to put in health checks? All of that isn't wired up, and you end up with this cluster that you're going to end up deleting anyways, hey.

D

Josh, can I inject one quick thing sure which is for folks outside of vmware when we talk about we've had this for a while, we've been doing monthly releases inside the company since january, and we've actually had this to an internal audience since what april or may right yeah. So when we say we've gotten lots of input, we're talking about, you know from dozens to hundreds of internal users over five or six months, not the last two weeks, yeah thanks for that call out, I will say.

B

Though I think, we've gotten a lot of feedback from people with bootstrapping.

E

Issues in particular.

B

um That is that has really kind of validated that, but thanks for the call out for sure roger, it's definitely something that internally, we've had folks using folks are using it in their ci cd pipelines. So there has been data more than two weeks, which is definitely a good call out all right. So what are what are we talking about here and what are we proposing? um The the crux of what we're looking at here is to actually break down the architecture of tanzu to solve this single node use case in a more elegant way.

B

So for those who don't know when you spin up tanzu environments, you end up with a management cluster and that management cluster can create one or many workload clusters, there's a descriptor that talks about or describes how to create that workload cluster. We call this a tkr, tanzu, kubernetes release, so think about this containing things like what are the base images? I should use. What is the cap controller? I should use what are the package repositories cni's so and on that, so on that I should install in the cluster.

B

So if you think about that idea, where the management cluster pulls in and parses the tkr and then creates a workload cluster, if we could do the tkr processing client side and then using a cube config that gives us api access to an arbitrary cluster. We could then understand the tkr's declaration and make that happen in a piece of infrastructure. That's provisioned!

B

We can spin up this single node use case in a really really simple, clean way. That's easy to create, delete and use. So this proposal will have some gifs and things that kind of show what the workflow looks like. I won't dig into to all of the pieces here, but I will just quickly kind of show a demo of of what it looks like, and this is something that um we'll have instructions in the pr for how to build locally.

B

If you want to try it out so right now I have a cluster stood up um and again it's just called local until we figure out a better name, but if I type in tanzu local ls, I can see. I have a misspelled cluster here, which is the hello cluster running in the bottom. I can do tanzhu local delete all right and then put in hello, and this will go ahead and delete the cluster so similar to an experience you have with something like kind.

B

What we've gone ahead and did is for the first provider implementation we just plugged kind in because it's really easy to use. It's community supported all that jazz, um but it's pluggable in any way. uh What be it something with vmware fusion, be it uh cluster api? Actually, you could plug into the back end of this there's a lot of options, but at some point, you'll get to a juncture where you want to create a cluster. So, let's create a correctly spelled cluster here. Tanzu local create hello.

B

So what this does out of the gate when I hit enter, is it's processing a tons of kubernetes release, which, again, you can think of like a bill of materials that actually goes in and tells us how the cluster should be bootstrapped? It's then selecting what the base image should be. What the cap controller configuration should be.

B

What package repository should be installed and it even gives us an output as it's creating if we want to kind of follow along with what's going on in the cluster, so I'll set up a watch down here, and I will point it at the right manifest and we'll just kind of watch the paint dry here and I'll talk about it a bit. So if you kind of think about the breakdown of spinning up one of these clusters, really the crux is creating a cluster and that's a bit of an opaque box. For us.

B

We just make the cluster something happens and we get a cube config back. That tells us how to talk to the api server. So we abstract ourselves away from that piece. Right now kind is being called under the hood to create the cluster, and it will give us a cube config back now. What tonzo then does is it looks to have the kind of, um dare I call it like the process initiator or the kernel kind of setup, which for us is cap controller.

B

So now it's installing cap controller- and you can see down here in the bottom that it's giving us some progress, updates around cap controller's install and you can see cap controllers, creating cap controller, actually gets set up in tanzu clusters as something that sits on the host network. It's it's like a very privileged process.

B

If you will from a networking standpoint, because it's actually responsible for instantiating lower level components like the cni, so the great thing about tons of architecture is that, since everything is a package, once we get cap controller up running and healthy, we can jump and install any arbitrary package into the cluster. So right now we're installing the core package repo, which has cni's like antraya csis, like the vsphere, integrations for storage, provisioning, all that jazz and once the core package repository gets reconciled.

B

Here we will take the final step which will be to choose whatever cni package you wanted to use and install that into the cluster as well.

B

So once this gets done, reconciling which it has done that now it has now created the cluster it'll. Give me some commands that I can run right here. So as an example, if I just grab the first one, we can do a tonzu package available list and we'll just list all packages that are available.

B

You'll notice, it automatically set my cubeconfig context too. So all the packages are running in the cluster. In my kind cluster they're all set up, I can view them install them. I'll, eventually have a tce package repository bringing extra software on too. So if we do package repository list here, you can see here that by default it installed- hopefully the community repository and the core repositories- those contain a bunch of packages, and then we can use cube cuddle for all the operations that we expect.

B

So this would be cube, cuddle get pods and you can see andrea's being initiated from cap controller and a bunch of other components. So in summary, uh hopefully this demo helped give a little bit of context. There's a couple things that we're hoping for with this local cluster model. One is that it significantly lowers the barrier of entry for getting a ton zoo.

B

Cluster running cappy is amazing: we're not competing with cappy it's just when you want to spin up a single static instance on a node and you're, not worried about intense cluster life cycle management like making this a really long running cluster. This is going to be a model. That's going to get you there likely in a couple minutes. It's also going to be a really easy thing to iterate on so those of you who are doing like package development.

B

I know some of the community has been doing that this bootstraps the environment entirely to look like a tonzu cluster. So as you develop packages you can bring them in, you can install them. You can swap out versions of cap controller. You can screw it with versions of the core dependencies and then, when all is said and done and you're kind of over it, you can find out what clusters you're running and then it takes rather than currently 10 minutes to delete a cluster.

B

You just run tanzu local, delete, hello and your cluster's gone and no longer existent.

B

So that's it I'd, be happy to take questions and uh yeah. Hopefully that was helpful understanding kind of what we're what we're driving at here.

A

Yeah, it does seem significantly more lightweight and faster than what uh the experience was with standalone clusters. Does anybody have any questions that they wanted to ask josh about this new development go ahead, chris.

F

Hey guys, um the beginning of the proposal discusses the need, eliminating the need for a long running management cluster. I'm just parsing this carefully. Does that mean we're spinning up a temporary management cluster to accomplish this.

B

We used to do that and largely this proposal no longer does that so effectively the need for a management cluster when using this model is nil.

F

So, there's a lot of really interesting new things that are we're bringing to the community here with this set of tools, and I'm wondering, if we're compromising all those unique things in order to do something that is easily doable once you get a cube, cuddle file and a local cluster running.

F

um What is it we're missing about what we're innovating on this platform here? If we focus on local clusters, is there.

B

A risk, so I think that what it comes down to is really understanding the users and their desires, I'm under the impression, although I could be wrong that folks, that want to spin up an environment where they can use the tonzu toolset shouldn't have to set up a bootstrap cluster to then set up a management cluster to then set up a workload cluster so that they can start their work. This will be something that the persona of an application developer or a package developer or people looking to plug tanzu into ci cd pipelines.

B

To do validation are going to have a way to stamp out a minimally viable tanzu cluster.

B

Now, when folks do have the need to actually go out and build clusters out in their data center, you would never use this model for that. In that case, you would instantiate management clusters, as you do today, and you would start bootstrapping everything through those management clusters.

F

And it sounds like there's really no concern um for reducing the exposure to the capabilities that the platform provides to this method.

B

I think that you scope the if you scope the target user, then I am not concerned. If you want to take this model and say: oh hey like instead of running a management cluster in your data center, have you considered this local model? That would be deeply problematic for both customers and users, we're giving up.

D

um You know we're giving up standalone on other provi on data on uh data center providers, basically um other than in our test suites. I have heard really nobody who has wanted to do. You know standalone clusters in uh you know aws, vsphere, etc.

D

So here um I was going to say the other thing, putting the two the two communications today together, I wasn't really going to do an update, but but maybe I'll do a very a one sentence, one that will help make the rest of my point we're um starting to have the real hardcore discussions about um which developer components which stuff from tanzu application platform um is going to come into tce when and I think, being able to deliver like one quick experience. That is all of this.

D

You know what you've seen here and the tap install as as a you know. Basically, a push button is going to be a hell of an option.

A

Yeah uh josh: do you want to take this question here? What sort of resource requirements do we have for the local install.

B

Yeah thanks for asking jesse it's. We don't have hard data yet, but I can say that in its current state uh you know with a gig of ram and very minimal processing, you can get a single node cluster up. It will scale out based on the number of nodes you want to bootstrap with the cluster.

B

So if, if I were to kind of be a bit hand-wavy and compare the standalone model to this model, I'd say resource has been reduced to about 20 what it used to require.

A

Thank you, josh um we've got about four minutes left. Did anybody have any other questions specific to this and we can continue the discussion in the slack channel. I know there's already a thread and we've got the issue linked in the hackmd as well.

B

Nigel, maybe one quick data point um so one of the great things about working in the open and you all being this awesome community with us is. This is truly a proposal and a proof of concept. It's something we might not do at all, uh just to make sure we're clear it might sound like. Oh, this is the future. This is what we're doing we're pretty excited about it. We think it really fills a gap, but we might not do it at all so check out the proposal.

B

We'll have some instructions coming soon about how you could build locally if you want to get that in the weeds and try it out, but if it's something you're in support of, let us know in the proposal, if it's something you think, is the wrong direction. It's totally fine to have that opinion um and do feel free to communicate that, because we want to really take your feedback in as we as we think this through.

A

And we're definitely going to be moving to a model later on, where we're looking at what we're prioritizing in the road map and presenting that to y'all to to give us some input and figure out how we as a community, want to shape uh tce yeah. While we've got uh another couple minutes, um let's see uh jeremy, you want to go ahead with your question.

E

uh That's fine, I I can just do it in the slack channel. I it it's probably a lengthy question. If you only got a few minutes left so, okay, yeah.

A

um So we started having these meetings as 30 minutes, because we feel like the default is always an hour and often it runs a bit too long and it seems like we do we. This feels like an appropriate time, but it's open for debate.

A

uh If we want to do this more often and then for the folks that are unaware, we have a model of doing our community calendar and that the first and third weeks of the month are our community meetings where we have an agenda and we kind of want to update you all and then the second and fourth weeks are the office hours where we don't have anything particularly planned, usually and it's more of an open forum for folks to come in and ask questions uh scott. I see your hand.

G

Yeah just one question, which is I the difference between pc and pkg today in tce the package repository for things like prometheus grafanal that is not added by default into the cluster. It's in tkg, where it is, I'm wondering if there's a reason that that package repository isn't added in automatically and that kind of falls into what roger was mentioning around tap and the easy installation, and things like that down the road into kenzu local.

G

Having those package repositories installed automatically even at the packages themselves, would make the experience better. I'm just wondering if there's a reason that was done different here, yeah.

B

There is a reason: it's not a great one, uh so when the plumbing initially was put together in actually that same bomb thing that I was talking about earlier, the bill of materials we initially built out a model where we auto installed the standard repository, which is what you're seeing in tkg but didn't necessarily make it pluggable for alternative package repositories, so that was kind of our bad on a lower level, um actually ivan who's on the call right now.

B

He I and some others are working on a new api for how we declare this tkr-esque thing so scott. We absolutely agree the tce repo needs to go in by default. Once we do some updating and some of our plumbing, it will be there by default. So just just uh just a lower level detail that we had to kind of work around for the time being.

D

Well, it was awesome yeah, it was, and it was really entirely time time. It was a confluence of strange bad timing, kind of things um we wanted to have it right, but um the only thing we were able to do in time was to have it be less wrong than what came right before it.

A

Well, uh thank you all so much for the great questions and the good discussions. uh If there's more, please you're very welcome to continue this in the slack. I know we had a couple hundred viewers uh of the video afterward on youtube.

A

So if you're one of those folks, uh please feel free to drop any questions in the comments and also uh direct conversations to the to the slack channel and as we see that, there's more need for more time zones that we're not serving as these like asynchronous video views, take up we'll figure out how we can better serve more than just a few time zones. Thank you all so much for being here for this community meeting. We appreciate you we'll see you next time take care bye,.