VMware Carvel Community Meetings, 27 Jan 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Carvel Community Meeting - January 27, 2021

Description

Carvel Community Meeting - January 27, 2021

Meeting information and notes can be found here: https://carvel.dev/community/

A

Cool, so everyone see with the agenda right. The shared screen great, so welcome everyone to carvalho community meeting today is january. 27Th we're excited to meet again so you'll see uh the agenda that we have it up here and um you'll see also the maintainers joining today. So if you're a maintainer wave your hands, so we can see you good to see you all beautiful faces um so yeah.

A

So today we're gonna start with announcements, what we're working on and then we have few topics that we want to talk about um today and, as always, you can find the recordings on youtube or, if you're, actually watching you're on youtube already so announcements here, um big announcements, um please note that we're making changes to this community meeting we're no longer gonna meet um on every other wednesdays, but we're gonna meet every monday.

A

So more frequently you get to see us at 11, 30, uh pacific time, so um los angeles or san francisco time or portland. Seattle time there 11 30 every monday, so uh you'll get an updated invite so uh be on the lookout for it. You'll still be able to connect to the same zoom link.

A

So don't worry about that so see you next monday, and another big announcement is that we are going to move to get up projects so um so far the maintainers we've been using a different tool and we're moving to github projects so that um you know folks in the community have greater visibility in what we're working on and so that you can also chime in and contribute together. So starting next week, you'll see all the work that we're gonna do reflected on the carvill github project.

A

So we'll add a link to this agenda later too once we have that ready. But I wanted to share that out.

A

Another thing that is exciting is so we want to try out um a github issue voting or what we're calling like a feature voting. So we want to hear from you what you would want us to work on next.

A

So if you go to github, let's go to it real quick, we go to issues and then, if you click onto an issue you see there is a oh I'm not signed in so if you're signed in there is a emoji where you can react to it by throwing a thumbs up.

A

So if you see a particular issue and you're signed into github, please let us know what issue that you would like us to work on or what you would like to contribute on by throwing that thumbs up we're hoping to get this experiment going and see how whether we can you know hear uh get your thoughts reflected in how we prioritize so um yeah we'll share that again next week and then also let you know exactly where you can do that voting.

A

So we have a few releases, um so image package version 0.3. We have um now we're introducing this concept of image package. Bundles, so you can read more about that here in this link and then we also are supporting this copy command, where you can relocate bundles, so read more and then there are some bug fixes along with it. So you can um look into each git of issues.

A

Next, one is key, build version 0.28.

A

So if I go back to this release page so because of the changes that we have made with image package, we had some revoca refactor decay, build it's supporting the new format of image packages, image lock and then also so, if you want to learn more about that check out our docs again, our docs are now at our website, carbo.dev, so check into that and a new features for buildkit.

A

So, thanks to dustin and andrew who worked on this release, we are excited that we see other community members contributing to our project. So thank you. Thank you and welcome.

A

So those are the big announcements we have also um carrie and dennis will be able to share what we're currently working on so carrie. Do you want to kick us off on um what we're working on there with ytt.

B

Sure yeah, just a quick update on what we've been working on lately, um so for one of our tools, the yaml templating tool, ytt working on a feature for adding schema support, so this will basically be a way to specify exactly what inputs that you expect into your data values and your templates in ytt as part of the schema's work.

B

We really want to get something well-rounded and complete into the hands of users as soon as possible.

B

So we have been focusing on improving our error messages around schemas, so um we added some features to basically make the error messages consistent across schemas and also to add a little bit of information around where an error is happening in your schema and what we expected so hopefully that information plus we have a few hints to help you get going and debugging in schemas and then another thing we've been working on is a schema file as data values.

B

Helen. If you want to click on that link, it might be a good visual.

B

um So this is basically um the way that ytt works right now is you? Can you basically add your inputs to ytt as a data values file?

B

Well, when our schema feature comes out, you can actually provide your data values and your schema in the same file.

B

