Continuous Delivery Foundation Events Special Interest Group, 31 Aug 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: CDEvents Working Group - August 31, 2022

Description

For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/

A

B

C

Am I audible, yes, you're, audible,.

B

Great andrea is writing in the minutes, so I expect him to join.

C

And here he is.

D

Hello good morning, good morning,.

B

Thanks for preparing the agenda.

B

I haven't been too too focused on this. Lately. Sorry.

D

Hopefully, you can see it yep.

D

Shall we wait another minute? Let's see someone else joins.

B

Well, it would, of course, be good to have some more people joining, but.

B

Have you heard from anyone.

B

um If they intend to jump no.

D

D

I guess we can get started as well.

D

All right, uh yeah so welcome everyone to the city events working group, today's august 31st, um my name is andrea frictali. I work for ibm and then you need to see plus one. Please redesign yourself in the participant list as you've done already, and the meeting is recorded all right uh so feel free to add things to the agenda for more things that pop up to be discussed, I started with a trying to collect action items from last meeting.

D

um So the first thing I mentioned in the last meeting that was spending was about the sdk go, so I didn't support for validating through the json schema um yeah. There were some.

D

I had some issue with the um with the libraries there on those side to achieve validation, um with some chat with ben offline as well a bit and finally found the solution, so that is done now.

D

um So it means that if you create an event for the glo sdk and then try to render it as a cloud event, it will try to apply.

A

D

Against the schema first.

D

Okay, um second item was adding json schema to the spec and I updated the pr there um and there are some comments uh from uml um and I think I put an item on the agenda later to discuss. Maybe we can go through those and see if there are also other things that we need to fix in the schemas.

D

So we can finish that yep next was adding the data field uh to the spec. There is an issue with that, but I have not worked in that, yet so no progress there.

D

um Next we discussed about adding version to the schema um as kind of specifying an enum with a specific version which is now done in the sd go sdk and see. I can.

D

The link here so it's done in the go sdk and the schemas are paid in accordingly.

D

D

And so where is it.

D

Right so the go library allows this kind of tagging of the ghost struct, so the json schema is marked as required and a num with one. Only one value only and the default is draft, and this is then rendered rendered.

D

In the json schema.

D

B

I think that looks good.

A

D

Next uh for the java sdk, there was an action to reach out to jalander and see if he plans any more java sdk work for the 0.1, but yeah yeah still have to do that.

B

I have had some contact with him always like on because he is intending to provide a presentation on the cd mini summit in dublin, and we have some discussions there, because he will. He will present a proposal on adding a um an eiffel integration to the the book.

B

uh That's something he has been working on, and uh so I think he has been mainly focusing on that, and I haven't heard that he's looking into updating the java sdk to the series 1 version. So he still lives with the old version that is used in the in the old book.

B

So I'm I would guess that he's not working on it for serious one. Yet.

B

But, of course it depends on when, when we release it 0.1, if he will be able to or someone else will be able to contribute that update um anyway, uh maybe we shouldn't have it as a requirement for 0.1 to have the java sdk there.

B

I think it's good to have.

D

D

Okay, does this make sense.

B

Yeah yeah, I mean, I think we three cannot say anything else, then it must not be a requirement, since we are not ourselves working on it, at least if it turns out that yelander someone else says that hey, yes, we will provide it or I will provide it or something. Then of course it could be added, but I think we can't say much more than this between us three here.

D

Okay, um next, uh in the last meeting, we had a discussion about the subscriber mode with consideration that was brought up by ben. um But what is the intent of the event uh if there are one-to-one or they're meant for multiple listeners um and.

B

D

We, I think we, the the action out of that, was to add a diagram to the specification and one of the existing diagrams. We have for the plc and maybe some more text to to make it more clear um what the intent will see. The event is um so it's just still an open item.

B

Yeah, I also know that you have discussions right on the cdcon. Was it in austin with someone? I don't remember where it was now on having uh prescriptive events or such so.

D

Maybe we should.

B

Anyway, clarify, I think that the outcome there was that it might be okay to send prescriptive events over over the cloud events, but they might not be part of the core spec right.

D

B

D

B

D

Like that, should.

B

Be written as well so.

B

So people thinking about that could get some answers if we are not available to answer them in person.

B

At least that's kind of related when it comes to broadcast or non-broadcast events or so on.

D

B

D

