Open Feature Project, 14 Apr 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: OpenFeature Project Meeting - April 14, 2022

Description

Bootstrap governance Board, Technical Steering Committee, Update on latest state of the SDK research repo, Specification Work, Open Telemetry work, provider generator, PR announcement.
Meeting notes: https://docs.google.com/document/d/1pp6t2giTcdEdVAri_2B1Z6Mv8mHhvtZT1AmkPV9K7xQ/

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

A

Hey, can you hear me okay,.

B

Hello, yeah again sounds great for, for once, linux worked.

B

B

Good morning, good afternoon, everyone uh good to see you, um let's just go ahead and jump into it, uh so kevin had volunteered to be described for today. Is there any volunteers for next one?

B

It's a pretty high pressure. High stress position, so you know be careful volunteering. Anyone I'll take it next time perfect. Thank you very much all right cool, um and I guess that is really it here. I guess the um it looks like according to the agenda, the results from our doodle was in and basically the meeting time will stay the same, at least for the time being, we may have to slightly adjust it to support other time zones periodically, but I think overall we'll just stay with the same schedule.

B

So hopefully people are good with that um and then it looks like olog has the the first agenda topic.

C

Maybe I put it uh last time: okay, it was.

B

For the governance.

C

Stuff, uh yes, so, basically, my question uh to the team two weeks ago was whether we're ready to press it with the governing board and we discussed a few options. Synchronously several people stepped up. So basically I wanted to press it on this topic and at least start defining board members so that we can have operating governance model.

C

We haven't been yet attributed by the cncf, but this part would be quite important for the review, even on the sandbox stage.

C

So um the thanks to everyone who responded so basically yeah I'll, just open the meeting notes and uh put my proposal there in terms of names, those are stepped up and again nothing is really isolated in the stone. So right now it's just a conversation and we can either agree or not on names and nominations and self-nominations, uh but yeah. I think that we could at least started so that we have more people on board. So just a second I'll find my list, which is just someone's luck. I guess.

C

Yeah and uh also one related topic, I uh submitted uh my proposal for the technical student committee, uh so basically it's rather nominal role in the current definition about facilitating things reviewing things, but still the feedback would be appreciated.

C

If you want uh to move forward with this student committee, okay, so I have access to the document and yeah. Basically, what I wanted uh to propose uh is so that maybe I could just.

C

So for the governance, uh uh the proposal uh we had uh is so once uh we discussed um that uh second telescope, sorry, you know it took me some time to catch up with all my windows. Okay, uh this my screen, uh okay. So this is a proposal which we tended uh really agreed on last time we met so basically I guess, michael and pete said that they would be interested right.

C

So what we have uh so we have one slot which is currently open, so people we talked to basically raise the question uh whether the diversity of the board could should be considered, but uh right now we don't have the seventh member identified. So if somebody wants to step up it's a good opportunity, maybe one comment.

D

From my side, I think we should only have like a person from dynaface in there. So if it's between michael and me, I would volunteer for the time being, because we want to like really everybody be properly represented here and an equal representation of like dangerous implementers and end users would at least idea do we have justin in there? Obviously, we have okay in there.

C

uh So yeah basically chata allows multiple representatives from one company unless, uh as long as it's less than 50 but yeah, we can limit to one member from any company right uh in this park. I see no problem with it. So basically, if you and michael agree, then it could be just one of you.

D

Yeah I'd rather uh open that seat to somebody else in here.

C

So, michael foreign yeah, that's.

B

C

Which? Michael.

D

Oh, my baby: okay.

C

Sorry uh yeah, so basically it leaves us these two slots, but we can proceed even with five members now uh so that we initialize, and then we have a few more weeks to find the remaining two uh mainly based on the new companies and interested parties who join, but at least with five members. uh The board cannot get the rate according to the charter.

C

So as long as what number it should be fine, okay and for technical steering. uh So basically what we discussed so just to have a group of three uh contributors.

C

uh There is a pro proposal submitted in the pull request, so basically membership or in the technical steering committee doesn't give any special permissions. uh Instead of that it basically well. Basically it's a formal role that says you facilitate all kinds of decision making for specification for other technical parts and, of course it's a public role, but at the same time it doesn't strictly get any permissions, because the decision making happens according to the recommended process so through the same kind of consensus of contributors and yeah.

C

The question to the team is whether we want to have it so one of the reasons to introduce this role was firstly to follow the patterns of other projects, so open telemetry has technical steering committee and many other incubated projects.

C

Also, it allows to have more people on board in terms of official roles, so it's one of the opportunities to actually have more interested parties and end users, company contributors to be represented in the project officially, so the idea was to just start from three people, but we can also grow, and the proposal on the table I have is basically taught steve arch from cloudbees and dan o'brien. So basically, it has two more companies to the governance model.

