Open Feature OpenFeature Project Meetings, 30 Jun 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: OpenFeature/Flagd K8S SIG, June 30, 2022

Description

Meeting notes: https://www.google.com/url?q=https://docs.google.com/document/d/1u_1qnS0PiYvZxwtsBgZrsX6DrRKfpG56q-Kh0-qn_pU/edit%23heading%3Dh.wh8mkiotns4b&sa=D&source=calendar&ust=1655043850692349&usg=AOvVaw3jgs22qY0Eh_ZvErxDUON9

OpenFeature website: https://open-feature.github.io/

A

Let's kick it off to nobody.

A

Give it like five ten.

B

Minutes or something.

A

B

I mean if, after 10 minutes.

C

B

C

Hey how's it going.

B

uh Hold on my I'm, I'm muted try again. I.

C

Can hear you? Oh okay,.

A

Yeah, I think yeah.

A

Max said about him,.

B

C

So where are you guys at now.

B

C

B

Yeah, just for the uh until saturday and we're playing back so todd just got out here, though so we're meeting with a few teams and uh yeah I've been out here almost two weeks, though so I'm pretty exhausted and ready to head home.

C

It hits that point where you're like europe is nice, and then I want to go home.

B

Yeah yep, so uh definitely looking forward to that yeah.

B

Lars, I think uh I think I've seen you before were you from. Are you from dev cycle? Am I getting that right? Ebay, ebay, that's right! That's what it is! Yeah.

A

Right yeah but um yeah so first meeting for me, so I don't know what to expect um yeah, I'm I'm I'm a java developer. Basically, so I'm a bacon developer, but java is my main language for now over 20 years, so hope to be able to contribute to open future.

A

B

Perfect yeah so yeah just to I guess, set a little bit of context, we'll see we'll see where it kind of conversation goes today, but uh this one this meeting typically is focused on just like the uh the kubernetes and the flag d portions of it, um and then the other meeting is the one. That's specific. Like the broad. um You know, I guess open feature topics, so uh you know we may have time to address any potential.

B

You know questions that you have, uh but that's typically, um you know what we talk about most of the time for these these particular meetings.

B

You're gonna, be subscribed, yeah I'll, uh my battery's about to die, but I'll do my best to describe.

A

B

Can also you could also just copy it down after, if you want to use it yeah, so I might just do pen and paper. So, okay, yeah, I'm not even sure. If we'll get that far daniel, we'll see how far the conversation goes, um but uh I'm not sure how long we'll go for so um we don't actually have an agenda so I'll just um rely on people to bring things up.

B

uh The the only thing I can think of starting, I guess that might be worth starting with, is there's been a decent amount of work done in flag d, especially since the last meeting, so I can summarize that at a really high level- um and that will segue into I guess the one thing that I was thinking of talking about.

B

um So in summary, uh we have implemented uh a basic json evaluator, um so that the flags are stored in a specific format and which is uh itself maintained in a schema's repository um which also previously contained our apis, open api specification for flag d um and, uh in addition to defining static flags uh in a way. That's that's.

B

You know going to be familiar to you if you're familiar with um with pretty much any feature flagging system- and it doesn't look, it looks like you'd, expect, there's variance and a default variant and basically an enum specified if the flag is enabled or disabled. We only made it minimum because we wanted to support additional possible options later without having to break the contract and then most recently, we added rules which are defined uh via json logic um and into that schema.

B

So, uh basically, now you can do what I would consider to be like a basic, a really basic definition of a flag, including dynamic evaluation, just by just by defining a proper json structure and uh last week at the at the bigger sync, I demoed that end to end um with the operator just deploying it and using it to power our playground, app, which you guys may remember- um and I did a similar demo uh today internally at dynatrace that also included a rule-based evaluation which again only got merged a couple days ago, um so that's kind of where we're at now.

B

One thing I I think, I'd like to see happen relatively soon um is uh grpc service implementation. So, right now we have http um as a service implementation, uh and I would like to see kind of a similar thing in grpc um just to reduce all the overhead associated with http.

B