Okay um yeah. Finally, you bird out wrote up the topic. I know of having a poc reference implementation last time.

B

D

Sorry, um so we need to create an issue to practice work um at least and.

B

Yeah, I don't know, maybe we didn't really have time to talk that through on the last meeting enough, uh I'm not sure um the term reference implementation might sound uh very including, or what should I say, we're very tough uh yeah. I think what I was more looking for was more of a demo.

B

A simple demo: implementation for.

B

Showing how a very simple hello world event type would be sent more or less, and it doesn't need to be a complete set of events supported in that demo. Maybe, but it needs to be up to date with the spec at least. So any the structure of the events should be this correct ones. I think.

C

So questioner, um could the sdks serve that purpose, or is it some other thing you want.

B

uh Well, hi brad, by the way, welcome.

B

So well, of course, the sdks one of the sdks could be used, or maybe both I don't know or all, um but I guess this would be yeah.

B

Of course, some kind of simple sdk might need to be used, but the idea there I had was that we shouldn't need a full poc setup with applications like tekton, spinnaker, captain or whatever, but instead just a very simplistic cli.

C

B

Youtube or something uh so it's all very easy to show how to send events and how they can be listened to and what they look like.

C

So basically, some kind of getting started examples.

B

Yeah, I guess some.

C

Yeah, I guess that's one takeaway from from a full is that we don't have two goods getting started information, so people think it's it's difficult getting started. So if we can have, if you lower the barrier of of getting started with it, it's I think it's going to be helpful.

B

Because if the only place to start now is to look at the box to understand how it works in practice, then you need to understand spinnaker, captain, ortekton or anything included in the box.

B

That might not be the best starting point for anyone.

D

Cool um yeah, I I agree um with what you just said. I think it makes sense and I like the idea of not requiring any tool specific knowledge to to understand city events, um yeah.

B

Yeah- and I would actually guess that there exists some- I mean those of you who have been working hands-on with with the cd events over the year. Now I guess you have had some very simple event listener, or something just echoing out events to the terminal or something that so you see what has been sent from the on to the broker to the hosts or the server.

B

So there might be things already that are very generic and can just be used to verify that the events are sent.

D

B

Well, there might be existing tools in cloud events already that you can use. I mean some library. There are some some.

D

There are a couple of um tools I mean there is a. There is a cloud event player. That's uh a web ui, it's a clinique service! um So, but it gives you like a a ui where you can see the cloud events going through.

D

um There is another one, sorry, the name the name doesn't come to me, but yeah. I think it it's, as I said, or possibly developed by the cloud event. Folks as well. um Yeah.

B

Of course, those them will not parse the events according to our spec and uh pretty print them or whatever, probably recovered.

D

B

D

Yeah, it would be nice to have something simple specific to see the events. I think um I created uh an issue about that.

D

um It was one of the possible potential ideas for project um where we could spend the budget we had left.

B

Yeah right, I remember.

B

I think that the question is still up. We didn't get to it on the toc meeting yesterday, but I guess it's still there on ideas on how to spend this budget, and there are not too many months left of this year. So maybe that is still an option to get someone to to implement such a listener. For us.

B

Should we maybe propose that to the toc group see what they say if you foundation.

D

Yes, so I need to remember where I created it.

D

But yeah I will find the issue and.

D

D

D

B

I have to find it, but I can't it's strange anyway.

D

B

Oh there it is actually on the sig events ripple I'll. Add it to those notes.

D

B

You can go on, I can add it to notes.

D

D

All right um next, thanks next item on the agenda.

D

Is this pr? The schema.

D

D

So these schemas are generated through the go sdk.

D

D

You want some some comments and said I need to address those because someone wanted to discuss and make sure we recover everything. So.

B

um So I had there were two more comments which you commented and I.

D

B

The master sold, so I agree that we don't need to cater for those on this pull request, even though there are discrepancies between the documentation of the actual event properties and what we state in the json schemas here.

B

But that could be, you know later alignment request. I think okay, not not in this one, but some other ones that you that I yeah I marked as results. You don't see them in this view. I guess, if you need to go to the conversation, you have to see those other yeah.

D

B

Right so at one moment there at least you can see them later on, but you don't need to consider them for this pull request.

D

Okay, okay, cool yeah, so the first one- and I agree with you- I think um I need to update those and add them. Do you want them? Do you want me to do that in in this pull request, or shall I do it as a follow-up? I can do either.