C

Question to the team: does it make sense, and if so, are you fine with these nominations or would you like to grow to five people? Consider other people.

E

What's if we like, is this like a a point in time where we have to lock it and then we can't add more people, or can we just say now and add more people if we find more people.

C

So we can add more people. I think everything right now is a moving target, so for the governing board there is expectations said that the board will be converted to fully elected body within two years with half of the board being collected next year. So basically we start from bootstrap identified by interested parties. We have at the moment basically people on the call and who participate synchronously, and then we start with formal elections and for technical steering committee. It's basically the same, so we have three people struck. Then they can step down at any moment.

C

We can grow it to five if needed and later within one year, we will still reappoint.

D

Them yeah, I think, uh starting with three for the time being, might be fine and also like, as we wrote like language, sdks and others, new people might come on board.

D

At the pizza point, we can easily like elect somebody else um right now. It's just a more bootstrapping type of approach because, as you usually want to have people being at least in maintainer status, or have a number of significant contributions um available, um that like right now, obviously falls under the table, because how would this work in in the bootstrapping mode.

C

So, while we're in bootstrap, everything is a kind of moving target but yeah, I think it's important to start early so that again, since you have, I will ask about that. We can actually. We already have a lot of changes coming in the specifications of people who are more or less responsible to coordinate reviews and decision making would be really important in the current stage, uh just uh to make sure that nothing is stuck and yeah. I think that it would be nice to initiate it.

C

Okay, so if everyone fine uh yeah my question regarding the names, are we fine with uh this bootstrap governing port? So I guess everyone explicitly declared interest or confirmed uh so, if you're finding, we can press it with this body and for the next two seats again. We have then, a few more weeks to make eliminations to talk to people.

B

Yeah, that sounds reasonable. I think leaving a couple open makes sense if someone wants to throw.

E

B

Know get involved, there's certainly opportunities, then, so I think that makes sense to me.

A

Yeah- and I think that one one thing was mentioned- the asynchronous meeting was um as much as possible: let's try to emphasize uh diversity, not just of like company.

E

A

Coming from, but also of identity, so let's try.

E

A

Try and do it again there it's not always an easy target, but.

D

Yeah, I think this might actually get better as soon as the project has more traction. I mean right now, like creating massive diversity. Amongst the team. Here is a bit hard, and so they pointed out that this is hopefully is it going to change? Yes, as we see more project and more momentum on the project.

C

Yes, so then I think we can agree on this list, so I can uh basically next step. I can just uh put it uh to the chat. Is official proposal maybe give it to timeout something like a few days uh until we have consensus in the chat?

C

And basically, if you have consensus there, then the decision is made and we will just put the dates so that we have a baseline.

D

We also put it into an issue or like because then people also can say that they're like agreeing with it more formally, okay documented just yeah and link people. There.

C

Okay, so basically a github issue is plus one minus one of those yeah.

D

C

D

Like that, amongst the initial team, okay.

C

uh I will do that tonight.

C

Okay, then we can uh proceed with that and thanks to everyone who stepped out and that everyone appreciate the feedback, because it's important nice stone and happy to move it forward.

B

Yeah perfect thanks for help driving that um todd. It looks like you're up next, you ready.

A

Yeah, I am um okay, so before I share my screen, uh what I'll be sharing is kind of a uh moving as quickly as I can through a lot of the most recent uh research that took place in the sdk research demo with demo repository.

A

um So, as you guys know, this is not official code, but it has been really useful and elucidating all the parts of the api um that need to be defined in terms of what we want application authors to be able to do, but also the integration points across various vendors. So I'm going to be kind of going through the latest iteration of the interfaces and the apis.

A

uh Most of this is reflected in a pull request that I have linked in the um in the document and then I'll finish up with a quick demo. So I'm going to be moving pretty fast, um feel free to to stop me. If you have a question but again pretty much. All of this is is documented and also available uh in a pull request, so I'll go ahead and share my screen.

A

Okay, so um yeah first thing is uh we added a few things to the to the readme, so a lot more information on the demos that have gotten out of date, but also this application author api? So if you check out the glossary again, the application author is a feature flag uh user in the sense that they're, mostly writing application code and they're concerned with what justin has referred to as pivot points in their application logic, which I think is a great way to talk about feature flags.

A

um So yeah they're not really concerned about the backing system, the feature flag, control plane: um they don't they don't really care about how these feature flags are evaluated. um So this is the api, that's most important to them. uh The part of the api and the sdk that's most important to them. So I just have a quick overview here. You can see you know going from a very basic boolean flag, evaluation to more complicated scenarios.

