VMware Cartographer Office Hours, 10 Jan 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Cartographer Office Hours - Jan 10th, 2022

Description

00:00 Intro
01:24 CRD change proposal
31:28 RFC 017 Workload conventions (Convention service)

The purpose of this meeting is to discuss architecture-changing ideas (in the form of RFCs) and provide in-depth support to the community of Cartographer contributors.
You can continue the conversation by adding comments to the RFCs PR: https://github.com/vmware-tanzu/cartographer/labels/rfc

Agenda: https://docs.google.com/document/d/1ImIh7qBrOLOvGMCzY6AURhE-a68IE9_EbCf0g5s18vc/edit?usp=sharing

A

B

Hello, everyone and welcome to the first 2022 uh of the tower session for cryptographer.

B

uh We really appreciate that you're joining us live or watching the recording, especially with all the difficult circumstances, we're living in the world again right now.

B

Okay, so remember that the goal of the office hours space is to discuss potential improvement, ideas for the project in the form of rfcs and also in general, questions that you may have for the maintainers team.

B

So let me share my screen.

B

Let's see the agenda there, you go uh okay, first of all who like to take notes today.

B

C

I can take notes.

B

Thank you. Emily.

B

That's definitely helpful.

B

Okay, we see a fur discussion topic regardless here the change proposal. I don't know who's this from that is me.

D

D

We just we just had a conversation with folks looking to create a gui for uh for supply chains, and I think one of the pain points that is looming for them is how to know that a deliverable on one cluster relates to a workload on another cluster and that's driven primarily because the.

D

The field that specifies that right now is kind of ad hoc. If you look at the example get writers that we have they leverage parameters on the workload spec rather than a dedicated field, and if we want to make it easy for yeah, if we want to make it really declarative and really easy to say, like oh here's, the field on the workload and here's the field on a deliverable and they match, and so these two uh are a pair.

D

uh We should make that uh that config destination field, uh a top level, spec location in the workload, uh and I suppose that means that we would also need that for deliverable, because deliverables could do verification and then promote to another environment.

E

I think the only thing that I can think of that might be a problem is that configuration isn't always specified by the workload right.

E

It could be specified in the supply chain where, like eventually, you might just want to configure like an org in the supply chain, where things might end up or a mono repo or something were, and then the supply chain itself um might dump your config into just a known bucket within that org or within that repo, and so there might not be like so there might be an implicit one-to-one mapping between like a workload and where that config ends up, but it might not be known uh in the workload configuration so like do you know what I mean.

D

I do um I think that I I think that goes back to the challenge, for anybody. That's trying to create a layer on top that that that that gui tool would have to crawl the supply chain.

D

Read every template, determine which template is writing configuration and then determine how that configuration is uh like what fields that configuration is relying upon in order to relate workloads and deliverables, and I think it would be a much better pattern for us to say like yeah, if you, if you have an org, wide mono repo kind of special, you have to specify that in the workload like that, that's something that your that your organization will have to be comfortable sharing.

A

Yeah, so I want to echo the concerns josh raised that a workload specifically the developer authoring. The workload might not know this information and to make it that a stronger statement and say the workload should not know this. Information like this is fundamental to the inversion of control patterns between developers and operators where a developer is defining the workload resource and saying here's my workload that I'm putting forward and like this is my source code like this is how it should get built, uh which is completely different than an operator's concern of.

A

Where do we take this config and how do we deploy it?.

A

B

That's exactly the case.

A

Of like the monorevo like that is even more a case where, like the developers on individual workloads, should not be setting that because, like those values, will change depending on environments so, like you, could imagine a developer iterating on a workload as part of their development day-to-day where they don't want it being pushed into a monorepo, because it's not ready for that. It's only once they've done their work and then it's ready to get promoted into a new environment and then that tar that value is going to change.

A

So if that value exists in the workload resource, then the workload isn't portable across environments.

C

Is there a do you have a solutions, kind of how we can tie the workload and deliverable together.

A

uh I had a conversation with ciro about this before the holiday, um but effectively like there kind of needs to be something between, and I haven't fought this through fully so like. Forgive me if this is look off, and I fumble a little bit um but sort of the core essence of the idea was the same way that supply chains have selectors that select workloads to be processed.

A