So it's a way to provide what you can think of as default values into ytt feel free to check out this doc. It's got a lot of helpful information on schemas, the syntax. What you can expect, it's really the source of information for the project yeah. That's it.

A

Thanks carrie dennis what about what's new? What's what are we cooking in image package? There.

C

Yeah, so the non-distributable layers feature. This is a feature. That's going to be really useful for folk that are running that want to run um images in an air-gapped environment in an internet-like environment that they want to run an image that contains a layer that has been marked as a non-distributable layer and currently without this feature implemented. That's not possible. This feature is all about introducing a new flag dash dash include.

C

It says here, foreign layers, but it's going to be called dash. Dash include non-distributable layers where it's a flag for the copy command and if you specify that flag to the copy command, when you copy an image that contains a layer that has been marked as non-distributable, it's going to get copied from the source to the target. So in the before use case, you have an air gap environment. You have an image, let's say it's a windows, microsoft image that has been that has a layer, that's called that's been marked as non-distributable you've specified.

C

You use the copy command with this flag. You copy from that. You copy that image to a table. You put that table on a usb disk and you go to your data center. It's an air gap environment and then you upload that table to a registry. Now your registry inside your air, grabbed environment has a microsoft image that has a non-distributable layer and you can use that to run in your kubernetes cluster or, however, you want to run that image.

C

Current is still in flight. um If I was to make a bet, it would probably land on the next release of image package.

A

Cool thanks for the update dennis um okay, so we have a last announcements here, so we have new web pages for now image package and vendor. So if you recall a few weeks ago, we announced that we have, um you know new pages for each of the projects and also like a whole refresh of karbol.dev.

A

Now you can click into image package and also vendor to learn more about those two specific tools. So you have each of the pages also have their own documentations and um yeah. So you can now go to cargo.dev to read all the dots instead of needing to go to github one project is still pending, so cat controller is still linking to github docs so that we are currently working on actively working on, but all the rest of the docs. You can come here to carbo.dev.

A

So now, let's move on to uh discussion, so I see two topics added here and as a reminder, committee members y'all, can add a topic here. We usually have this agenda up ahead of the time.

A

So, even with our weekly, you know new community meetings, we'll still have some of the discussion times available, so please throw in a topic there. If you want to discuss so I see the first topic is assertion library, discussion. um Whoever added this item could maybe speak to it.

D

Was I the one I think.

A

D

Did you edit john or did I do? No, you don't in.

E

I mean I want to talk about this and I thought we were, but I wasn't the guy to put the words on the page now. Maybe that was but.

D

E

You want to you want to kick us off man. I know you've been doing some.

D

F

E

C

E

You do you have your example or the pr that might be a good thing for us. Yes,.

G

I could share my screen: yeah cool.

D

I just oop there we go, I'm gonna share my screen.

D

D

Okay can y'all see my screen, my nice discussion topic in github cool, so this is basically just like the discussion topic that I created underneath carvel to so we can talk about this and what is the what's the? Why behind this? So currently our if we look at our tests and and in the way they uh that they are set up, I feel like that. There's they are a little bit hard to read. uh So if we, if we take an example, for example like in ytt, let's go to image package image package all right.

D

So if we take a look at at our end-to-end tests and to these uh bundle tests, we can see that the big thing that is telling us what this, um what this test is doing, is like this huge name here that we have here and personally as this is like a personal note, I'm not very good at reading snake case sentences, but um yeah.

D

So this was one of like the first pain points that I had when I joined this project is that for me, it was a little bit hard to understand the the the content like of each test, because I felt like I, I needed like a a bigger sentence in english. To tell me what this test was doing uh and like the way. The way the tests are structured as well. uh Sometimes it was not like straightforward to try to understand what they were doing.

D

They were doing like a lot of setup on them and it was hard to understand like where the setup started, and where did the test.

D

The effective assertions started and what were part of the assertions and what were not so in order to try to get this um try to understand like is there like a an a different way that could be easier for people to understand what we're?

D

uh What we're testing here, uh I thought, maybe that we can, if we add, a if we add, um maybe a testing framework, that that would decouple like these informations, like this, these parts of the tests that could give us like a little bit more an easier way for us to read what the test was about.