A

So take a look at this if you, if you haven't yet it's a fairly decent overview of the current uh state, so the next thing to move on to, we did have some changes in our uh provider interface.

A

So this is the interface that um feature flag providers feature flag, vendors feature flag services of any kind need to conform to to be able to provide the feature flag, evaluation data to the application author, um so the biggest change we made recently is that the evaluations you have to implement um are now a little bit richer. So, instead of just returning a flag value, they return a more complex wrapper object: the provider evaluation interface.

A

Now, obviously, the value is provided, but there's some additional metadata, and this is really useful for understanding why future flag evaluation proceeded in the way it did so again, you know: there's there's error codes. If there was an error, um there's a reason and we're working on the semantics around reason, we may not actually want to define any semantics for a reason with an open feature and instead just pass on whatever the underlying provider exposes.

A

um We may want to do some mapping between a well-defined set of reasons and open feature and then map those to to provider reasoning.

A

This data is not provided by every single provider, um so it's kind of best effort, whether or not this is defined in every single call again. Keep in mind that when I, when uh the application author is actually evaluating flags, they don't have to concern themselves with this information. So they can just do a basic call to get the value of a flag. But if they are interested in seeing um more details, they can call a more advanced, a more detailed method to get a lot of these additional reasons: error, codes, etc.

A

It's a little bit more of an advanced use case and, like I said again provided provider, this data may not all be available, um and hopefully we can move towards uh more enriched data from all providers, as you know, as we move into the the future of open feature and ideally, better vendor support.

A

So the next thing I think to talk about uh really quick is: we do have a new provider. We added uh there's two versions of flagsmith uh the flagsmith provider. um One thing: that's uh one thing that's relevant here, um I I guess I I could go back to the uh provider um implementation too, that I was just mentioning uh in addition to these more rich methods.

A

We also introduced the contact, uh the concept of a context, transformer.

A

So a context transformer basically right now is a means to adapt the arbitrary attributes that open feature exposes in flag evaluation in a way that the provider understands.

A

So the provider can define this itself in its provider implementation or it can actually accept this from from the uh from the integrator who sets up the provider and they can do their own custom context transformation.

A

But this would say: map attributes like a user's ip address, a user's user identifier to attributes that are maybe maybe rigorously defined in the provider. Some divider providers have definitions and fields for these things that are well understood. For example, launch darkly um has uh has some predefined um attributes like ip address email address, um so this that mapping takes place here.

A

um It also in the case of flagsmith, for instance, there's some side effects that actually take place so um when, um when the context is transformed in the concept and the context of flagsmith traits are set on the user object, that is, that is cached in the flagsmith sdk. So that's a detail. That's an implementation detail from flagsmith, but I think what I wanted to highlight here is.

A

We do have this kind of nice concept now around a well-defined way of transforming the arbitrary user attributes that come into feature flags to the user, attributes that flag providers might be interested in in a way. That's kind of kind of well defined and um uh you know, can be controlled both by the uh provider implementer um and even the feature flag user. If they want more specificity.

E

This is all available.

A

E

Is is the is the thinking that just just like, so I understand it's a thinking here, mainly essentially to make it easier for those flag provider implementers to just give them like a here's like a standard pattern for implementing a provider or or is it more for um the application?

E

Oh gosh, I can't remember the the glossary now but like the person who's setting up yeah, not the author, but yeah person, who's like works at the company, that's using the thing, the.

A

E

Think is what we've been.

A

C

This is probably the name.

A

E

With um so so yeah yeah- I guess I'm just wondering like like, because because I'm thinking like in general, with the like the first version of this thing, is like there's a there's. This, like line, that we're walking between trying to make it rich and complete versus not kind of like um kind of like guessing at things that we think will be useful, but we don't really know until people kind of start building it. You know what I mean.

A

Yeah- and I think the the thing that the thing that you're hitting on is that um we definitely want to strike a balance between complexity um and and power, um so the contracts, the context transformer, is not something that um needs to be supplied by the application integrator at all. um They can completely ignore it, so it's optional, where it's not optional is for the provider implementer.

A

That is where it must be done and, and the reason is evaluating traits on a as part of a flag evaluation is part of a rule, is a first class use case. Every single vendor needs to be able to say here, here's a rule, I'm defining and based on this, you know attribute coming in for this black evaluation.

A

I want to differentially render a different result, um but because all of the underlying sdks require that attribute data to be shaped and defined.

E

A

Ways there needs to be a way that the provider can say: okay, based on the open feature, context which is coming in. I, as a provider, need to structure this data in a way that my sdk understands, but.

E

In in theory like, if, if this thing didn't exist, then each provider could kind of realize that themselves and kind of do it their own kind of custom way right like it. Doesn't I guess what I'm I guess.