You could have the config writers kind of do the same thing so that a config writer could pull in multiple workload, definitions and basically say okay. I want to take all these and then write something for them into some other location, so it could be like you could have something that says. Okay, I want to match like a very specific subset of workloads.

A

Let me just say I want to have something that takes all the workloads in a namespace and then does something with that. Config.

E

I was thinking something that, like might be a little simpler along those lines right because like if we think about the config writer itself, like it's gonna, write to a location and it's gonna write a commit right that actually that output actually conforms to our existing uh source, template right and so like all, even though a workload might not know explicitly like where it's config is going to end up it in its status.

E

Once we start talking about like artifacts and stuff, it could ultimately end up with an artifact that points to that exact, commit at that exact repo and so like once you once you once. We have a tool that can parse what the artifacts in the status of workload look like. We could, in theory, you know, match up outputs to something in a deliverable. That's an input.

D

D

If you know the.

D

Well, I guess I guess one one thing that we could do is have a template type for that config writer and then say like every.

D

We assume that a supply chain that is trying to write to that is trying to promote is going to use that promotion, template and then that promotion template exposes some value on it, then that, then, that artifact would be reflected on the workload.

E

But isn't the promotion template the same as a source template.

E

And it like, the only difference is.

D

E

No well whoa. What would the interface for a promotion? Oh.

D

Would it be oh, would it uh play back up? Yes, you could use a source template to do that, uh the challenge being that uh from the from a gui from a gui's perspective.

D

How does it know that it should be referencing uh like which uh which source template should it be uh leveraging to pair up workloads and deliverables?

D

So if we specify there's one promotion, template like you can use zero or one promotion templates in a supply chain, then it's very clear. uh This uh yeah, the output of the promotion template, is the uh the key.

E

But if our visualization tool like at the end of the our visualization tool, may only may not need to look at that information right, because if we are actually building out a tree of artifacts in the workload itself right, you could parse that tree and you could follow all the you know. uh This commit produced this image produced blah blah blah produce blah and that, if you built out that tree right, you could see that at the end of that tree, you have an artifact that ended up as a source and then, if you're.

E

If so, then my tool. If I'm looking at a workload and a deliverable, I can see that these two things match.

D

Like could you build a.

E

D

uh Could you build in conventions uh that would allow you to associate them? Yes, uh they sound like they're, getting a little bit fragile, like you're, just like hey. If there's a source template at the end of your supply chain, then uh you should always assume that that is uh that's a config config written to a rebar registry um yeah. We could. We could say that that is a convention that all tools that use cartographer that all supply chain authors must follow.

D

But that seems like.

E

A more fragile small distinction.

E

Just a small distinction, what I'm saying right all I'm saying is that, like I I could. I totally agree that maybe you're right like maybe this doesn't need its own template type to be more explicit and stuff. But technically all I'm saying is that all we would need to do in that case. Is we wouldn't need to know that it's a source template? All we would need to know is that the final artifact in a workload's artifact graph matches the first artifact in a deliverables, artifact graph.

E

And, like the distinction to me, is like the workload doesn't know about like in in so based on rfc, 14 or whatever right it. It's not. It doesn't really know about template types and stuff. All it really knows about is artifacts and so like from the workloads perspective. If we had a promotion template whose interface looked a lot like a source template, it probably wouldn't matter based on that graph, because the the interface for that artifact would be a revision and a url, and you know whatever else is in there.

E

That that's that's all I'm saying but like if, if we wanted to get into the business of interpreting a supply chain and like understanding, you know how templates and how like a promotion, template can lead to. You know other clusters and stuff like that, then I fully agree that we might want a custom template type for this.

D

um I think the so one I I think you're right, like you could just opportunistically, say: here's the last uh here's the last artifact uh in workload and it matches the first artifact in this deliverable. um uh It does necessitate telling people, I don't use a config or don't use a bear. Bear template as we do now, like all of our config writers, are just the templates that don't output any value.

D

I think that could be a it's, certainly a a first step that we could. We could take to the you know we could make that change um and have our examples, be source uh use, source templates at the end and then see and then look for feedback from consumers of cartographer and gui writers and see what they think.

C

Is it a little strange that we would be changing examples and, if we're not using like a third-party tool like the visualizer, that it wouldn't make sense why we are using a different template.

D

E

Are you saying like? Is this an argument for like for using a source template or using a promotion template.