D

uh That would be interesting, so I I did a quick google and I added some options here that currently we're using the golang vanilla like what comes from the center library uh testing framework, and it works pretty good right, like there's a lot of prior art and a lot of projects that have this as their testing framework, then I added like two other uh uh frameworks that I knew about.

D

uh One is spec that is just like a fine, uh thin, very thin, wrapper on top of uh tests, uh testing framework that it's not linking outrageous. Oh, what is that?

D

Okay, I think there's like a problem with that link uh that it's basically just a thin wrapper on top of the test, but it gives it a little bit more structure and you can have something like uh you're running a test, and you can write letters about what this is doing. So, for example, it should have some default, for example right, and it has like a more bdd structure.

D

So another option that I saw it was ginkgo and, for example, for some reason ginkgo is okay, but the other one is not that somewhat just uses more or less the same. um The same ideas for the bdd I do. I I explored just spec. I didn't explore gingko, but I do believe that there's like some sort of like um an issue with ginkgo that ginkgo doesn't do very well with threading.

D

If I'm not mistaken, and it is a, it is like a more complete uh framework instead of being like just a thin wrapper like uh spec is, and you can see that spec a lot of things are just passed around with the t testing t around, while gingko even has its own implementation of the testing. T so it completely isolates uh the go framework from testing framework.

D

The other part of this this that I was looking at was that we kind of currently do all the assertions by hand which is okay, but then our assertions we'll have to implement like our own methods and if we, for example, if we try to see this assert bundle lock it just we try to do something like we compare the objects and then we need to do a fatal to then say like what we expected to do and- and I thought there must be a better way like we don't do.

D

We really need to do this if statement when we're just trying to compare like, for example, to strings and as a matter of fact, there are some other options that I collected here that could help us out making the tests a little bit more readable. When you read like the assertion, you know what what is being asserted on so like I I looked into again. This link is broken.

D

Fine I'll just cut this here, so I looked into testify that basically it's just an assertion, library that allows you to have like commands, like I'm going to assert that this is equal and then you have the expected and then the actual value. And then you can have like a sentence. If you want to and say like.

D

Oh, I wanted oranges or like I was expecting oranges, and that's not what you gave me uh and I think this way it's a little bit easier to understand what we're trying to compare and what we're trying to do. And there's like a bunch of assertions on this library that we could piggyback on another option. It was go mega and go magazine. A search is a it's a matching library. It's not an assertion library which kinda.

D

I don't understand much the difference, but it's more or less the same thing right, and this is the the the library that is uh recommended to use with ginkgo and it basically, it contains more or less the same, the same functionality as require.

D

Did I click in the place that I was expecting to see all available match matches, so it is a little bit of a different syntax, but in the end it is doing the same thing. It's saying that is this: the value that I have it should be equal to blah right. So this is more or less like the the frameworks, uh the other option that we that I was told about to be fair.

D

I did not investigate this a lot uh there's like this library that can be used for ytt tests that allows you to do some matching uh for uh for us and it brings by default some matchers that you can check out here. So there are like some functions and it works in a similar way to other assertion. Matching libraries right.

C

Yeah, this is a specific matcher for gemega, like this only works with gomega. I believe, oh.

D

Okay, okay, cool! So thanks for clearing that out dennis so and like I started this discussion to try to understand if there were like other ideas and I attached to that a little bit of the um of like a prototype, let's call it of a. um I picked up this one particular file and I said like okay, I'm going to try to make convert this. This file, this test file into a spec, testify.

D

Testing file, instead of what we have right and I created some pluses and my minuses around like after my experience but.

D

Just scroll down, do I have no. I cannot do that thing. So, there's like already some dimitri did some um some comments here, but in the end, if we look at this, it becomes, I think, a little bit easier to reason about what is being done in terms of uh testing, uh what we're trying to test and then our assertions.

D