E

What I'm getting to is like this seems like a really like a nice utility to provide to to to give to someone who's implementing a provider, but it doesn't necessarily need to be part of the spec right because um they could use it or not use it, and um we wouldn't necessarily need to nail it down and then kind of like if we need to change it, be like oh crap. Well now we need to like do a new version of the spec.

A

Yeah, it's, it provides a structured. It provides a structured way to do that um because of the way some of these providers work with underlying caching mechanisms um and things like that, basically state that exists outside of the context of a single flag evaluation it. It does make things that would be particularly, um not performant possible and it also increases type accuracy within the provider.

A

um So yeah, I I I I see your point. um We could consider kind of relaxing this or not providing it, um and there certainly is no need to do it at all. Like I said it is optional, you can, you can have a no op provider, I'm sorry a no um context transformer, um but these are all really good points. I mean there. There is certainly a risk at uh at over engineering um things early. So it's it's certainly a consideration.

A

uh Yes, a great feedback there there is. um This is already committed to the repo, but if you'd like to open an issue to discuss this further, I definitely encourage that. I think it's a great point.

B

So one of the considerations, though, is like in and todd is actually and that's I think a discussion point for later is the difference between context and attributes and what we want to do there, but basically, at the end of the day. um Imagine if we had you know a context uh that was a user id or user identifier and we call it. You know I don't know user id or request whatever we wanted to go with for that. Each back-end vendor uses a different value for that.

B

So even like the most basic scenario here, this transformer could just map it to.

E

B

The expected value is so that was kind of the core use case here and um I think it it's kind of required, but how we would define it in the spec, I think, could be. Definitely uh you know open for discussion.

A

Well, to pete's point I mean the way that that that problem could be handled would be in every single one of these evaluation methods as an alternative. So, instead of instead of exposing a transformed context, the um the provider implementer could, at every single method, do the kind of transformation that we're talking about. um That is true. I I think that um I think it's a great point whether or not we want to be this prescriptive with how we do context transformation.

A

um There is some, like I said, there's some stylistic benefits to defining it and there's probably some performance benefits to defining it. This way, but point taken that we may want to keep things lacked. So I think it's a valuable discussion and a valuable thing to consider.

F

Yeah, I also want to understand a bit more in the future for like at least for launch doctor. We consider where you can have some attributes private so like it sounds like I p address here, maybe like a default value getting passed in, but I don't know if we want that for everyone. You know, because some people don't want that as they consider ip address identifiable information.

F

um So we'd want to understand a bit more around how all that mapping works.

A

Yeah, well I mean that's a great question and to be less abstract, you can see the implementation that we have for the current launch, darpa provider, which is very basic, um but by default it maps in all the attributes as custom.

A

That's not that's, probably not ideal, but it's because we don't have a well-defined context, object for um open feature. Yet so obviously you know there's default attributes here like ip address. This exists in the launch darkly user right, so we could do something like context dot ip were it actually defined in in an open feature, context um object.

A

The thing is um to your point: dan is that this is the default context transformer on this provider. So there's a number of ways that users could customize this behavior. They could extend the the open feature launch darpa provider. They could as an option, actually specify their own transformer, which is how the api works now. So you can kind of ignore any of this data you can override it or at any of this functionality you can overwrite it. You can hide things you could.

A

You know ignore the ip, um but in the basic default implementation you know right now, because again we don't have the strong, strong definition for any of these attributes in open feature. We just take the context, that's being passed in and throw that all on the launch. Darkly custom attributes object. I hope that makes.

F

A

Amount of sense.

F

Yeah definitely I appreciate the walkthrough on it.

A

Yeah and please go ahead and take a look. I mean this is a very naive implementation just to get the idea across, um but uh I I hope it. I hope it does. That.

A

Okay, so um I think that's everything I wanted to talk about in terms of the new provider. Implementations last thing: fun demo, hopefully so yeah. This is the this is the exciting bit. We have a new demo called install it's somewhat contrived, but the idea is it's going to render and a simple html page I'll, show you the markup here.

A

um So we have an html page and it says: hey thanks for your interest in our killer app, we see you're using some os and you know please follow the installation instructions.

A

So it's very very dead, simple, um but you can understand how maybe, if you were a uh yeah, I'm using launch darkly for this demo. um I think I used clabvies last time so I'm trying to spread things around, but um we have a feature flag here. You can see installation instructions.

A

The interesting thing about this um flag is that it's actually a json object. So you can see it's basically fleshing out this template.

A