I mean there's there's ways we can improve. Even the http transport, using like persistent connections and stuff like that, but http is always going to be a bit slower and it doesn't support bi-directional so eventually, when we want events um to fire, if the configuration changes, http is not really a great way to do that. So I'd like to see that done eventually uh and then one other actually somewhat related thing um so alex initially we in in your implementation, there was a socket implementation.

B

uh We we kind of took that away as we added some additional interfaces and abstractions, but I'm thinking now it would be. It would be no problem to add it back now to add something like that. um If we wanted to so I don't know how you feel about having a socket implementation. Still that would um probably just uh you know, dump all the flags uh or or take a certain interface and or take certain parameters to like, like.

B

Maybe you could take a a string identifier for a flag and just send back that flag as a json object. I don't know if you still see that as valuable or not, but um that's something I think we could add back if we if we felt like it if he thought it was important, I think the.

D

um We could make it so that each buffer write from the socket returns the payload body of what the json object would be from the http restful protocol. So you can kind of just mirror that right, because it's just a decapsulated version of that. So I think it's it would be interesting to do.

D

But the greater reason was that you could use the same socket for hp as well right you could use, you could have a socket client and you could then do http transport on top of it, uh which would just mean we could do a bit of reuse inside of the application.

D

I don't, I don't think it's worth doing unless there's actually a need for it right unless we're going to build an end-to-end example which quite could be cool, I do think we should have a conversation about the examples we have, because we've got the kind of hdb sidecar example. But if we wanted to showcase flag d, is a multi-um level server, multiple service levels? I do think that that could be an idea right.

D

You say: okay, well, we're going to pick either socket we're going to pick up pick our pc and we're going to design an end-to-end demo with the implementation so that people can really get what this is all about, and also now, as just a brief update the I did a lot of work on the operator side uh open feature operator that now supports um multiple service providers.

D

uh There's some work to be done on passing credentials and api api uris through. But in theory the default service provider is now flag d and that's um that's, checked, that's validated what service provider is, but we can now add service providers like flagsmith, launch, darkly et cetera, et cetera, um and then what would happen is that on the back end, it would do a dynamic resolve based on the flag d input arguments to the flag provider. So I actually think that might be a better route of being our next thing to do.

D

But I don't know who is ready to work with us on that. Yet.

C

Can you help me understand that one a little bit what's like the order of resolving it? One thing to worry about with multiple providers? Is it can get abstracted from an end user? So if the flag isn't in one of these, you can end up in a weird case where you don't know what, where the value is coming from.

B

So so to me, it's this exactly the same as a server-side implementation, your pat, the the um the context, the flag d provider, for example, that we have passes all the same information to flag d that um that is available in the in the sdk. So it passes any user context. It passes all of the same objects um across the wire via like via the rest protocol.

B

um So it's it's it's it doesn't the map. The parameters you have and the context you have is exactly the same as what you have in any like server side. Evaluation, um for example,.

C

Okay, but so at the end of the day, you're still only loading one service provider when it's up and running right, like.

D

Yes, yes, okay, okay, I can talk. I can briefly just walk us through how this implementation works um so flag d at the moment, has uh this this abstraction layer for service providers. Also, sync providers syncs. This is this- is actually am a different sync provider. The service provider is the service that flag d offers outwards right. So that's hp only at the moment we're talking about res we're talking about grpc as well, etc.

D

However, the sync provider, which is the internal naming, we're calling this is where it gets its data from right. So what would happen is that the kubernetes operator, so this could be a vendor and um what happens is when flagged gets created in on the host by the um kubernetes operator. It just effectively is starting it with new arguments. Right, just likely start sync provider equals and then what would happen is we also have some additional parameters that get passed through, such as uh credential path. I'm thinking we actually store this.

D

We actually um put the secret from kate's on the disk, so we never have to read it in plain text. We just let that um get read by the program: flag d only or set it as an environmental variable. We can decide and then the other thing. Of course we can say something like the restful endpoint right.

D

I think most most providers come down on a pretty similar set of uh credentials and and configuration, and then what would happen is that, rather than using the um the injected config map that we currently use at the moment like that, where we we update it and sort of like the case layer, if you will um manages that we let the the provider manage it, so you can manage that through your ui.