I think they become a little bit more uh understandable if there's like a lot of text there, but things like this. I believe it becomes a little become a little bit more understandable and could help us out and also the the fact. The thing that I like about this is that we can have uh resemble a resemblance of structure where the tests like feed from the parent test.

D

That gives you like even a broader information. So, for example, if we see naming wise we're doing a copy bundle image test and it should preserve the copy bundle image, it preserves the annotation right or if we go. I have like an example where we have like multiple layers, for example, for this one: the copy bundle image tests when the images of the bundle are collocated with the bundle it copies the images and creates the bundle when minus minus lock output is provided.

D

I think, like this, provides a much better information about what this test is giving and what is tess is testing really, instead of us trying to read through there's, there's like a description about this test. Let me see, if I can, is this the file. Let me check go back so there you go so like this. I think this is the test like test copy bundle with co-locators reference images to repo destination and output.

D

So like this is the trend. This is like the test that was converted from here into uh too many tabs too many tabs here into like these lines, and I believe that it feels a little bit better and allows us to isolate if you want, for example, to have some setup that we want to do. We can move that setup into before blocks and to be fair, like this commit that I have here it's more like these are the things that we can do it doesn't.

D

It doesn't like try to say this is the way we should do tests and the tests should look like this right, it's more like what are the possibilities that we have given these two frameworks uh and yeah. I think that is more or less it.

D

uh I I tried to open this and see if there was like other people that were interested in experimenting with other uh frameworks, but I'm the only one here so, but in the end, what I, what I saw in terms of like differences for spec in particular, is that spec is like a thin wrapper around uh test testing t, so it still keeps all the the goods that come from test from the testing package from go with it. So it does all the things that um the testing t does it's.

D

It gives us like a well-known terms like when and it that translating to the messages on the common line when you run go test, oh by the way like these run with. If you just go, do go test and you have tests with testing t like the the base standard library, testing plus spec, they all run without you have to having to do anything because it is the same uh infrastructure that it's used. The other thing is that you can focus particular tests while currently there's no real way to do.

D

It allows us to skip a particular test as well.

D

It has no extra dependencies whatsoever, so the only dependency it has is on top of testing, uh and the test names can now be full sentences to describe the behavior that we expect. um One thing that I that I noticed that sometimes nesting can be a little bit hard to follow.

D

If you have like a lot of, if you do tests that are like very big that do a lot of things, then it might be hard for you to follow along what what is like the context that you're in so that was one thing that I I saw that could be improved, uh not could be improved. I don't think the library in itself needs to improve it, but it's something that we need to be aware of when we're writing tests and for the testing, like the testify assertion library.

D

uh What I saw is that it has like a better error output and without you having to do much, you can say like this: bananas need to be equal to apples, and then it already has a phrase for you and says like oh, but the expected bananas are not equal to the the the apples that you got that you provided right so like it.

E

D

Error messaging, just out of the box, uh I think it's it makes it easier to read the purpose of the tests when you're looking at it- and you say just like not equal this- this might be like a flood. I have, but I'm a little bit of a bullying impaired person and when I have to look at knots and hands and so on. It takes me a lot of time.

D

Well, if I just have like this reason in english, it makes it easier, at least for me, it has a lot of pre-built assertions and also allows the user to the developer to group assertions into blocks. So there are two different types of uh there are searches and there are requires and the assertions you can do like 10 assertions and it will not.

D

It will fail in the end of the test unless you use require and require fails at the point where, if there's a failure, so like you can group assertion group assertions if you want to assert like in different parts of like a an output, for example. uh So that's that's something. That's neat.

E

D

That um that I saw as a downside, it takes some time to convert tests, especially because we already have like a a full breadth of tests right and it has some third-party uh dependencies. So it brings some some extra dependencies to our code.

D

So that's basically what I have to present in terms of like the this experiment that I did with spec and um testify. I don't know if anyone did has anything that they'd like to share if they try to do this with different libraries or something or if they have any kind of comments and so on. What I would like before we do that what I'd like to get is more or less try to understand.

D