So you know again. If we consider the template, I showed you earlier. We see you're using mac os. Please download our dmg file. We see you're using windows, please download our exe file to install um that's the basic idea here. So you know a non-technical person could come in here and you know when um some other operating system is supported, uh they could add, say an android entry and then say: please visit the google app store, um that's relevant because.

A

If you take a look at what's actually happening here, we're taking a look at a particular header that most less privacy oriented browsers, I suppose, is a good way to put it send along with most requests. So google chrome will send this um firefox, uh I believe, sends it there's a few more lockdown browsers that don't send it, but it is a standard and it's basically a hint for a particular platform that the user is using.

A

um So we're sending this along with a request and we're going to use it to differentially, evaluate a feature flag. um The thing that's important here and this kind of demonstrates why context or attributes is important for flag evaluation. You can see we're pulling the set of the request context, we're creating an attribute called platform and we're sending those attributes along with this flag evaluation request. So.

A

I'm going to just run this really quickly.

A

And what you'll see is uh thanks for using our killer app. We see you're using linux. Please install our killer app package using your distributions package manager and if you look at what actually happened with the request, indeed, you can see we sent along a header indicating that I'm on linux, it's the header that we lifted now the other interesting things that are happening here. You can see.

A

I have a hook, so there's a a risk with this setup that a non-technical person could easily come in here and put some really invalid input in this flag value. So I could change this to be a totally embedded object where I've said. Okay, the value of the operating system is now one that doesn't parse, there's nothing about the underlying flag system that um being launched darkly here that understands that's invalid.

A

There's no schema here that we've defined or anything like that.

A

But what you can see we've done here is we've also added um a into our after hooks into our hooks that we've we've talked about in previous meetings, a very simple validator that leverages some a popular validation, library and node very similar to jax rs validators, if you're more familiar with java.

A

But the idea is, we have a simple class, we mention, and we attach this, and it has some validation annotations and now, when we run this demo again with the totally invalid data we can see. Oh the default has fired and series in windows. Please download our exe, that's the default, and you can see here that some property validation has has failed and that's just because we hooked into the flag evaluation life cycle.

A

So this is a really basic extensibility um concept that I think we've introduced introduced earlier, so we used it for open, telemetry integration and for logging I mean those are certainly very valid use cases here, we're using it for some very basic validation and I think uh that's a fairly cool uh use case. So this.

E

Is definitely one of.

A

The more advanced um usages of the sdk you can see we're we're getting an.

E

A

We're passing in attributes we're using those attributes to differentially affect the flag, value return and then we're doing some validation. So this is probably like a a full use case for for where we're at with the sdk development. At this point- and I think that's all- I have.

E

You can ask a question: it's kind of a little bit beside the point, I think of the demo that just kind of occurred to me that attribute that you're you're grabbing that header and then kind of like figuring out the platform and putting that into an attribute so that when we evaluate the flag, that context is considered in like a kind of like a more real-world scenario. We'd probably want to do that, like in some kind of middleware or some kind of like thing, so it's always done. What would that?

E

What would that look like for the um implementer, the the person that was? That was doing that wanting to ask.

A

Excellent questions, excellent question: that's a that's a fantastic question and you're absolutely right! So um we actually do have uh I have a branch locally. That's using um I'm not sure how familiar you are with uh node, um but uh there's there's an api node called asynchronous context, tracking um yeah. So this is this is probably the recommended way of doing this in in node and is equivalent to thread local storage and java yeah.

A

um But yeah I mean I'm sure you can see where I'm getting at here uh in the in the small poc branch. I have exactly what you described. There's a middleware. That's throwing arbitrary attributes onto this um asynchronous context and we're pulling it out later.

E

Yeah, that's the like. I started down the path of trying to use the. um I did a tiny little spike on using the open, telemetry um thing that does this and just baggage, yeah, no, not baggage, but like context or something.

F

Yeah, the open, inflammatory.

E

Kind of like thing that uses this, you know shove stuffing something in a span and then later on, it's it's kind of like available, um or at least it's recorded.

E

um I wanted to not have to, like my experience, is use going down to the level of node and like getting continuation, local storage or async hooks or whatever to work is a huge pain because you have to support a bunch of different versions of node and it's there's bugs and promises are annoying and javascript's a terrible thing.

E

um So I was kind of hoping that we could just grab open telemetry's. It looks like it has a really nice kind of like generic implementations like here's, how you would do something like thread: local storage, for a bag of generic context, which is almost exactly what we need. I uh I gave up after a while because I it was like uh I couldn't figure out all of the moving parts of how open telemetry does it. But um I think it's like, like my bias, is like as a person using feature flags.

E

This is like the number one kind of like convenience that that I want is to be able to have something at the front of the application or elsewhere shoving a bunch of context into the system, so that I can just so the application author can just ask questions and not even know like what context is being taken into account so like to me. That's like the killer.