C

I'm just saying it seems a little confusing to just change the templates in our examples, without like there being a reason for it right. The reason is because of a third-party tool, not because of anything cartographer needs it for.

D

That's true, I think part of my uh part of my statement is. I think this is the the multi-cluster story for uh an application platform seems pretty robust, and this is a problem that I think any uh any team that wanted to leverage cartographer as part of that platform would have to figure out.

D

It's like how do I relate the workloads to the deliverables.

E

And the way I see it too is kind of like technically the get writer like they're you're right. It doesn't necessarily need to be wrapped in another template, but for, but if I think about the supply chain, it seems more correct to say, like the the last thing in a supply chain is like an output is an artifact right, it's like, even though we don't have it like necessarily anything consuming it directly. um It seems like that last thing, being an artifact makes sense.

D

I also wanted to point out that there's a bit of a mismatch in terms of how source templates are used currently because the artifact is the shaw, but for workload deliverable we wouldn't want that. The deliverable is going, isn't going to know about the shot. It's going to know about some branch and then it's it's first git source template is going to be responsible for turning that branch into a particular shot at a particular url.

E

Yes, technically.

D

The it's it's all right.

E

D

So so yeah like.

D

I wanna have to be careful writing the template to expose the branch rather than expose the commit.

E

Well, I think the thing there right, even though, if we think of the deliverable, doesn't reference the shaw directly like the the things that operate under the hood on that deliverable are going to have an output. That knows exactly about that specific commit, and the thing that we want to trace is that specific commit right like we actually want to be able to? Because because the thing that we want to tie is we want to say, hey this source code commit produced. This config commit produced this running thing somewhere right and so you're right.

E

There might be an abstraction where the the deliverable talks about you know to track this branch, but we actually want to be able to trace the underlying artifact that gets produced along the way so like. Maybe maybe we skip the like what, if we're, building out that graph right, like maybe the deliverable, isn't actually part of that graph, and we just map the the commit artifact from the config to the first thing, like the first, like git repository in the the next delivery chain, or something like that.

D

uh I can see a use case for that. It seems a bit limiting, but presumably you know you can. The users can make that choice.

E

Yeah, like yeah so you're, saying, like a delivery, could point to a specific commit. Is that what you're saying because, like the user, can make that choice or what user? What choice are you saying the user can make.

D

I mean I I, as a user, would want to have some visualization of here's, here's the workload and here's the the deliverable in the in the staging cluster and here's the deliverable in the production cluster. Now I just want to be able to to visualize here's where things are all the way through, and I wouldn't want that visualization to break at the moment that the get writer made some commit and the gui tool suddenly was like well, there's no deliverable that has that commit shaw.

D

So I don't know where, like so, I don't know what's going on um and then suddenly, when the deliverable picks up that next, uh that next change on that branch, and so it's like. Oh.

B

D

I'm now I'm reporting this artifact, then suddenly the visualization like becomes whole again.

E

Right because, like the the deliverable itself, is actually like a stream of versions, it represents like a stream of versions right and what we need to visualize is actually like one line of versions throughout the system.

E

So it's like the workload represents a stream of versions. The deliverable represents a stream of versions, and there could be like multiple commits that we need to associate back to like both those underlying concepts.

E

So we need to be able.

B

To see two things.

E

Right, we need to be able to associate a source, commit ties back to a config commit and we need to be able to associate those both those version streams back to their underlying uh like workload and deliverable.

D

Yeah, it just seems like it's. The logic is much simpler to say, uh yeah. This writer is committing to this branch, and this reader is reading from that branch. Rather than doing some logic of this writer has made five commits of this sha to this repository, and this reader has picked up five of those shaws, and so they must be related and like, let's, let's keep them uh keep them related, um but.

E

But I think either.

D

E

I don't, I think we need a direct mapping right. We need a direct line from like this source commit produce. This config commit produced like this revision and a k-native service, or whatever the endpoint thing that we want to show is it's like. We can't just say, like we can't just say, they're associated through this branch by some mechanism, we have, to like point specific, commits that map to specific things.

D

uh Yeah, I don't think the other approach precludes that, um but.

E

Okay, sorry, I kind of don't think I follow your point anymore. If so,.

D