If this is a pattern that we we like and that's something that we would be willing to um start using, and if so, I would like to see this if that's something that we that we want to implement. We I'd like to see like whenever we do some changing the code that we start, including uh our like these new frameworks and so on. That's that would be like my my goal with this um experiment here so I'll open. The floor too, does anyone have any question have anything that they want to show something like that.

C

I mean I prefer the bdd nessa structure a lot. uh It just makes it. I agree easier to read in in my head, while you were going through spec and you were going through was it testify as to match as the assertion library in my head. I was like because I have prior experience with ginkgo and gomega and there's a almost complete overlap in terms of you know the ginkgo to spec and in my head gomega to testify.

C

um You know they have context and whens and it's nested in to each other and even the the way that assertions are made. You know something should equal this, then, whatever that looks pretty similar, I'm just wondering about um the activity like the how well supported you know. Testifying spec is, I know. Ginkgo and gomega is active, actively developed and they have releases pretty frequently I'm wondering about yeah how popular spec is, for example, or how widely used it is. That's something that's unknown to me.

D

So to answer that, like testify, it has a lot of stars in here and they release pretty frequently uh to be fair, like in a in a library like this yeah. I expect this to be released frequently, while the testing framework for this one in particular, it's not the like steven, usually doesn't do like a lot of updates, because in the end this is a very thin library.

D

The only thing that this library provides to you is just the readability of the tests and gives you some sort of like a a structure where you can call befores and afters, and that's it. So it's not. I don't think, there's like a lot being developed right now, because in the end, the idea behind this library was to create just a thin wrapper on top of testing t that could provide you, some bdd-like uh behavior. It's it's just that so a very simple library.

E

Okay, so when you're done, you're done.

C

Yeah, okay, so ginkgo and spec maybe differ in that ginkgo can be used as a very thin library. It could just be used as using before afters in its and whens if you like, but it also offers a lot more functionality that we may or may not find valuable.

C

I know you mentioned it was harder to write parallel tests in ginkgo, but I'm pretty sure they have first class support for actually making assertions when you run, you know, go routines in your test and that's part of a ginkgo framework.

D

From what I know is that the parallelization on ginkgo was created before testing t or the standard library was able to parallelize tests. So that's a good thing, but the problem now is that, at least this is the knowledge that I had like maybe a year ago, or something that, because they do not rely on a lot on the testing library, they now have their own implementation of the testing of the parallelization of the tests. It is a parallelization of the tests that I'm talking about uh it's it's it's like their own.

D

Instead of using the the um the testing that comes with go right. So.

C

Yeah, I think you can opt in to use the testing object or, if you use ginkgoes, you can run tests in parallel, but you got to know what you're doing you don't want test pollution when you're running tests in parallel, essentially yeah, and it also does allow a really nice way to. If you have parallelism in your implementation code, they have nice primitives to help you test up. You know, go routines running in your implementation as well.

F

Yeah, just add on to that, I think my experience in seeing parallelization issues has usually been just not structuring the tests and isolating them properly or using shared resources and having contention. um So that's, I think, mainly on us to be able to structure those things well.

D

uh Cool john, you were going to say something.

E

Yeah, I I was thinking about what are the uh the the the needs that drive us here. So one of them is that test names, as as they are hard to read um that the sections of the arrange act assert can be hard to suss out um yeah. I agree with a lot of that um dennis and I saw a real improvement in the schema tests that we uh just reworked a little bit of organization.

E

uh The t object that testing.t object provides uh that run function, um which kind of nice when, when you're looking at um at spec tests, they can. They can seem very similar to uh to that, because I'm used to seeing the the the tdot run, it could be a spec.run.

E

um The the other things that come up from me are um the before and after are are not available in the built-in testing framework and there's hacks that you can do to make that work, but it's pretty hacky so that that's a really big win on, in, from my perspective, to be able to set per test uh setup and tear down and also because you can layer things a little bit and again, I echo your concern about uh you can go nuts there's more rope here than you need to get the job done in terms of nesting context.

E

You could very quickly create a maintenance problem in the other direction, but but but it does provide, provide a really nice smooth way of, including uh before and afters.