D

So I can go to um one of my flagging isvs and click on or off in my ui and suddenly now I'm affecting what's happening inside the pod. Does that make sense.

C

Yeah, I'm still just trying to think through it from like. I know: we've circled it a few times just that. Normally we live in the application there and I'm trying to see what this is offering for the end. Customer that sure.

D

So if that application is a it's like a flask server right um and that flask server here has a um has a like, you know, pet shop kind of thing um and then or whatever, and then this can return back and then, of course, it's just your normal kind of flagging situation when inside the host application, it calls the client library um for flag d or in fact this I think, todd in your implementation. Don't you have a client library? Do you right? You just use restful so.

B

I think part of the confusion, though, is uh in like uh actually a lot of feature flag vendors. They do flag evaluation inside, like basically the host application in this context. So, yes.

D

B

That right right, but I mean the question I guess would be: is there a need? You know to some extent it made sense in flag d, because then you know that's just kind of part of this particular architecture and it worked well in the kubernetes world but like if, if you're already using launch darkly, for example, to move it to a separate process, may not you know, buy you much yeah the reason. The reason why I think and and doug from launch dark was somewhat excited about it.

B

um I don't know if it's the right solution for everybody, like especially in um especially in a k-8's world, like I think you know using the um configmap injected version- is probably what we're going to see mostly. But I think this is worth pocing, because I think specifically the use case that uh that I think was interesting to to doug. I don't want to speak too much on his behalf.

B

Was that, like I think, alex is getting at it allows the it allows the layer that is written in your application code to be extremely thin, so all you're doing in application in in the native application language, like maybe your application is written in erlang like something incredibly, maybe it's miranda uh all you need to do is be able to um to basically communicate over a socket and then there's no need to have a flag or to have a launch darkly sdk made for that language.

D

So my original, my original implementation was in c for this, and I just did a restful call over a socket to flag b.

C

And for the additional languages, then it makes sense. I guess like originally. You know it was definitely more exciting with the different architectures. I know. That's really is a blocker now also itself, because it's the end provider would start to support that architecture um but yeah. I could see a limited use case of this for those other languages that don't have support some of the really esoteric ones.

B

Yeah, I think that's that's one one use case another one is like, if you think of what's happening here, um you're we're moving the decision about about their feature, flagging implementation out of app code and therefore maybe a little bit away from the developer and towards the operations person right so like the person. Maintaining the cluster is actually making decisions about how this flag is evaluated.

B

um Maybe maybe they're aggregating multiple flag, evaluation systems and abstracting them all in flag d, um the the actual application author doesn't have to concern himself with any of that.

D

Well, you also, then, sorry, okay,.

C

Sorry, I was gonna say well, the abstracting of multiple ones is definitely a question I have because, as a service provider at the end of the day, you know we're there to provide a good value. If you're now combining multiple providers in your code bases it gets kind of complicated in how is it getting supported? If something goes wrong, is it actually launched starkly? Is it flagsmith? Is it flag d, which one of these providers is called.

B

Yeah and I'm not necessarily suggesting that people would build an architecture like that. What I can tell you is that, right now at dynatrace we already have that problem. It's already a problem for us, because we have multiple future flag sources of truth in our even in our in-house implementations, so starting to be able to unify them behind a single abstraction at least helps us move towards finding a solution to that problem.

B

I I don't necessarily see it as a target as much as it's a it's kind of a reality for some people um and then so it does help in that regard.

C

Okay, yeah make sense.

B

um Alex was there something that was there a point that you didn't get to finish, making that you wanted to yeah.

D

I was just going to make that um this is opening up a new market for these flagging providers, who traditionally have been um aiming towards application developers right and maybe even product folks who want to do ab a b testing. This now lets you create flags um that control operators inside of kubernetes clusters right, so you can do infrastructure flagging, turning off load, balancers, um there's nothing quite like that exists currently. So I think, there's a quite exciting opportunity here to be leveraged.

B