You, and maybe it does quickly, uh you would, I guess, if you, if you were only exposing to the gui, the uh the branch that you're committing to and maybe the sub path that you're committing to.

D

Yeah back up uh here's the question should: should we retain the.

D

Okay or to put in a parking lot a question: should we retain the bear, the bear template any longer? Should there should there be the option to do work? That is not uh reported that that doesn't have some artifact reported back to the cluster.

D

um Sorry reported back to the workload that would result in some change in status on the workload, um not necessarily a question. We need to answer right now.

E

I um we'll always need to keep it, for you know, folks that want to do like for interlude use cases right where a supply chain.

E

I say that sorry, maybe not I don't know, you're right, open question.

D

um To look back really really quickly, I I, I think that the model you're suggesting where you report, here's the here's, the.

D

The url and the sha, where the commit has been made, uh I does that, does that necessitate that once the deliverable has uh picked up, one of those shahs has read one of those shaws, then that delivery is associated with that workload. Forevermore um yeah.

E

So she did by who.

D

E

D

E

E

Is it concretely associated no, but can it be associated? I would argue yes.

D

D

Yeah not concretely, obviously we're talking about like other tools that are going to be layered on top of so I'm trying to think out like what is the? uh What logical assumptions can those tools be programmed to make.

D

So, okay separate question: uh when we were talking about the monorepo, I presumably you would have commits to one repository. You could have them on the same branch, but in different file paths in that branch.

D

um How would we can we use the source template to associate in that case.

E

I I don't think, there's any difference, I'm just going off the top of my head here, um because that's an interesting question but, like I don't think, there's any difference right, because all we're saying is it's a snapshot of the files under this massive thing, like there's other tools down the line that might implicitly rely on uh subpath, but I think that the the commit still holds right.

E

It still gives us the proper version of the the underlying files that we want, that we care about.

D

You would mike my concern is that you would get a situation where, let's say you have two teams that commit to the same rebound for their get their get ups between supply chain and deliverable.

D

uh I think we would have to preclude using subpads for that, because you would say uh uh team. A uh you know commits to the team. A directory team b commits to the team b directory. uh The deliverable for both of their teams would pick up uh every commit from team a and team b, and it would only be the next step in the in the process that would disambiguate those different directories.

E

Oh, I think that's flux's job is to like differentiate where, like uh things have changed for this path right, so I think, like I'm, not sure if I.

B

Don't think flux.

E

Supports, but I think they should right like in this model, if we're talking about this model, I think they they should kind of thing right. Like I mean it's.

A

I mean the the general model is that you have the bundle or sorry you have the tarball that represents whatever the flux resource is pointing at and then, if you choose to only care about a sub path within that, then that's your business.

A

So then, so like, for example, the way it works between yeah.

B

A

Like flux and something like kpac today like if you do want to support, if you will use the the sub path field that exists on the workload flex, will fall all of the source code for whatever commit that you're pointing at and then that bundle reference gets passed, tk back and then the sub path reference from the work that also gets passed to k back and then cape back goes okay. I know to do a sub path within this tarball, but it's not flux, crediting the filter.

E

And so then, under that model, what should was right in that both of those things will trigger downstream resources, but it's up to those downstream resources to determine that. This is a no op for me, because nothing changed which yeah, I think, that's fair.

D

Yeah so just like tell people don't use that pattern, get get supports, branches, use, branches.

D

E

Anyway, we can move on yeah.

B

Sorry yeah. This looks like a really interesting conversation, so at this point we should move it to an asynchronous format, so I was wondering if this one should apply to become a new rfc, at least a draft rfc. I don't know.

B

uh I don't think we.

D

uh What we've just been talking about, I don't think we'd need an rfc, because we've landed on a solution. That's totally possible with our current uh yeah, we'll just be switching the template in some examples.

E

Yeah, it does suppose we have rfc 14 finalized though, um but yeah, I don't think we need a net for this yeah.

B

That's great, thank you, okay um time to move the next item from this cod workload. Conventions.

A

This is mostly an fii for people, uh but last week I opened an rfc tentatively claimed 0017, that is talks about adding workload conventions to cartographer.

A

So this is a capability that we have within the tonsil application platform that we're looking to contribute to photographer at its core. Basically, what this component is doing is providing a higher level of choreography, specifically around the content and the shape of the template, spec that is sort of being contributed to via the source code referenced by the workload and the images that gets built before it gets delivered.