B

Well, it could be a follow-up as long as we don't forget about it. I guess.

D

Okay, well, I can do it in this pull request. That's that's fine! So then type in content um all right, so these are matching what we discussed as a format, but it's not like very well written in the spec. I guess today. So I.

B

Think the only way we don't talk about it is actually in the example where we show data. That's probably the only place where those are seen at all, but.

D

D

Which I'm not sure why this vendors in this order way? But.

D

um Yeah, so we need to document this.

B

D

B

There shouldn't that be hardcoded, just as the type on the context level.

B

As we said, there, r b have an nm, so both the version and the type in the context, and also the type in the subject since that would should be the same. If I understood you correctly, for each event for the same type.

D

Yes, um we can record it in the same way. I mean if we wanted to write a scheme as a common schema share schema for the different events. Then you know it could be a new with multiple values, but since we are using.

C

D

Schema per event, um it can be hard coded, so I can add that too.

B

You have to make it clear that it needs to be the same for all events in this different type, so there is no freedom. There.

D

Yeah yeah. That makes sense for for the content. um I know a lot of events today. They do not have any any content defined because the data model isn't complete there.

D

um So would it be okay to leave an empty content.

A

D

For now, because eventually they will all have some content.

B

Yeah so then the event will validate regardless of what you put into the content there.

D

B

Can put how much you want and still have it empty as well, and it will validate, uh because you didn't say additional properties false on on the content level right in the schema.

D

Let me check it should be additional property, false.

B

But not within the content object.

B

Aha, it is okay, but that means then, if you would add things there, those events will not be very valid towards the scheme life. If it's false there right.

D

Right but then I mean when we when we do add things we need to update the schema accordingly.

B

Yeah, but if you would add, if you would send on a cd ramp today with your sdk, would you not provide things in the content then.

B

Yes and then it will not validate if you do.

B

Yes, if you just see an event on the bus or on the broker um and try to evaluate it towards the scheme might be not without it be valid.

B

If there are things in the content, unless we remove line 56 here.

D

C

Or if we do it like this, we are forced to update the scheme. If we add content.

B

Yeah and that's what I was discussing during the result comment if we should actually have things in it, um I thought that's from from the beginning. We should actually provide or add things that we know should be there. Otherwise.

D

Yeah, but but this is, um this is aligned to the spec as it is now right. So I mean if, if you look at the um let's say pipeline run finished, um the content is not empty and that's because if you go in the in the where is it core events?

D

Okay, I was mistaken and you go in the pipeline run. There are four fields uh pipeline one finished. uh There are four fields here right.

B

My confusion there, then, was that we don't state the content, content keyword in this in this page, so I was a bit confused boy. What properties end up in what object? In the event, from this table.

B

But confused I of course see that when I look at the schema, but but it's not clear.

D

B

The actual payload should be the same, regardless of what binding we use. So the structure of the event within the payload should be the same. Then I think this document should reflect the objects that each of these event types contain and those objects properties as well and not just low level properties without any home turf. Let's say if you do what I mean.

D

I'm not sure um I think I mean we agreed that on the the way we rendered this in json is to put those fields into um into a content container, but I mean this: this pack is is the cd event spec, regardless of the binding.

D

So this is the information that that we have. I mean the fact that this is included in a content field, or there is a type field which says this is a pipeline run.

D

B

Okay yeah, maybe your.

A

B

You know the point there I think, but then there are some fields here, for example, the idp which is used in in multiple objects, for example the other videos, both in the context and in the subject field. Right, a subject object, and it's not I mean, if you see an event on the bus, it's not clear what I reveal this corresponds to. In that event, then that's an example.

B

If you go back to the example uh again in the current binding.

B

In binding documentation there, so there we have the id a234 one, two, three four and so on.

C

B

So I guess the cloud event event id and then we have another id under the subject.

D

B

So if you just see this and then there's also an id in the pipeline run down there. So if you just see this json blob, it's not well. Of course you need to learn how the event structure is, but it's not directly clear what id field is documented, really in the documentation.

B

And I guess the same goes for the type there as we said before, that the type is the same for all events of this event type, but we only we don't note any of them in the documentation what they should, what they mean or what they are. So I mean we need to describe what what all these properties mean somewhere and.

D

B

D