Yeah, that's an excellent point actually to alex. um Who is it? Somebody asked this last week. I don't know if you were there or if your head's, just in the same place yeah some somebody asked the ex they were like hey. Could we do routing decisions in nginx based on this concept um based on flag d, and the answer is absolutely you could like?

B

You can write custom extensions to nginx with lua, so you could write a lua extension that would call flag d to do an evaluation and then make routing decisions in real time based on that and that's definitely more in the infrastructure category for sure it's.

D

Interesting because I was also sorry I was just going to say, I was also looking at losing like a wasm filter on flag d that could do resolution based on incoming arguments and that's something else we can do. I know we've talked about using queue as an evaluation, um some dsl as well. So there's a lot of ways. You can build that out.

A

B

Yeah absolutely.

C

Yeah, I do think these will help with the learning. Overall we do have some customers using us with nginx. Today. I actually know one customer, instead of using the hpa, actually uses launch directly because it's more limited, but those are much more one-offs versus industry kind of concept. So hopefully we can kind of move it in the operational direction.

B

Yeah yeah and and like I said I mean I just want to reiterate like to your original point. Dan, um the the using a vendor in flag d is a valid use case, but I think it's probably not a primary use case. Right, like I think. The primary use case of flag d is going to be reading the config maps, but I think that it's certainly it, but because we're kind of already almost there, because we have all the abstractions, because we have the golang sdk and we're gonna have golang um providers it make.

B

I think it makes sense to be able to poc it and it makes sense to be able to see it working and I think, as we work on it, we're gonna see more use cases that are that are valid and interesting and again move us towards the operational aspect of things.

C

Yeah great, I just wanted to bring it up. You know I had the conversation around it to make sure we at least had the conversation, and now it sounds good to me.

B

Yeah yeah, I do it does make sense, so I don't think it's it's likely to have like some java application called through flag d to call the launch directly java sdk. It just doesn't really make sense, but um so yeah yeah yeah. I think there's there's some use cases but they're more they're, not the primary use case. Like I said, I would expect that 90 of flag d deployments are probably going to be reading um going to be reading a config, but that could change, because I think this could be a potentially powerful concept.

B

A

D

I had a few thoughts around that um I mean I don't know it's a good thing to mention now from the agenda at some point, that is, to open up other ways that flag d can have more dynamic updates, and one of them is to read the api server directly. So it's how they have a have an event stream on the api server, and then we actually put the data into edcd and we do that through primitives right, so we can kind of cut out the middleman.

D

I mean it's actually the same thing if you think about it other than having to mount the volume and then and then um have to to read the path, we're doing we're cutting that out and going straight to uh the server. So I think that might be the next evolution of the sync is to have a an api server. Sync.

B

Yeah that actually I'm assuming that would probably cut down on uh kind of suppose the latency almost of the updates. I don't know if you've gone through the demo, but it takes about a minute sometimes to like the record.

D

Yeah I mean there will definitely be use cases where it's not possible. Like I know you know, working at jp and amex those sort of places you're never going to be given permission in a tenant namespace to read off the api server, because it's also a cross issue right. You can, you can hammer it, but there is certainly a like a bunch of folks who don't care about that. So you could have said that maybe that could even be the default. It would definitely be much quicker because we.

B

Could even even beyond quality of service, I suppose there'd be like general permissions issues.

D

Yeah the service account permissions would need to be um more extensive, yeah.

B

Yeah, but that makes sense it's still a really interesting point. It makes sense to me, um but, speaking of uh speaking of the reconciliation time we had, we had a an issue to um add: uh add an annotation to our workloads like that. Would that would represent the hash? I don't know if that ever got action. Did we.

D

That was to um to check to see if the um hash changed. I thought I did that.

B

Maybe you didn't, maybe I just I just wasn't involved in the pr I.

D

Can check that so that would be in the um the mutating the the the web hook right.

B

Yeah, it's possible, I just didn't see it. Maybe it was a day that a couple days it wasn't working or something.

D

I'll have a check.

A

B

uh What's I mean those are all the things I think I wanted to talk about. I don't know if anybody else has anything they want to bring up, but those were the ones.