A

So you can do things like detecting that a workload is a spring boot app and then making changes to the pod temple spec that are specifically enabling spring boot capabilities.

A

One of the reasons why we developed this capability is that we've identified sort of a gap that most developers and specifically the workload resource, doesn't expose a lot of the knobs that are necessary in order to actually have a workload at runtime be well behaved this. This can be things like defining liveness and readiness probes that trigger over an http endpoint, as opposed to just watching whether the process is alive or not inside the container.

A

But when you do that, you need to have more specific knowledge about what the runtime process is inside of the container, because you can't just make an arbitrary request. You need to know like what path should I make the request to in order for to have the workload actually participate in the sort of the liveness which, basically just am I up or do I need to be restarted uh versus the readiness aspect is like? Am I able to receive new requests, or so do you send traffic to me?

A

So it's in order to kind of distinguish those aspects you kind of have to have workload knowledge. So this is something that can kind of provide that glue by providing new extension points that other people can hook into.

A

That's like the oral in summary, but if people read this and put questions on the pr we can sort of have the conversation there or people have questions here. I can start to answer.

C

Is there uh more work that needs to be done for the convention service.

A

So it's a feature that we're shipping, um so the work would be in order to actually make a contribution to cartographer, um but like the core capabilities exist and are functional today,.

C

A

C

I guess roadmap.

A

C

A

uh We don't have a publicly facing roadmap right now, uh because it's an internal component at the moment, so this is a proposal to open source it into cryptographer, um but certainly we have ideas of ways that we can sort of, enhance it going forward, uh but like the core essence of it, that is uh established at least as it currently exists like. If there's, if there's ideas and like how to improve it, then we can certainly address figure out how to address those going forward.

E

um Is there like a plan for people working on this to continue working on this.

A

Vmware will staff it so whatever that means uh internally. I can't really comment beyond that.

C

Yeah, I see an unresolved question at the bottom is like: does this belong in the cartographer repo or a separate repo, and I think all of my concerns come out of that question.

C

So how like you just want async conversation on this or.

A

Whatever is easier for people, so I mean, if sync is better, I can talk sync if async is better, then that's great.

D

I think uh related to that, I wonder, would the cartographer like with with these office hours, would we have office hours for convention service that are separate from cartographer, or would we be merging all that like? Are we saying like.

D

There's enough bandwidth in the cartographer community to discuss core cartographer as well as any changes that convention service might want to iterate on.

A

I would presume that there would be enough bandwidth in this call, especially if it is going to be a component of cryptographer. If it's not a part of this call, in other words, not really integrated, then it doesn't make sense necessarily to go through the rfc in the contribution process. It would just be a separate open source project.

D

D

When you say integrated, um I assume that my assumption was that they would always be separate controllers and the cartographer would be writing. Convention service objects that a separate controller would uh would then manage.

A

Yeah, I would fold that under that first unresolved question about whether that's a design goal or not.

D

A

D

A

I could imagine a world where we basically say this is two new crds. It's just another reconciler inside the existing controller.

A

Today, it exists as a separate process so with a separate distribution so like that is also an option depending on just sort of what the desires are for the photographer community.

E

Do you do you have opinions on some of these unresolved questions, scott or they just like.

A

You know that's partially, why they're unresolved.

A

Like I, I do think that this is a capability that is a gap in cartographer if something isn't plugging it, um just because there's a lot that the workload resource doesn't expose intentionally.

A

That needs to end up in a running workload in order for that workload to be well behaved on kubernetes um in terms of like, is this like core cartographer? Is this a sub component of cartographer sub project like I.

A

I mean I I haven't see ever everything I've seen so far is basically a cartographer is a single repo, um so like as long as that was true, I would imagine we would try to fold into that model uh if there is a reason why that model doesn't work and like or it's like it's about to evolve to not be that- and this is like an impedance to like go. Do that other new thing that you wanted to do anyway, then I think that could make sense.

A

So I guess my opinion is absent. Any other reason not to I would tend to lean towards saying just put it into the same repo and like integrate actually make it part of the photographer code, codebase as it is.

E

So the goal is to.

A

E

It feel integrated and it just fit with whatever we're doing for everything else.

A

Yeah, I definitely don't want it to be a bolt-on like that's just absolutely not the intent.