B

Yeah todd had a really cool demo of that, and maybe we can push that up, so you kind of play around with it. I've also talked to the open, telemetry maintainers about this very thing and they've readily admitted that it's probably possible but not really well documented, and we may have to do some clever things because the way they deal with like immutability of that context, so I guess active.

E

B

Happening there, um another.

E

B

Worth mentioning sorry, go ahead! No! No! I was just saying oh.

E

B

The other point that uh we can just given the architecture of this, we could actually generate uh clients per request too so todd had another example of using dependency injection and it's basically a a new client would be generated per request and the reason we can get away with. That is because the underlying provider would be the singleton. So that would already like have the flag context and we wouldn't be regenerating it, which is the expensive part, and then you'd basically associate context with the individual like open feature client.

B

So that could be another alternative too, which is a little bit cleaner in some scenarios.

A

Yeah to elaborate on what what mike is saying, um it's, it's not just the context, but if you're using a dependency injection framework, it's trivially easy to inject any structure you like in in into your request handler so like if you use nest js or something like that, um those frameworks do allow you to say, like you know, imagine this handler had another parameter here. That was that was, like you know, context or whatever, um and it would be injected at the framework level and then you could inject it at the evaluation level.

A

um So that's one way to do it as well as into the client, but to your point one of the cool. The coolest thing is that even hypothetically, if you're doing this with um something along the lines of the async local storage, even flags that don't use um that, don't openly that you didn't write in third party libraries, you can inject context into those.

A

So if I'm using an underlying library that I have no control over the flag evaluation code in, but it used open feature, I could inject my context there with a zero interface of the library.

E

Yeah, that's something.

A

E

You can use the provider to kind of customize the library without doing any kind of code.

A

Yourself exactly and that's where the async, local storage and the thread, local storage concepts become really powerful. um The the the I totally agree with your sort of go ahead.

B

Just saying we should probably for the sake of time kind of move on from this one, but I think it's something that we can. Maybe you know, share your experiment and kind of chat about. You know asynchronously, because it's a super interesting topic, but we have a few other things to get through. Definitely.

A

B

A

I guess that's it for me. Unless anybody has any questions, you.

B

Have one more item on here talking about the context attributes.

A

Oh yeah, I guess it's a good sideways so um specifically before, uh because of the reason that context is a fairly overloaded term. um It's used natively for something like async local storage.

A

In go, uh it's an open telemetry, um it's obviously a first class concept with a lot of I'd, say a lot more power um and a lot more surface area than our our kind of concept of attributes. I'm kind of proposing that we actually move away from the word context and shift towards attributes. So we can call the flag, evaluation, attributes or or attributes in general, um but I'm I'm going to make a pr to the glossary and feel free to agree or disagree with it or add input.

A

That's going to suggest we move away from the term context and towards attributes or long-form flag evaluation attributes, um so yeah I'll open up that pr later today and feel free to weigh in on it. That's that's it thanks mike and.

B

Then we have the quick teaser for the spec work. That's your last uh action right.

A

Yeah, so I I guess that is not really related to the sdk update um the. I think the theme of the meeting today that we might keep coming back to is we're kind of probably finishing up a lot of our research phase and more moving into a spec phase, um so yeah. What we're kind of starting to do using some pretty cool tooling that was developed from some of the open telemetry folks, um is come up with with uh our first crack at an unofficial.

A

I don't sorry, I had an official spec, be it experimental at this point um so with that we're really looking for volunteers to write compliant sdks in various languages. um Obviously uh you know java go.net all important targets at this point and for people to weigh in on the spec as it grows so more to come on.

A

That probably will mention that more next week and maybe even demo, some of the tooling we're using- uh and I think I think, just in abrams- I believe that there was even a thread where um he had made some really good observations about how a lot of this might be translated to java. So that's exactly the kind of input we're hoping to to get as we move into more of a spec building phase um yeah, I think it'll be reasonable.

G

To pick everyone pick a language that they're familiar with and try to implement at least the the client side version of this, the like the application developer side make sure it feels right.

B

Yeah, perfect and one of the recommendations from the open telemetry side actually was to make the spec uh open to basically taking advantage of the language itself, so not prescribing anything too specific that makes it like sort of tedious to use in a particular language. So that's just something I want to keep in mind as we're we're defining the spec cool thanks todd. um I have just a few quick updates.

B

um One is the hotel update, so um I've updated uh todd's branch actually to take advantage of some of the hotel semantic conventions that we proposed. The two items that became tricky was the concept of a variant, and that becomes important, especially when you're dealing with basically kind of like non-boolean values, especially around objects figuring out.

B