D

Yeah, I think you might be right, I'm not sure if it is in there. What was it was too. um It was just store, the the shah of the sorry that the the the integrity check of the payload, so you didn't- have to run it through the validator right. If it'd already been validated.

B

There's a couple things it was. It was to not run them because the record you, you said that the reconciliation, the reconciliation loop would run occasionally when there was no changes, yeah, occasionally as a no-op and then sometimes when there was no changes to the actual flag spec.

B

So in those cases we didn't want to do any reconciliation of the actual config maps, but the other thing was that we were going to as part of that add that same sha to an annotation on the actual workload on the on the deployment itself, which, if I understand correctly, adding an annotation to a workload hypothetically, should it should decrease the propagation time um in updating the config map. So it hypothetically should just make things quicker. Was my understanding, yeah.

D

That's right, I didn't get around to doing that. I'll have an issue.

B

I think there might be an issue already um that was that was there. That could be wrong. I think it might have been a sign to me at some point and then assigned to you. I think it's in the operator.

D

Yeah, there is provider awareness at cr level.

B

No, it wouldn't be that one in fact that one's done yeah, it says, improve reconciliation. Only it's this one, it's a side to both of us. It's 20 issue, 20.

D

Yeah I can take, I mean a very quick change. I I think I might actually have it stashed on a branch.

B

Yeah that wouldn't surprise me, because I think I think you mentioned that you'd actually done it and I just think it. Maybe it never got into a pr.

D

Yeah, so it just um just does like a checksum.

D

A

D

Then I put it on the store on the config map itself and on the sorry, no story on the start on the feature feature flag, configuration right, yeah so in the future, configuration and then inject it with the config map into the deployment on the deployment yeah.

D

A

D

Trickier um because the we don't own the car, we don't own the deployments right, we're not. We don't have an owner reference on his deployment, so we have to scout in it's fine, but it's just as you scale the cluster out that becomes quite intensive scanning every deployment in every namespace for that annotation for those levels.

B

Yeah I mean I mean, maybe maybe that's not something we want to do. Maybe if the only reason to do that is to is to lower the reconciliation time. Maybe it's not something that's worth doing. I'm not personally of the opinion that we need to have flag values be propagated faster than a minute. um I don't know if other people disagree like. I think, if you do need that, maybe you should again consider a vendor.

B

D

I think we definitely, I want to aim to try and lower it as much as we can, because that is quite slow, but, um let's just see I mean I was seeing 20 seconds 30 seconds when I was doing direct.

B

I mean it depends on when you do it, you can hit it just wrong and it takes about a minute where it becomes slightly. Annoying is, if you have multiple pods, you can see it basically slowly roll out and that's that's because a bummer like a minute's, no big deal. But if it's 10 seconds between you know.

D

Almost thomas did add some code in. I wasn't super sure about she. Does this back off retry and the operator? Actually it does a does a exponential back off, so it might be hitting one of those and it's increasing the retry loops. So.

A

D

B

Yeah when I, when I like it just as an experiment, I added a whole bunch of replicas to our workload and it's interesting what the delta is so and maybe it does have to do with that backup retrieve because it seems like there could be a very fairly large delta between the first uh workload be having its config map, be updated and and the last one. But again I I'm not convinced any of this is like a huge deal. Breaker for the.

D

um I think we're getting to a point where we actually need some user feedback as well on this stuff. You know to really decide that.

A

B

That's true, you're right.

D

What's the um what's the timeline, I mean, I haven't attended some of the other meetings, but what's the timeline on sandboxing.

D

So what how do you mean so is it been accepted yet a sandbox.

B

Yes, yeah, I'm just filling out the paperwork. Now I've been in europe for two weeks, so it's slightly delayed. But when I get back it's gonna, something I knock out, but yes, it has been accepted uh and then, when it comes to spec and some of the sdks um we're pretty solidly in alpha now and we have uh java and net in a pretty good state right now, um I think go won't be too far behind.

D

Java and javascript.

B

A

D