Yeah, so we need we need to describe the type and the content here in in the cloud event funding. So maybe we need, I I agree with you. We need to do a better job there in the cloud and finding to describe how that just pack maps onto this, but I mean in terms of what id this is. um So this is a description documentation of subjects.

D

B

Yeah, but down there, you have the events description. If you go down to the events description, it's still. You have ideas, while in the events right.

B

And then you're not anymore within the subject, object. It's the whole event.

D

D

Well, yeah, I guess.

D

We could I mean it's not the whole event, because the content is not there. The context is not there. It's not yeah.

B

D

Just the same for every single event, so this is kind of the part of the event that is specific to this specific event,.

B

Yeah, I think I understand where you're heading.

D

D

So I don't want you to now like in in the spec, uh have the entire json schema here for every single event as a table, I don't think we we should.

B

D

Should have that in that.

B

Case we should just reference the context or something in each of them, but maybe that's not necessary.

D

Yeah, I guess we could.

D

We could maybe announce these tables and add, like a context, with a link to the documentation of the context, and I have a subject and then these fields or something like that to make it more clear.

C

We need at least to have some kind of description of the the containers that we have there.

C

Either that you would describe, we have a com page within like uh event, structure or something we were described, different containers, and then these pages are for having the individual events and what would be in one container or that you would actually describe each event with the container uh in a page. So you would you basically repeat the container information, but then you would have the whole structure of the event in one place.

D

Right yeah, I want to keep the. I would like to keep the the actual json structure.

D

Separated because that's specific to to the binding to how we render that information onto a wire if it makes sense so um in the common metadata we say here we have the context.

D

And then we have the vocabulary.

D

And then there is an example here of how that combination looks like and then it says, okay format of subject. I say all the subjects have an id and the source.

D

Optionally, so here yeah, I guess we should say include the type and content we could include the type and content here and then clarify that, then what is in the content? So what is in the subject um and in the content is what is specified then by the book library stages.

B

Yes, so so all these buckets of events, most of those pages represent, is actually the subject.

B

Then, if, if the binding allows you to group all those properties into one json object or if there is some other way to to propagate the subject over that binding, that's secondary, I think, but still it should be made clear that we talk about the subject on those specific event pages I think but yeah I I get your point, but that's it's good to to not include the details within within those pages, since we have different bindings, it's just that it makes the reader it hit me a bit confused when I'm used to seeing clear, json examples in documentation more but.

C

Yeah, I'm I'm also unfortunate a little bit more towards that one to. I think it would be easier having a adjacent example or I don't know, uml model or whatever I guess we can. We can draw it on a picture uh to show because json is one way of doing it, but I guess we're gonna have some kind of containers and fields, so it could be a graphical thing. Also.

C

But I guess I have the same biases as the amount there so.

B

C

Either graphical.

B

Or it could be like a table or.

B

Some hierarchical visualization, it could be in text maybe anyway, but it's the only way we intend it to be. I think we intended to be hierarchical regardless of binding, but maybe that's not true. If you would do a binary binding over http, maybe that's not, it will all be flat. Maybe.

B

But isn't there anyway, some kind of logic, logical grouping, even though those properties might live all in the flat levels? I'd say.

D

um Yeah, yes, here points uh just trying to think.

D

I mean I, I don't think this is meant to be like flat as these are like this subject. So this is preserving the hierarchical structure. I guess the the content. One is not um highlighted there, so maybe we could kind of separate it separate them out in the table to make it clear and yeah, and then we could add one json example for each each event.

B

Yeah, I don't- I don't know if it's worth it to redo this documentation that much uh now um I I still have some some issue that we we also duplicate or information here in both under the subject heading in the event setting. It seems to me to be duplicate the information in many senses and and the same descriptions some types of, for example, in in all of them.

B

So but that's I think, secondary and it can be, can be changed later on.

B

um So I'm not sure we need to change anything now for 0.1, but it's maybe good that we have the discussion and can I know maybe we should write an issue on it. Let's see how we can improve it after that.

D

About the duplicate information, I kind of disagree now because we did, the initial version was trying to avoid that. And then I mean the comment was that it was hard to follow, because we only had the bits of information here and there. So there was no place where it was put all together, and I think we discussed that it's better to to have the information multiple times and maybe can in future use tools to generate it.

D