What we do uh you know into justin's point really you're likely not going to want to just dump an object into you know telemetry data or something it's not that useful it'd be better to map that back to like a variant name. That is not a consistent concept across uh vendors. At this point, um even in something like uh launch darkly, which does have it, it actually comes back as an integer which we then we just cast to a string.

B

It's okay, you can figure it out, but it'd be better to have like a friendly name associated with that.

F

And that also uh is a point in time. Unfortunately, for that because like if you move the you know, if you actually change the variation values you're only looking at that array, so it's not a reliable piece. It's not like a key. That's immutable.

B

Yeah and I think from like a telemetry perspective, it does make a little bit more sense because you can like start splitting on those values and things like that, so just something to keep in mind as we kind of move forward with that, the other one that was really tricky. In fact, I didn't even really do.

B

Was the management url so thinking how nice it would be in like an observability tool to see a flag evaluation and be able to click a hyperlink to go back and like see that flag configuration um almost all sdks do not provide that some.

B

You could probably sort of infer it based on the data you have others use like goods and stuff so trying to figure out.

B

You know, of course, that's an optional attribute, so it's not something we'd have to provide, but um you know I would definitely encourage vendors to start thinking about how that could work, because I do think that would be super useful information to provide in the trace next step is uh we're starting to, I think, come to an agreement on that, but maybe take another look at it see if the the most recent proposal makes sense, and if that does, I'm gonna go ahead and open a pull request and open telemetry um just to get that process rolling uh next item.

B

Last time we talked about you know being able to create your own providers in our experimental branch. um I did create a generator now, so it's just a simple nx generator. You run a single command and it spits out all the scaffolding that you need.

B

So I would encourage you to if you haven't yet check out the experimental project and just run the generator play around with your own provider. You know test it out, provide feedback, but it's a really nice way to kind of handle some of the boilerplate stuff. For you. uh Next item was a cloud native implementation. That was something we talked about.

B

I still think it's kind of an open item and something we're going to want to probably continue to chat about, like our messaging around that to some extent, I think it's a pretty important concept, because I think, as uh as more and more people move to more cloud native environments, offloading flag evaluation to either a service or a dedicated process may make more sense, architecturally, and so I think it's something we want to keep uh keep track of in the spec potentially.

B

But how that breaks down is still, you know, definitely open to discussion and, as part of that, we've started to consider uh what it would take to do a proof of concept, ideally to have some kind of demo ready by kubecon eu. So if you have any interest in being involved in that, you know, certainly let me know, but that's something we're going to try to pull something together, just to kind of get a sense of of.

B

Does the architecture work where you know kind of the gaps um and- and you know give us something to work off of so that's something that's kind of under active development right now and then, lastly related to kubecon. uh I know a few of us will be there um if you're gonna, you know if you are going to be there. I created uh a google form, so please fill out some information there and we'll try to schedule some time to meet up and eloise volunteered to pay for some t-shirts.

B

So uh put your t-shirt size in there too, uh and we'll get those printed and handed out. So that's it for me um that looks like that's it for the agenda. I don't know if anyone else has anything to add, but yeah. Please feel free.

D

Yeah, maybe just one more item: last time we discussed about like having a gay pr or blog announcements or whatever it's eventually going to turn out to be. We talk to our internal teams and we should have something available for you by next week.

D

So we will post a link to the document out by next week, again usual approach like there's some shared text in the beginning, and then you can put in whatever, like you want, what best fits you and obviously, if there's anything in there that you don't like um yeah, then just say that you don't like it basically and obviously think about like a quote. So we will have different quotes available that people can use, as um it's part, of the like um pr and other topics as well.

D

So think of who could be a good person to have a code or if you want to do one with yourself uh that people can use that we can throw them in but again more next week. So there's a lot of easter holidays going on right now over here and that will end by next week, tuesday. So that's what I'm expecting to happen next week.

B

Perfect thanks ellis anyone else.

D

Yeah, I have just one more thing: didn't we like two meetings ago, we didn't like justin, offered to talk about what they actually built at ebay and we never got back to him. I wonder what we did deliberately didn't. Do it because justin wanted to take more time, or we just forgot about it,.

G

Yeah sure, but I can spend four minutes and talk to talk to you about what we're making yeah. If you don't mind, unless someone.

B

Else says something.

G

So we're building feature flags internally to ebay um after some vendor analysis.

G

The big the big sticking point for us was: we have an already home built experimentation engine and we couldn't figure out how to get external vendors to work in a good developer.

G

Experience as you migrate from feature flag to experiment, so we're building um audience aware, feature flags with a um kind of using the stuff that's available in the industry as a um as a guide, we're trying to track the um the spec uh we're not entirely sure where, along our roadmap, we're going to get it uh like when the spec stabilizes enough that we can like start writing against it, um but we're trying to like borrow some ideas from it and map our api to that api.