We, I think, maybe then from like the flag b perspective in the operator. We need to just really really focus on kubecon to get good examples like more good end-to-end examples, and so maybe the thing we should do is um harmonize on the next sync provider. We end up building or that's our next service next service provider we end up exposing, I mean, maybe.

B

Something infrastructure could be really cool. I mean that that is just such a new concept. To some extent, you know that it could be a pretty cool. You know proof of concept. At a conference like kubecon, I I mean actually maybe doing routing with nginx is a good use case, because it's in lua um and lua is not a not an extremely popular language uh and we could easily write a lua provider that would just talk to flag d, and then we could do some like. Maybe we could find some interesting routing.

D

I would like to. um I would like to write an admission controller that has flagging, enabled to check to be able to turn on and off the ability to do cosine checking um in queue, because I think cosine with sigstor is a very hot topic and I think q is a very new language, so actually having a dsl. You can mount as a config map that could be an alternative to just json might be interesting.

A

D

Is it is it you know we could? We could translate the schema spec to q as well, because q is a superset json.

B

Right, yep, yeah and- and I think like that whole um that whole eye evaluator, I think it is- is the interface. So you can really plug it with anything. So you could easily implement a q1 which, which might might be more like cloud native than json and maybe like more attractive. So I think we could plug in anything. We want, maybe even becomes the new default. I think.

D

It would definitely get a lot of interest because q is such a um an interesting language to people.

B

Yeah yeah I'd be excited to see that so, just to kind of summarize that you know it's uh the the mission, uh the mission controller, to toggle, what exactly.

D

So um for a q con demo or a demo generally, I think it'd be interesting to have the ability to show some sort of infrastructure capability, and so to do that, you could write an operator that has an admission controller so, and what would happen is that it does what we do in some ways: it scans the pod spec the object spec coming to the cluster. It looks at the image and if you flag the feature on it, doesn't just look at the image.

D

It checks that the image has the metadata of cosine the public key. It's a gp gpg key.

A

D

It validates that that is a signed image. It's a new it's worth. Checking out six store is a project that has just been um adopted by kubernetes upstream.

A

D

Images now have the metadata that contains the public key of the uh gpg key yeah.

A

D

What's interesting is now, you could then say only allow with a feature, flag images that are signed and we could demo that pretty easily.

B

Yeah, I can't I can't wait till we can do signed, helm, helm artifacts. I don't think that's a thing yet, but I could see how I could see what you're talking about would be useful for everybody.

D

That's coming from a lot of vendors very soon. Actually, that's.

B

Great um but yeah that sounds like a really cool demo and I think, like all of the subject matter around it seems really hot and interesting to talk about kubecon. So I I like that idea. A lot.

D

A

I put a um should I.

D

Put an issue in the research repository or something like that, and we can talk about it more there yeah.

B

That'd, probably be perfect, I think dan has to drop. Was there anything else? You wanted to add quickly.

C

Yeah, just before I drop off 424 what we were mentioning with nginx todd we'll want to check, because I know one of the things we ran into was lua can't make network calls.

B

C

In the hotpath so definitely.

A

Make sure it works.

C

A

um If we run into it, because.

C

It's loaded locally in memory that it works there, but there are some kind of restrictions with the scripting.

B

Okay, that would that would make sense you probably yeah they're, probably heavily restricted actually well, it sounds like I mean, maybe I'm not sure if lua will allow you to do like uh like if well, I'm not sure if a framework allows you to do in a different thread like some kind of other. Maybe it does can do some other kind of polling, but if it can't, then that's just a that's, not an idea we have to implement.

B

I mean alex's seems to kind of hit the mark in terms of a cool infrastructural, hot topic anyway. So.

D

Okay, I'll write a quick um issue up and we can take it offline and chat about that. Perfect cool.

C

I need a job have a good one. Everyone all.

A

Right thanks man.

B

um Lars yosa uh have anything else specifically to add or any questions. I know it's probably a little off topic for your lars compared to what you're probably expecting, but.

A

I think it's very very interesting also to see where, where the journey is going so also also being open to completely different use cases than than the usual one. So I really like this. Okay.

B