E

The one thing that I'm uh just trying to add to the conversation doesn't mean this is a big deal, but it, but it's an important one for me personally, is um I know. There's a number of us use. Ides want to make sure that whatever we use can be, even if it's a little bit of work to get it working with id. We live in that we code in that 3tdd and that, for those that do want to make sure that those workflows wouldn't be broken, um uh and then I wondered, did you?

E

Did you run into any kind of assertion that uh would show a diff like we've got a number of tests where we have like multi-line strings, and we want to show the difference between the expected and the result and want to show like a um a patch style diff. Is that does testify? Have that? Do you know that off top of your head.

D

um Testify has a bunch of uh assertions for you and you're okay, so.

E

In the end like they do have they do.

D

Have like it's like these are like the basics that everybody has right, but I do believe that they have um a lot of like comparison and the output. But what's oh my god, that's not what I want to include.

E

We don't have to research right now is just wondering if you off the top of your head.

E

So yeah there's this bit where there's there's some there's quite a bit of subjectivity in like readability um and some of those other things, but I feel like from where I'm standing.

E

I could see a real improvement here um and, and more importantly to me, is like that we have actually more plays in our playbook with like the ability to set up and tear down context easily, um if uh the the other thing actually that is a big deal, is the approachability of our projects to open source contributors.

E

um So I think that I wouldn't look at stars per se as some kind of indicator, but uh or or some kind of um direct measure, but like they do indicate a little bit of how many folks are out. There would probably be able to look at your tests and uh not just be able to read them be able to contribute.

E

um So this is part of. I think why the built-in testing is appealing because everybody's got it um it's a lot of material for it. So that's the thing. I think we want to keep in mind make sure that we don't create inadvertent potential barriers, but like okay well and additionally, you got to learn this other thing.

E

um If, if learning this other thing really maps well to what I would already know, that seems legit, but yeah.

D

Cool thanks john: uh does anyone have anything else? They would like to say. I'd also like to be constant that we do have another topic, so uh my idea is that we can maybe discuss here and then we can try to make this some sort of like an asynchronous.

D

Maybe in a synchronous discussion where I can create something in slack and then we can contribute. If there's any questions, if there's like any other options and eventually we could create some sort of like a pull or uh just to see, if that's something that we would like to uh to undertake or not as like. The next steps for us.

E

Can I suggest, like I think this breathes like talking about it together, breathes life in into your discussion.

E

I know you pointed to it before but like if we, if folks, had additional thoughts that come up uh after having seen this and had a chance to go, look at things themselves and have questions that the discussion that you started with this. You know rich example and all the stuff good place to get that going.

D

That's definitely a good idea.

G

Cool just last minor comment. I realized that um one of the points here is um takes some time to convert tests as well um kind of the counter points here, and maybe this is implied, um and people are thinking that way, but an easier way to like convert would not be to like do like a big like convert all the tests. I'm thinking of this, as like more of like a update things kind of as we need to would be a nice way to kind of introduce this.

D

That's a definitely a good idea when I said this, it was. Why did I say this here because in the end I kind of had to rejigger some of the tests in order to make this work so like, even when I I did like a file right, but it's like this.

D

One file took me some time, because I had to rejigger a lot of parts in order to to put this into this format and to make sure that the format made sense and so on, and when we're doing this, the assertions I had also had to change some things here and there. So that was the only thing that I was trying to call out here.

D

It might not be just as simple as pick up the function name replace that with a string in english in the testing framework and then just go and find the equal equal and replace that with a assert dot equal or something like that right. So it was more just a call out to that. But that's a good.

D

D

Cool anything else.

E

Thanks for doing all that homework, man appreciate it.

D

So, as the next steps, uh I'm gonna.

E

D

Here, for maybe a week more and then I'll, maybe try try to create a poll or something to see if that's something that we want to uh take over if there are other uh other ideas, uh just put them into this discussion.

D