C

I guess if it's, if, if it, if it's integrated to me, that means that this team is now the one staffing it so like, and we will be pushing one release and that sort of those sort of things like I don't think we would want to. You know: vmware teams working out of the same repository.

A

Yeah I mean how it gets staffed is definitely at that level. As a question above my favorite, I'm just saying, I think that makes.

C

A difference to us from the perspective of.

A

From the community perspective like, if it's one project like there will always be at least hopefully there will be external contributors who aren't employed by vmware who exist on different teams.

A

So how that dynamic works is something I think we can figure out.

E

Cool! um What what next steps you expecting on this gut? uh Just like start a conversation, yeah.

A

Great question uh definitely just wanted to raise it as it exists.

A

uh If you didn't get the notification that I created the pr um reading through the rfc process, doc, um there's a few things that are a little ambiguous in terms of how draft prs get merged like the the actual doc talks about just pushing to the main branch which I don't have rights to, um so how the draft final conversion process happens if we can figure that out, um but definitely interested in kind of getting feedback from the community at large and figure out like one is this something interesting?

A

Is this an actual problem space that people agree is a potential problem space, that's worth solving um and then how to actually go forward with it like, as I said earlier, like we have an implementation, we have design docs. These things are currently internal, um but we can work to make more of that information public as this process moves on.

A

But also definitely not looking to just dump it. uh This is something that, like I, definitely want to be involved in making it uh the right fit for photographer.

D

Yeah, I think um I I've uh sort of mirrored some of my thoughts that I've shared with you before um to me. The convention service, like in terms of like, is this uh worthwhile effort. I'm like yes, I I think that uh you know you're what I've read from you and talked with you like you, you've, definitely laid out. Here's why this is a gap that needs to be filled, but for me it goes back to the question of.

D

Is this the choreographer or is this the choreographed and the convention service to me seems very similar to k-pac, where, if k-pac didn't exist, you'd be like oh, like it'd, be really useful to have some controller. That's like out there turning source code into images and at the same time is saying, like that's a great idea. um Cartographer is like separating itself and saying uh we are.

D

We are this. You know we're the choreographer and up until this point, that has meant that we don't uh cartographer, isn't involved in any of the lower level decisions about uh what happens with source code or um or images or uh any of those things like there.

D

Isn't that sort of decision logic in any of our current code and what our current code does share is a lot of concerns about reading crds reading objects that are already in the reported by the api server and then stamping out new objects from them and that's what runnable has in common with supply chain has in common with delivery.

D

And that seems uh that question of fit, I think, is really distinct from the question from some of the questions you raised in terms of like does. uh Is this a worthwhile project? I'm like? Yes, definitely.

A

Yeah- and I don't disagree with anything- you just said- uh obviously it's implemented today as an extension point that fits into cryptographer and like we can. Obviously it works, um like I said in timeout, so you'll have to trust me that it works, but the the question of like how deep is too deep in terms of the knowledge, I think, like the way that we approached creating the sort of the relationship of conventions from a choreographer of conventions.

A

um I think that's sort of one of the distinction out women's funny elements so like when I talk about being able to identify a spring boot application and sort of apply a aliveness around this probe, that's appropriate for a spring boot application, like that exact logic, is not what I'm proposing that we contribute to cryptographer. What I'm proposing is that we contribute the ability for someone else to define that behavior and sort of help that sort of naturally be an extension.

A

So the actual convention services itself, the core of it, is basically similar to how a supply chain can exist. But with that, if it doesn't have all the component templates defined, it's not going to do anything or if a workload exists, it doesn't have a backing supply chain. It's not going to do anything. The convention service can exist, but if there's no conventions defined- and it's not going to do anything so it's when operators start to plug in these conventions, then the actual behavior starts to emerge. Out of that.

A

So for from that spirit, I see them as similar. It's definitely higher level, but I see the overall spirit as being similar.

A

But I also acknowledge, like it's subjective and sort of where you want to draw that boundary line, is valid.

B

Any other comment disregard.

B

Thank you for bringing all this this specific topic into the open. Thank you.

A

Thanks for having me.

B

Awesome so looks like we reached end of the agenda.

B

If there's not anything else, you would like to discuss. Thank you for your time. See you next week.

B

Bye. Thank you.