Perfect yeah, it is pretty interesting. I think that that's why we kind of split the meetings off too. It's like this can be very specific, for you know some of this maybe infrastructure and like the flag, d processes and kind of some new ideas there and the other one's more around, like the spec itself and kind of defining that all out so both are progressing pretty nicely, but they're, pretty distinct topics.

D

About um uh the logo situation.

B

No I'm glad he brought that up. Actually, that's a good point. um I I like have been I've had that on my brain for a while, I kind of I gotta say I really like your idea of doing like a um a contest I would be down for that. I don't know um it would be cool to have some kind of half decent prize, but yeah I don't know alex, is going to personally build and ship someone like a raspberry pi, kubernetes cluster.

D

And you know what it's funny: I've actually got one ready to go. I got one right here I got. I gotta go with the next cube con.

B

Will you sign it for.

D

I've actually got a couple of those just hanging around but yeah. I I think um to your point. It is hard to find a good prize. That's not going to cost huge amounts of money. Maybe we could get it sponsored or something I don't know.

B

Yeah, I was somebody had mentioned that internally, like I I don't know we could. We could put some feelers out in dino trace and see. If it's possible, I mean it seems like a yeah.

A

I mean as long as it's not you know, insanely.

B

Expensive, just kind of a and.

B

Yeah, I think that's good, I mean we could start there. If it's a flop, then we make our our own logo so uh yeah uh I'll. Take that as a an action item then see what we can do on on our side. If, if you know anyone at canonical that feels like getting involved too, uh certainly let me know, um but it probably isn't too difficult to find. You know some someone to sponsor a 50 prize or something and oh.

D

Yeah, I I I don't think that would be too hard.

B

Yeah, if anything, I think the more difficult thing would be. um You know trying to get making sure that we have enough participation within the community and that there's also like even outside of our community so far, it'll be a good opportunity to involve new people. Also.

D

Yeah for sure the ultimate prize I can think of um would be like virtual or you know, some sort of conference ticket or something like that. We have we get loads, but unfortunately we're going to use them because we send like 30 people every year, but I'm just trying.

A

D

Think what we get for free as sponsors that we can give to people that they might enjoy. You know it.

B

Can be vip access to the uh open feature party at cubecon? You.

D

Have open feature swag.

D

B

Send them some stickers so yeah. uh Let's think about that. I think that would be kind of fun like why not we can give it a shot. If it doesn't work out, you know no loss, there really yeah. So maybe we could have something by by next week community meeting, and that would be my goal yeah. If I could have something kind of prepared, we could mention it there and try to build some buzz around it. Try to get some people.

B

I think we also probably want to create an issue for that, then, so we can basically say like here's, the some ideas kind of the requirements and whatever I can link.

A

To that issue in community.

B

Maybe yeah alex, do you know if there's any like precedence for that anywhere? Like have you seen this elsewhere? We could maybe just kind of see you know, because there's probably some kind of like legal, disclaimers and stuff, we would have to make sure we.

D

B

For like running a like, I don't know a open source contest of some sort like.

D

You know the the more I spend time in these communities. The more I realize it's sort of the ask forgiveness model.

D

Yeah just do what they want and like they, they sometimes get reprimanded. No, I I don't know. I am.

B

I'm I guess the only thing that we should we could be. You know when we set up the the thing is that it's going to be it's going to belong to open feature at the end of it right.

A

It's actually the linux foundation.

D

The linux yeah, the cncs section, make sure that I would. I would make the thing a google form right, you'd attach it and you just say it be in the form please. This is the. This is the agreement. This is the license just so you know, you know, and you know just link to the um the the contributor covenant that people are expecting, because we've got that in now as well. Don't we.

A

B

And that's probably also another reason to keep the prize money low or not money, but like a of low value, um obviously probably getting the weird like tax and other issues that I don't feel like dealing with so um yeah. I know I think that that's that's cool it'd be fun to get people involved in that you know all right, any other topics. We should chat about.

B

Perfect, I guess we can go ahead and wrap it up all.

A

B

Sounds good thanks. Everyone thanks guys.