um Yeah, maybe maybe a misunderstood, the old discussion we had and that's the reason why I now made this uh documentation with you know all this, the subject first and then the events that repeat the fills from the subjects and but only specifying those that are valid for that specific subject um yeah.

D

I did not include the the context here because I thought that was too redundant to have everything but yeah we we could have like use these tables to kind of uh use some indentations, maybe your columns in the tables to imply the uh hierarchical structure and to have like the context and then just a link to the context to avoid repeating and then add, subject and then this fills and so forth, but yeah. So that's something that we can do over time um to improve readability.

B

um Yeah I know we talked about that if you can generate the documentation somehow or have one source for these, both types of tables, maybe yeah. We discussed that. I understand them, so maybe the under the subject heading there. It might be fine that we don't group them in different sub objects.

B

But then, when we go down to the event sub section here, we might might want to see them in their context. I shouldn't say context in their object.

D

Maybe something like see if I can.

D

So this would be like.

D

No, I didn't copy this table structure.

D

D

Say we write this, I could have.

D

Something like.

D

Okay, I don't know how to do this.

C

um An example- or I don't know if I'm disturbing too much but in in eiffel, we have, um we specify this with the dots, so we have, for example, container dot and then the keyword.

C

Let me take up an example. There.

B

Yeah, I'm thinking because it's too specific to jason but.

C

So, for example, here we have a meta source and then under that there are a couple of keys and then we send me the metadata source dot, whatever.

C

I pasted in a chat by the way for people wondering why we're talking about them.

B

So there we specify the the container of the objects.

D

Right so we could do.

D

D

Yeah, so it's just here in the table at something like subject: dot id.

B

But subject that source is not correct, then, because source is in the context right, so there should be context.source.

D

No subject can also have a source.

D

It's an optional field, but.

D

Testing because basically the id is always unique compared to the source, but if the subject does not originate in the source of the event, then you can have a source on the subject to make sure that your id can be resolved or easily compared to the correct subject.

B

I thought that wasn't the source on the context we talked about then, but that's not the case then.

D

Okay, sss: it's.

B

From the context it says there, this does not mean it's the same as the context, or is it really.

D

B

Separate thing for the subjects.

C

I didn't quite follow that one.

B

Why would different subjects there? It might be okay to repeat it if we consider the context to be on some other level, but it's not sure why really.

C

B

C

Let's, let's talk about the structure first,.

B

Yeah yeah it's better, but I think that this structure makes a bit more sense to me, at least, if we just add those test, dot notation.

B

But do you think that's okay, andrea when it comes to different kinds of bindings to have that notation.

D

Yeah, I think that's that's.

D

That's probably fine um yeah.

D

I mean if we, if we need to if we create a binding in the future, where we do something different, we can.

D

You can change it to think about it, but I think it should be fine yeah. I was thinking of adding it as like extra columns here, but maybe it's simple everyday.

D

With a dot notation, I mean one way or the other anyways um yeah. I think it makes sense. It makes it more clear.

B

Yeah that lessons my confusion, a lot at least.

D

C

It's also also better.

D

So sorry mickey did you say this. This is better for you.

C

Yeah, I agree with you on there: okay, cool.

D

C

Well, you're typing there uh brad you've been silent. Do you have anything you want to bring up? Do you have a comment or anything hello.

A

Yeah, no, I was just watching and learning. um One thing I did want to bring up is maybe uh at the moment we're investigating the idea of getting a kubernetes event and then sort of transforming that into a cloud event straight away. If that makes sense,.

A

Yeah so there's a tool like trigger mesh, for example, that doesn't I'm not sure if anyone's heard of it, um but we're actually trigger meshes. Let me just send the link it sort of does that, so I'm just exploring the concept of if that would actually work. But I've been talking to the flux team and they uh I want to integrate the city events into the flux, notification controller and they said um it's worth investigating getting the actual kubernetes event and then sort of transforming it. There does that. Does that make sense.

D

Yeah, I think they're they're at least they used to be, or I don't know if there still is, but um something on canadian side that yeah is it the same. So basically.

D

um It's basically transform like a kubernetes event into into a cloud event. I don't know if that still exists.

A

I I I quite don't I I don't know enough about kubernetes events to be able to to look at it, but I'm just researching at the moment just out of interest, but but it could be quite a cool thing to help with some parks.

A