G

Even though it's a moving target, we are just now testing our first customers internally um and and getting feedback.

G

um Let's see what else can I tell you? Oh um it it currently works in um by making api calls for all flag evaluations, um which is probably not something that will survive for eternity. We probably will move to a local rule set that gets evaluated mechanism.

G

A

That's where we're at today, that's not actually entirely unusual. um Well, it's not entirely unheard of it's it's less common! It's a less common pattern and there's obvious limitations to it, but it is how um the the version, one of the flagsmith sdk, does work as well. You can't set up some caching to obviously reduce the traffic, but conceptually that's what's happening, so it was these kinds of different implementation. Details are why it's uh fun to attempt to abstract this in a consistent way across all different providers.

D

Yeah, that's, I think we should get alex back to that conversation at some point, because he had that proposal of implementing, especially the rule evaluation piece within web assembly, which would lend itself very nicely to being part of the sdks, because you could load it language, independent and evaluate at nearly native speed and even update at at runtime.

D

So I think that that might like be a really nice approach, because you only need to export pretty much. The interface like evaluate this for me and you can take your entire rule, set, compile it down to to web assembly and send it down and evaluate it locally for cindy iris, where you can do it. So maybe we can get him to talk about this, like how I thought that was working and yeah some people.

D

You know that I'm currently very much fascinated by what you can do with webassembly, because if you think it's with some use cases, but I thought the idea is kind of intriguing, because building like an evaluation engine in multiple languages sounds like yeah havoc to happen at some point, because at some point you will get at least one of the implementations not being compliant.

D

Simply because that's what we do, we write code as good as we do, but sometimes we don't get it like one hundred percent right, um so that might be also an interesting one. It gets sent down. But what I found very interesting from you justin, and maybe we could put this in some points into the docs, the difference between like the feature flag and the experimentation.

D

I think it separates also like what the back ends are doing, because if I understood it uh correctly like feature flag is the flag. The thing that you can turn on and off and experimentation is pretty much the rules that you that you apply when you turn something on and off right.

G

um So in in our version of the world, experimentation is statistical analysis based on some end state that we hope for and so being ebay. You can imagine, there's like hey when we flip this flag. Does money go up or does money go down um and that experiment like tracks fiscal significance and things like that around?

G

How did the money work um and there's like a bunch of like tracking stuff that happens to to fuel that and that's all internal systems.

A

G

A

Whereas the so the future flag is basically the pivot point in the code that that is the basis for information input into the experiment and the pivot point in the code could be an arbitrary split based on a percentage or based on attributes or just a boolean, or something like that. Yeah yeah and right.

G

Now we have different.

G

The current state of the world is, if you want to move to experimentation, you actually have to like replace all your code to do experiments um we're trying to make the experimentation sdk api compatible with the feature flagging sdk, because they're actually two different sets of code, um so that developers don't have to change stuff. Would.

E

You so would the end goal be the developer, like the application offer doesn't know, doesn't really know or care whether they're writing code for, like a release. Toggle, like you know, a dark launch versus a a b test that just.

G

uh Implemented, I believe that becomes more of a project, product manager, decision yeah as to like how we ramp our code and the important part for developers is like it's live. I can see it that does in fact work.

G

E

I guess an interesting test of the of the spec that we have is whether you can get people internally comfortable with using um that hook, concept to track analytics for an a b test, not just like open telemetry but like because because that's the thing I see most that's the biggest uh split, if you're pardon the pun uh between like um feature flagging, traditional feature. Flagging and like uh experimentation is where is like?

E

How much do we care about, like the like whether the experience data goes and like tracking, who saw what experience and I've never like? I've seen launch directly trying to get into the experimentation space I've seen optimistically trying to get into the future flagging space and the big difference. Is that experience, part or tracking who saw what experience.

G

Yeah in in the ebay world, a lot of that tracking happens um outside of the purview of developers. It's like. I called this api and magic happened and now there's a tracking event somewhere in some other system.

G

That says, like the header that came from the upstream request, had this user id and now that's in that thing and yeah a lot of like black box from my perspective um and that has pluses and minuses yeah.

B

So sorry to interrupt here we're just about out of time, and I think this might be a good conversation to pick up next time. So if you don't mind putting that on the agenda, it's really interesting. I think it does lead to some interesting questions here, um but yeah. If there, if there's nothing else, I think we can go ahead and wrap up just so we make sure everyone can probably make your next meeting that time so yeah any last thoughts.

B

Perfect all right, thanks for your time, everyone talk soon.

F

B