uh I'll share the discussion in here, and maybe I can later add it to the uh to the other, um to the to the meeting notes. So we can go there and we'll see if we wanna undertake this or not. Thank you and ellen.

A

Trying to do that right now at that github issue to our uh md agenda and see if that worked.

B

uh If we want to talk about the next item, um I can share my screen. Go over that a little bit.

A

Yeah. The next item is command to validate data values.

B

Yeah, um so this is an issue that I filed. um It was inspired by uh an issue that danny um herbert filed for generating data values file skeletons. He proposed a command to validate a data values file.

B

um I thought it was a great idea and I think it goes well with sort of the work that we're doing around schemas, um so to kind of incorporate that idea into schemas. I propose a top-level command in ytt to basically validate the data values that you've given.

B

B

What this command would be able to provide in addition to like what ytt does currently with schemas um is it would be able to provide more information about what may be wrong in your data values file.

B

Currently, if you run ytt-f with your files and your schema- and your include experimental schema flag, of course, because this work is feature flagged currently um that command will either fail or succeed um fail with some errors. Your data values file did not adhere to your schema, and so that is an error. Otherwise it will succeed, but we think that there may be some additional information that would be helpful to know in addition to just failing or succeeding, such as warnings for like ytt best practices.

B

So one example I gave here was: if you have a value defined in your schema and say it's foo apple, and then you redefine that same value in your data values, file um totally valid totally acceptable, but.

B

um Maybe we want to provide a warning to let the user know that this value was defined twice to the same thing, and maybe that's not what you meant to do.

B

So for context around schemas, basically, your schema definition file acts as both the contract for your data values, files and a default value.

B

So, basically, by passing in this schema, you will have a data value foo apple by adding another scheme. Another data values file on top of that basically acts as an overlay on your schema.

B

So you could change foo to a different value.

B

There's been some discussion in here. Some really great points. um Basically.

B

I think stephen brought up some good points about like what do we want to recommend for best practices for ytt um that'll kind of inspire, what it is that we would want to give warnings on um like what would not be recommended. What we want to warn users not to do, and another example that stephen and joao came up with was a configuration author would want to provide a single instance for deployment say in your schema file. You have like replicas one.

B

But the configuration author recommends that the consumer of the configuration change that later on to more acceptable value.

B

So we could warn the user about that.

B

Another use case is unused data values.

B

um Basically, you can provide as many data values as you want in your schema or your data value file, but you don't have to use them and that's not an error, but it may be indicative of well. Maybe you accidentally hard-coded something or maybe you meant to use those values but didn't.

B

And daniel also mentioned that this is similar to linkedin.

B

Yeah I'll, let you all talk more about your points if you feel like wasn't captured in my synopsis, but I'm curious from from the people here like.

B

Does this have enough value to be its own command, or do we feel like we want to do this like the way that we're doing it now, which is basically fail? If there is an error, and we can report warnings to standard error which is kind of how this works.

H

Now my current belief is that this is this is valuable, but should probably exist within the same schema.

H

B

The same schema command as in like ytt.

H

Right the same normal uh templating command. I really love the idea of the fail on warnings flag, because this to me is, is just a bunch of warnings that well yeah. You may have duplicated a message or probably an extra data value, or you may not be using something that you specified that to me isn't an error. It is just a warning and so offering the consumer the ability to fail.

H

If any of those conditions are true, I think, might be nice, but it seems I don't know, perhaps small enough, that it shouldn't be its own uh top level command while being big enough to offer a an intermediary flag.

B

Yeah, I think some advantages of using a flag rather than a top level command would be like you can go through the exact same flow that you would otherwise, if you're, maybe piping the output of ytt into another tool- and you include the flag fail on warnings- then you'll never make it to that. Second step um fails early. um You don't really have to change the way that you use the tool which I think would be nice.

E

Part of what I really like the spirit of of this idea is that it it's getting to the heart of it points to the heart of a part of the overall problem. We have with ytt adoption, which is um there's various potential barriers sitting in front of a new user of ytt, and some of it is education, and some of it is us like helping the tool, be more cognitively, empathetic um garrett's heading up like a yeoman's effort and trying to like make that second part better.