um It's a difference between the integration and interoperability, because, if you're, if you're, still writing in every piece of software code that transforms it, it's sort of like an integration again, if that makes sense, so so we're trying to look if there's like a standard way of of getting that event and then pushing it on again.

A

So we only have to do it once, instead of for each tool doing like a custom integration.

A

So that's that's what I've been working on for with flux, just researching that and seeing if we can put it in there and then I haven't done that github action, yet sorry, so um I'll be doing that this week, I've been really busy with other things as well.

A

D

Yeah, let let us know what you find, I think there are some limitations and what you can put into kubernetes event. So there is.

A

Exactly yeah and that's the things.

D

A

Understand as well.

D

um And also, I think, the there are some policies that kubernetes will apply in terms of I don't know if it's called like rate limiting or well. If it sees an event multiple times, it will just send it once and there yeah.

A

D

It's it's kind of meant for monitoring type of scenarios. I think okay, but um so there there is some limitation, but I think it can. It can work some use cases um so.

C

D

To know like that, that pod was created or a deployment was created or updated, and you want to transform that into a cd event. uh They should be able to do that, um and I mean.

A

D

Yeah there there might be tools that do that or you can write a small like kubernetes controller. It watches for the resources and uses the sdk to send the event. For instance, something like that.

A

Yeah, I I don't know if it's limited to just kubernetes objects as well or if you can use any crd or anything.

D

Yeah you I mean you, can um I mean cds are resources as well? So if you.

D

If you write a controller that watches for the the type of resources that you you need, you can react to.

D

Events on those three services as well.

A

Yeah I'll write a controller, I've never read any controller before, but that will be a fun task and then I'll sort of report back. What I find just out of interest.

D

um Yeah, if I can find the canadian one, it might be a good starting point.

A

Yeah, because because flux don't want to have the the proposal that we did for captain, so they want us to try and do something like that. Instead, so I'm going to research.

B

Curiosity brad: are you looking at integrating flux with events for the purpose of the rotarious use case, or is it for for some use cases.

A

Or company, or it's actually more for the captain g-stock project, so yeah yeah, it's nothing to do with the geniuses one, but it's um part of the kitten project for the the flux inaudible. So argo has been done now, we're doing flux, um which is a little bit harder right. Okay, okay,.

B

A

Yeah yeah, but um it could be possibly you if it does work, it could be possibly used for a lot of other tools as well, not just flux like, for example, falco.

A

I I also seen someone in the general channel just posted that they're going to do a talk on argo city and techton, which is very, very interesting at a local meet up. So that would be cool to see that if they have.

B

Have you been involved in that uh andrea anyway? I saw that you had a comment on that or you forwarded someone there.

D

uh Sorry, I I missed the last thing I was looking for for the source and can you decide could you repeat.

B

No, I I that was, as rad said, there was a post in the general channel and someone was forwarded by you there uh to talk about stickers, uh someone who will do the local talk protector.

D

Oh, oh yeah, no, um no, I mean the the person asked asking about it and on detectors like, and they suggested. Okay, if you ask on the cdf's like that's, is that as much as it was involved.

B

I'm not sure how much it even involves events. In that case it doesn't. He doesn't say that would be interesting to hear about.

A

Yeah, you would hope so because that's the way, I did it for.

D

A

And captain, which is the same concept.

A

Yeah yeah thanks. I I I I wanted to ask you about it, just to see if that that idea was even possible, but it sounds like it's somewhat somewhat possible but limited so yeah.

A

Oh yeah, perfect thanks. That's quite cool.

B

There are discussions from buying your cloud event towards k native. If that helps.

A

Point me in the right direction. I think.

B

See your whole discussion, but you would google for binding cloud event to generate it might give some hints.

A

Yeah yeah thanks for that yeah sorry to go off topic.

D

um Yeah no cool, um so I think we are about the time we have a bunch of action items. There is some work on the formatting of the spec um to be done.

D

I create an issue to track that work and yeah. I don't think we necessarily have to do it for 0.1, but any improvement and readability for sure. It's welcome great, um so, hopefully iteration after iteration. We get to to a point where the spec it's more like obvious, and to the first speed there as well so cool any any last thing.

B

Good discussions, I'm glad to hear, might be a bit frustrating to not finalize the discussions always, but I think it's very good discussion here.

D

Yeah, I agree yeah good talking to everyone. Thank.

B

D

B