E

But there's also this first part like in in terms of guides that we want to write in the documentation to like meet people halfway about where they're at, and this feels like another potential ingredient for improving the overall experience, especially if somebody's getting started with the tool where we know that there are probably widespread assumptions that one might bring. There are assumptions that many folks might bring with them to using the tool that like fall invalid um and it's just the tool, has a slightly different philosophy. And how do we uh kindly share that?

E

um There's this counterbalance in my head of?

E

We also there there's a kind of um an aspect of that in being concise, so um there's real value in in keeping the messaging and the signal that we're getting from the tool to be tight um compact, if you will like high signal, low noise, and so then that makes me wonder about like yeah, maybe that linting things so anyway.

E

um I really appreciate the exploration here. I'm I'm personally like really torn about like the what the interaction ought to be personally, but I love that we're digging into this, because I think it's a very subtle. No, no one's directly asking for uh okay. Can you make your education experience better, but, like that's one of the big things that's in front of us, I believe, with this.

E

G

I do think there's like this um kind of idea. That's come out of this of like what the what really the scope should be of this feature like whether or not we just want to focus on things like data values. In this case and like um in some cases like, should it maybe only apply like if we're like validating things against schemas.

G

To another extent, um I think maybe that's like where it should be like um refined, a little bit more. It's like or like do we want to maybe like would something like this be more valuable to like start with this, like more specific case of like validating data values um and then like, maybe we evolve it from there, um because I, I really think that something like having like something that gives you a more opinionated idea about like how you should work with ytt like beyond.

G

Just even like your data values file would be really valuable and, like maybe, would be really helpful for people um who are using it, not even just as like, first-time users but like day-to-day users, of it help them like learn better ways of like working with the tool.

G

So maybe that's like um something to to think about with. It is like how valuable is this like overall, like beyond like doing this data values, validation um and like maybe, would it like just but like? Would it make more sense to like maybe start there from like? Just uh how to like um see if this feature like adds a lot of value to people's life um like to really put it in that scope, to start.

B

Yeah, that's a great prompt like how do we know that this is really adding value.

B

I think one way that we can kind of get more data on that is adding use cases um seeing what use cases this could help with, and um I know we have like three or so in here, but if we think of more, I think it'd be really helpful to add them to this issue. Like here's a case where we could inform the user of a better practice- or this is a pain point that we've seen right now, be super helpful to add that in here get more data.

D

uh To be fair, like the talking about the difference between this being a high level command or being like a flag, I see these there there's two different.

D

Use cases right where there's a use case, where you want to use the tool ytt in order to generate some some yaml that, then you want to pipe to something else or you want to generate the file and that's one use case right and there and that's the use case of someone that is, that receives the yaml and you just want to generate the yaml and just put it into kubernetes. For example.

D

Right, I don't me as that person, I don't care if there's any warnings in in the yaml, because some of a lot of this those times you're, not even the one generating those yammels right, you're, just consuming them.

D

The other side, where I am the person that is developing the the the ammos and the ytt templates and so on. I think I would prefer to have a way to tell me like. Is this correct, because why? Why should I call ytt to generate templates and give me a wall of yaml just so that I have to go scroll up to see if there's a there was any warning or uh or that I have to? I need to add like another flag. I think these are like this.

D

We are catering to two different users with using the minus minus using the flag or using a command.

D

So personally, I think that the validate gives you more like this idea of like okay. I want to make sure that what I'm generating is okay he's good while ytt. When I call ytt I want to generate my yaml, I don't in some way I care about the correctness of it, but I I just want to generate my yaml and pipe it into uh something that will apply it, for example, right so.

B

Yeah, that's a great call out.

B

Well, we're running out of time here so please add your thoughts to the issue. Any use cases that you think of that may be able to be solved by.

A

A

Thanks thanks carrie and everyone for the discussion so again a reminder. uh Next week we'll meet on monday 11 30 a.m. Pacific time so cool have a great day. Everyone.

A