Antrea Community, 3 Jan 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Antrea Community Meeting 01/03/2023

Description

Antrea Community Meeting, January 3rd 2023

A

All right so hello, good morning, good afternoon, good evening and uh thanks for joining the first Andrea committee meeting of the Year 2023 Happy New Year to everyone, and uh we are therefore ready to start with this meeting so uh for today. I have uh on the agenda a discussion of uh of net performance announcements.

A

uh I, don't know if we have any other topic. uh Chan I believe that the last time you mentioned that you wanted to bring up uh some discussion over outstanding user reported issues. Is that correct.

B

Yes, yes, I think if we got time today, perfect.

A

So maybe, let's start with the of net announcements, and then you know we can go with the discussion of these uh um customer reported issues and if we don't go through all the issues today, we can uh finish them in the next community meeting. I believe that uh Ashish joined this meeting to present about the ethernet announcements. So I will probably just end it over to Ashish and please go ahead with your presentation.

C

uh Yeah hi uh I'm Ashish uh I've been working in the OBS team uh at VMware and recently spent some time on the the live open, Flow and the of net library of the Andrea. So I'll share my uh presentation now.

C

So, uh can you see this diagram that I have a PDF document? We.

A

Can see your screen? Yes right.

C

So let me give you just a very brief background of what we are discussing. So uh in Andrea we have uh the OBS, which actually does the data path, and this ovs is programmed by uh the Andrea agent. But uh if you look down, uh it's actually a set of libraries that we use. So we have this Library called live open, Flow, uh which majorly does the encoding decoding of the open, Flow messages. uh Previously we were using 1.3 and recently we coded the 1.5 support, which is now integrated.

C

uh Apart from this, this Library also has some support for different protocol encoding decoding like uh like, like icmp and other protocols, and it also provides some utility to to read the messages and buffer the messages over the socket. So it talks to the obs, um the the module that drives or uses this. uh This live open. Flow is the of net which actually implements the the logic.

C

Like kind of uh you can say, the the first level of the controller Logic, the open, Flow controller, which so this implements uh like a like kind of a switch implementation. uh You can program the of net using some kind of a like a graph method where you can program different entities. uh It has an obstp driver, support for a transaction and packet in handling and uh the the the the user of the of net is called an app or an application.

C

uh Currently, uh the application is Andrea agent or you can also trigger uh different scenarios using the unit test which, like is, is which acts as the same level as the app uh we'll discuss about this command line a little later. So uh when we coded this uh and like discussing with winning, we found that the of net code uh can has some like few enhancements. That is possible, which will make the whole code better.

C

um So I have listed uh the points over here, so the the the way this discussion started was that we encountered a deadlock bug. uh This was observed, I think, once only uh as far as I recall, uh this was observed in some customer site, where the the of net code kind of just blocked on certain load, condition uh by load condition. I mean that there were a lot of flows getting programmed at the OBS and under certain condition.

C

We are not sure uh we still don't know the root cause, but it kind of deadlocked and uh when he added some code, but we can, uh we can further.

A

C

You know enhance that code and make it better.

C

So as a part of this, we obviously have to fix this bug and but to fix this bug, uh what we have to do is we have to add some way where we can actually uh do some kind of a load or stress test, uh because, uh apart from being able to reproduce this issue, this is it's a good thing to have some a test case which can load up the the entire of net and the and the lib open floor code, the code, so that we we we can iron out any other issues that we encounter.

C

So that's the plan to add this this uh this test. um Also, we found that uh there are certain interfaces by interface. I mean that, uh like from whenever, whenever a packet in is received at ofnet, um it's sent to the application or Andrea agent. It's still like a like a function call we would like to make it like a buffered channel uh and so that the of net code doesn't get uh locked up or delayed, because the application returns takes more time than than what is usually acceptable.

C

So so we want to to not block the of net code. uh One more thing that we like that I found is that whenever we program a flow to the ovs uh open, Flow doesn't like provide a very clear feedback, whether the flow Edition was successful or not so uh right now, the way we kind of account for the flows programmed in the OBS is using a flow stats, uh uh but OpenFlow has like a better way to do this kind of a monitoring.

C

It's actually called a flow monitor, and this the way uh it's better is because you, once you program a flow monitor in the OBS, it will just generate asynchronous messages to the controller on any flow Edition deletion. uh So that way you get a feedback of what's happening at ovs um in case in case. For some reason, OBS decides to delete a flow. You again get a feedback, so uh this is. This is a good way to keep a check on uh of of the flows, which is there at the obs uh one.

C

Other thing that we found is that the the logging at the of net is is not uh like. It's really bad. So uh in case now we get any issue any bug. uh We don't know where it is, if it's in the osnet, which part of the code failed, because the logs are actually not there, so this has to be added on a high priority uh as well as so. We we need to add error logs and debug log to for obviously debugging any issue.

C

The documentation at the of net level is again can be enhanced further uh okay. Now this is this: is this this command line tool now I? Don't know whether this this uh make sense or not, but this is something which I thought so right now to trigger this of net code.

C

uh We have the Andrea agent, of course, so, uh but or or the unit test, but I was just thinking of like adding like a command line to uh to to to so this command line tool will trigger of net and live open, Flow, something very similar to the OBS of cuttle. uh We can have something called of of net cutter, or something like that, so that this becomes like a standalone utility to program uh like program, add or delete flows using this code base.

C

So, uh just just an idea, uh maybe not a high priority, but uh like probably a good utility to have uh again uh right now uh so coming to this feed. Just this part, so right now, uh whatever is implemented in of net, is obviously what is needed by Andrea agent, but uh maybe in future you need more open, Flow features, uh which obviously is not here.

C

So this is kind of an open-ended thing, uh where probably uh the the folks working at the entry agent can uh think, like any other feature that they would be needing in future, so that we can plan it ahead of time uh again. This is something which is I'm, not sure, but uh do we need to explore the AFX DP or the dbtk support at OBS? This is more at the obvious level.

C

um Are we ever like? Are we planning to move in this direction? So again, uh getting to know in advance would help um that. That's all I had any any comment or feedback.

A

Thanks for the presentation, please go ahead with questions.

B

I see you thanks for sharing. This uh I also have some questions about uh fxdp and dbtk data parts of os support. So I want to take this opportunity to ask you some questions uh for for afxdp uh I'm, not sure whether my understanding is correct. That uh is this only about moving the data path to user space, and would it affect the use case of workloads? Does it require the workload the application must be developed for the based on XDP or like dbtk, based application.

C

B

C

So it's it's! Oh, it's the data path of the OBS uh which will move so right. Now we are using the kernel module as the data patch.

C

uh If you move to AFX, DP or dpdk, uh we have a different data path so, uh but the the open Flow the messages, the interface that doesn't change, but uh when we move to AFX, DP or dpdk, uh the the data path code is entirely different, so uh and I believe we do support everything that uh the the kernel module today supports in the dpdk or the AFX DP data path. But that could be certain features which might be missing.

C

I don't have that list right now, uh I can get it, uh uh but mostly the interface will not change, but the second limitation, of course, would be that uh uh at least for dpdk I know that it doesn't work on like it works on. Only certain specific Nicks uh I can tell you, I mean about afxtp uh that it probably again may have the same limitation but I'm, not very sure about afxtp. Today, I can I can find it out.

B

Okay: okay, uh my my major concern for moving to AFX DP, like whether it would affect the application itself, because that means whether the application uh can continue use rely on the TCP IP stack of its own namespace, whether it can receive traffic from its network interface like like before, or it will have to move to uh you.

D

B

Some XDP type library to develop the applications.

B

With AFX DP data pass where there could the container still connected to a vth device we to con to the OS bridge, where that change.

C

Oh okay, um I I'm, not sure as of now but I'll I'll, find it out and tell it to you. I I actually didn't work on AFX TP, so but I'll definitely find and tell it to you. But uh by application you mean the container uh trying to um like bind to a normal Dev device is. Is that what yes.

B

Yeah and I mean regular applications like HTTP server that, uh but we see we traffic from normal interfaces. Virtual interfaces, oh.

C

Okay, okay, I I have to I have to find that and I'll get back to you.

B

C

um Sorry, who was this speaking my screen somewhere.

B

A

A

um Any other question curiosity anything you'd like to ask Ashish foreign.

A

Waiting a few more seconds.

A

Okay, so actually, which areas do you think you are winning, will be tackling first.

C

I think it will be some changes in this Deadlock uh bug uh logs and the buffered Channel. This will be probably we are aiming for the next release and then we'll work on the the stress test, documentation uh after that.

A

Awesome, thank you perfect, and uh it seems there are no further questions for Ashish. So perhaps we can move to the next topic for today's meeting and uh Chan I, don't know how you want to go ahead for discussing uh customer reported issues so I'll, just let you lead the conversation from here.

B

Okay, let me show my screen.

B

uh I hope my screen is visible. Yes, yeah. Currently, we we have 18 open issues for future requests and I have opened the fields for today's discussion and they are mainly about a service external IP, egress and nail policies and the sync. The the issues themselves are valuable and I want to collect more imports from the community.

B

uh Oh, this is not a feature request and removed the label yeah. Let's start from this one. This is for a feature request to allow multiple service sharing a single IP and is it use the use case of meta IB either in Lamport and I. Think this feature request makes sense and uh I proposed to just allow allowing users to specify the same IP for different services and when and it could automatically mod, you will automatically work when the services are using different port and if they are using support, they cannot work.

B

So we will not report the the requested, learn bus IP to the status of the second service and the LED users to correct the configuration, and we will generate events for this service to alert this warning a single. It should basically work and also got some comments for Antonio and the shoe and the user. So if we uh any comments for this feature request, if not I I think it should be clear under what we need to decide is whether we should just include this um implementation in this or outcoming release.

B

Not sure if I explain the issue itself clearly I think it's a small change in that. Just previously, we don't allow you to specify same IP for different Services. Now we allow it and check for conflicts.

B

If no more comments, I think we could move to next one, and perhaps if we get bandwidth in this release, we could find someone to work on this.

A

Foreign I, at least I, didn't have time to think totally about this problem, but I don't see any problem with sharing the same IP for multiple services, so it should be. Your proposal should be good um and does anyone else tell me any comment on uh on this issue.

A

Seems not so maybe Channel we can move the next one.

B

Sure the second one is from Junction and I think he wanted to uh uh this feature to resolve one problem that for some Services created automatically by some controllers, there is no chance to update the augmentation to let until allocate one robust IP for that or even user manually annotated service.

B

It will automatically cleared by the controller, who is doing the model for managing it. So his proposal was to have an annotation on Wednesday night before and meaning that that external IP poor will be used for all lower bands type of uh Services when they are, they don't have a separate annotation I didn't reply this issue, but I thought about this through comment.

B

My feeling is that it may uh having a unified annotate, a unified external IP. Poor may not work for all use cases, because uh all services will have to use same instant, IP, core and and I wonder if we could just move the service annotation to namespace level, not move to, but just have another layer for annotation.

B

For example, when the when the name space has a uh how, uh when the service yourself has The annotation, uh the Android controller will allocate the Eastern IP phone that uh IP poor when the services itself doesn't have The annotation until I will check. The annotation on the namespace and The annotation is in the same format, just the two layer of annotation, and if this, the namespace itself have The annotation, uh I'm sure we'll still use that IP poor to allocate them IP, and there are two uh benefits I can think of. First.

B

Is that not all services in the cluster how to use one instant, IP, port and I think it may be typical to use in space as the boundary of resource sharing, and uh the other benefit is that it could also resolve the problem that a user don't have to annotate every service and.

C

B

Especially when the service annotation is known, cannot um updated by user.

B

The third benefit is that users.

A

B

Have to know another annotation, we could just use the same annotation as uh as before, just annotated on the namespace.

B

um Not sure if others have opinions on this requirement and.

B

What you're saying it's not here today so I will also check with okay well and just reply here.

A

Yeah I mean I, don't have any specific comment to just um The Proposal from Junction. The only thing that dejection, the only thing that happens. The only comment that I have is that, typically, if you have to annotate something uh as being the default, then we need also some additional check to make sure that uh only one tool is a noted as default right, so that that's the strange part.

D

A

Okay, well, since Junction is not here, perhaps this will need additional discussion on uh on GitHub too.

B

Sounds good and the next one is about egress, you know. Currently, uh we we can only assign one Ingress IP uh to to to each egress object.

B

That means that uh um if the ukras IP is statically located support.

B

And and if the egress is a dynamically allocated from externality poor, it has the flow over support. However, the egress IP, a single request, IP, can only work on a subnet of nodes only because the egress IP must be in the same subnet as the node.

B

So if the cluster has more than more than one subnets in the nodes are in different subnets is, uh is it um we? The only a few of the nodes can be used as the external node and when the Houston window knows that are in same subnet are all done. The egress will no longer work, regardless of the uh the which you know that the the traffic comes from.

B

So when and it's very typical, uh it's a very typical scenario that on cloud, the the the whole cluster stays in different subnets and each subnet and maps maps to one available Zoom, and so you, you know the point of available zone- is that um the the the they provide the ha support uh as a as a unit or for availability.

B

So it's not good that way. We we are located. We we use the one single available Zone as the egress notes.

B

So I I think about this requirement and propose to uh one approach to address the limit is that is allowing a secondary egress IP and a secondary egress IP port, a Eastern IP poor, to be used by an egress, and that means that you user could request one egress, IP phone One external IP, poor and locate a secondary eclip from just for another instant IP port and each using an IP port. We are mapped to one available Zone, so people could get the address support.

B

Even the whole is done as long as any of the available song is up. The request. Traffic could still go through the available one and that could also adjust the limit of static egress, meaning that I I could use two different uh IPS, which is physically assigned to two nodes and even I, don't use uh Keystone ip4 I I could get AJ support as long as the two nodes are not done at the same time, um yeah I, think user is the the the user who reportedly issue is fine with the approach. But let's change.

B

This chance, you require some efforts to invent, to implement and not sure if anyone has any other comments or any any other approaches want to suggest.

B

A

B

I will also create and used to for the design and the uh for the proposal and the design of implementation and the price perhaps and also need- and we also need to do some POC to verify that this approach could work on the above scenarios. Yeah.

A

B

Okay, let's move to next one- and this is for the nail policy feature.

B

um I think the use case is that when uh in in some uh this Choice, especially on cloud, it's very typical that the control plane notes are not showing up in the but I'm not showing up. As kubernetes knows, the control, plane, components run out of the cluster, and we there is no way to select the the IPS of the control plane components as using existing selector.

B

For example, you cannot use node selector, because there are no control plane nodes and you cannot use the port selector because they are not running as ports, um at least not not in this the class itself. So when user want to allow um control, plane components to access this service.

B

Currently, the only way is that the the master specify the I, the the they must figure out, the control, plane, components IP and the specifying then either IP Block in net policies so use this user requests. This feature that they want to leverage the end point uh object to get the IP of control, plane components, for example. uh Typically, the there is a service named the kubernetes in the default namespace and is corresponding endpoints, how all com, uh how all control plane IPS.

B

So uh they they propose to have an endpoint selector and uh the the.

C

B

Could be adjusted and the name and name space over the end point as uh form of the Ingress Rua, then that and enter to get the the IPS in the endpoint object itself and use them as Source IP other eyes changing and replied.

B

This is very specific to one use case, because uh that it does not make sense to use endpoint selector for for any other use cases, especially actually the endpoints the mean for the back end of service, which is which you usually means the destination instead of the source, um but anyway, I I think the requirement itself makes sense, but just uh no idea. What's the best approach, help to address the requirement.

A

Well, uh yeah, perhaps do you have any option, I see that you have been mentioned several times on this VR yeah.

B

That's why I brought to you there.

B

Want some feedback on this future on this requirement, so I want to arrive here. It has been more than half half a year.

D

Yeah I think I've must have missed it a couple of times. um I will take a um more closer look at this, but uh um on top of my head, I agree with that. All the things that Trend said that this is you know for a very specific use case.

D

um um I mean I mean it might be.

D

It might be good to think of you know- maybe some other API design to solve this use case, because um I don't know if that the endpoint selector will be very confusing uh for the you know, other users uh on what's the um what's the difference between this and the two services that we provide, because they're gonna look exactly the same, um and you know it's, it's going to be really tough to first to explain that um when you use the two Services, um we will Leverage The intra proxy uh thing, uh so so that you know we're actually filtering on um something other than IPS, whereas if you're using endpoint selector we're actually filtering on the IP I think both should exactly do essentially the exact thing.

D

um But you know it's kind of it as Trend said, for you know really normal use cases, it feels really sort of a redundant and confusing um to me uh for for normal use cases. So I probably needed to think a little bit more on this.

E

Yeah yeah should.

B

E

Ask there's a there's another problem here: um I think in many cases the the the and the points IP for control plan is actually a local bank's IP, so that put it down work for Ingress policy.

B

Yeah you mean the the IP in the endpoints object itself is a low balance IP right and we want to be used as in a source IP of the English.

E

Traffic well, for example, in uh eks, probably also the case for GK in AKs, I, think the control plan service and the point size charge with logo. The private link IP engine, because other IPS is different from the uh Source type. Here, when the control panels, which ports.

B

Okay and then yeah, they need to even more difficult to figure out the Source IP of control, components.

E

B

Then it doesn't sound like uh any issue specific to answer. Any other thing like that implemented nail policy could have this used to right.

E

Using the there's, a project called, uh let hook proxy could be. Could foreign.

E

B

Oh, you mean the API server proxy.

E

Yeah yeah yeah, uh it's called API server connection process or something.

B

E

I I, don't even know in that case, what will be the Society, the the policies.

E

But definitely would not be the end upon ipf.

B

F

It will be the IP of the proxy server pod, which.

E

B

uh That's only for gke not for uks.

E

Requires a with me, um I said we we we uh looking into that for uks. Right, um really assume you always have connectivity from Japan nodes to Ports uh I need your posts uh uh using public IPL. As my understanding.

B

Okay, because I think the problem of gke could be resolved by just having a port selector if the source IP is sure for ECS, if they are.

E

Not interested.

B

E

Maybe that that is nothing useful you can, since you guys, don't really you know assume you can always enable the connectivity from control plan to Ports. So probably you cannot. Actually, there will be a traffic from controls to Ports.

B

Okay, then, we need more clarification from the user, whether how it is guaranteed that uh the the traffic from control plane components with the service in the cluster yeah.

E

But but I mean um you just like for a different discourse or different uh measures may have different uh implementations, so you will see different Source type here for the traffic I. Don't know if I can figure out a way to support the water cases.

B

Sure young, could you follow up with this with the user? I think he he is watching this issue and they want some feedback. I think we could at least get some clarification from him, yeah sure, okay,.

B

Nasa is also for Neil policy, but for auditor logging. Currently, we don't have namespace and the name information uh of uh of the traffic traffic endpoint, for example the when the traffic comes from a port or it's destinated, that's native to our Port. We just look like in the audit log, but not the namespace and the name of the IP.

B

So the users I think the there are different people asking something: maybe they are from 17. uh they they're asking for uh the more uh more information uh to be added to the audit login, so they so that they can uh to to meet their requirement.

B

uh I think Anthony is already an energy already following up this, uh you comment and not sure. What's your latest uh thought about this one, whether this is a valid one or it should be addressed in while another mechanism like uh traffic use, water.

F

Well, I think it's uh it's a valid uh question that they ask right, because it would be like useful to have that information in the local audit policy logs. But it's not really possible for us to add that information without changing the current architecture.

F

Right, because we don't really want to have like each agent monitors um the full set of pods in the cluster to be able to map IP addresses too two namespins and names um I think maybe that would put too much strain on the API server and also that's kind of like duplicate functionality, with what we're trying to do um in the flow exporter and wistia. But I do understand, like the point of view that uh some users may not want to deploy CIA and still be able to have that information in the local policy.

F

Logs uh I think the only approach we would have it would be to like, take those uh local audit logs and send them to a central place where we can add the missing information, and that starts to be very similar to what the flow exporter is. Is.

C

F

um Maybe we could have a mechanism to have the flow aggregator uh generate. Those Network policy logs in in a similar format. I think that that could be a solution, because the flow aggregator should already receive flow records for all the denied connections, for example, and it's already mapping AP addresses to pod namespaces and names. So we could have the flow aggregator be able to write those comprehensive Network policy logs to to disk, and then they could be collected by by the user in a way without having to deploy.

F

Potentially, it would just be the same kind of network policy log that we have locally, but we would add the namespace and name information.

F

E

In a way, it's.

F

Even easier to look at the log than before, because you will have like a a single file to look at instead of having to look at local files on the different agent nodes.

B

Yeah, but that that sounds like that, there is no point to look at the local audit logging files. If that centralized, the login has more information and if it doesn't does not miss any flow right.

F

It should not miss any flow I think it's always possible to have some flows missing. If there is too much information generated, you know, because we do like contract polling.

F

uh uh Oh sorry, um it should not miss more flows than the local audit logs, because both of them required are rely on the packeting mechanism from obs and in both cases we have meters to rate limit the number of messages we process in the agent because, uh as you know, if we have like uh a network policy that drops traffic, otherwise it would be possible to kind of like do a Dos attack on the agent where you generate, like you, keep generating the same kind of uh UDP packets, for example, and all those UDP packets would eat a network policy role and and be dropped.

F

If we were to process like a packeting message for each of those UDP packets, it would patch to put too much strain on the on the agent, and so we limit the packets I believe to 100 packets per second 100 messages per second.

F

uh But that limit applies to both local audit logs and to the flow exporter, a job information.

F

D

There is no difference.

F

In interior you can for for job connections, you can um I think we can lose the information in both cases.

B

I got it thanks.

F

So my yes is because we want, we don't want to like build a brand new component to be able to do that, but we could build that functionality without too much difficulty in the flow aggregator.

B

Okay sounds cool.

B

Okay, then, let's move to next one I.

F

I can take the AI of I'll, see if I can comment on that issue again and click bring it to conclusion.

B

Okay, thank you, uh the next one. Is uh it I think it's not what we can support for now it wants to apply and general policy to the node itself. Like some other thing, I dance like a cargo but I I, don't think it's uh is very favorable today, because the traffic phone and to the node are not manage.

B

I know the email managed by and sure, unless using the uh uh the flexible iPad mode, which means the the the node the host network is bridged by OS is bridge by open with switch and it's kind of similar to what external uh external know the future. That's today and managing security for the node itself, um so I I, don't have uh could upload a solution for now.

B

Unless we we also Bridge the host Network in regular modes like in cap and knowing cap, but that also brings risky or for under complexity of managing the node Network itself.

B

um Yeah, if anyone has any thought or any suggestion, I think we can discard here otherwise I may have to leave. This is to open for I.

A

I don't know you know, I, think that uh my personal standpoint here is that kubernetes Network policy should stay away from uh managing node traffic. That's outside of the scope, but I'm curious that you mentioned the Calico is a solution for this. uh Can you share briefly how Calico they do this.

B

uh Your unit Calico Implement in their policy atletic, is a. It is a default mode. It use IB tables to support the policy right so for container traffic. It just uh programs available in the forwarding forward chain and, of course, for host net policies. I think they just create a applicable scores in input and output chain instead of the forward chain. So it's pretty easy for it to implement host net policy.

A

Okay, understood, but, but still there is a there is no solution to for distinguish. The policies that are applied to the node are the host networking and to the ports that are in Austin Network modes. They are both Android by the same rules right.

B

uh Sorry, okay, can you repeat yeah.

A

I mean the pods that are running in host network mode. It's not like they have uh dedicated policies that are are only enforced on those spots in Austin network mode. So the pod, which runs in US network mode and the host networking are uh the same policy are enforced of both is that yeah yeah I.

B

A

I don't know personally, I would I would not make an effort to try and control this I mean I, don't know young if you have also an opinion on on this matter.

D

um To be honest, I I I, if you are very similar to what Tran feel and no this is also. This is also something that uh you know when we talked about I've been now a policy we've been discussing upstream and in kubernetes Upstream. uh If I remember correctly, because it has been, you know a year give or take when we're still discussing the specifics of aluminum policy and if I remember clearly, you know this was the area where the Upstream kubernetes people say that we don't want to touch this. So you know.

D

um But you know given given the uh given the uh admin hour policies stuff, we weren't even touching um North South traffic. It will won't be surprising, but still I.

A

D

Don't I don't feel like uh um you know, we have uh enough use cases maybe to justify. Maybe we wanted to bring this into uh entry plus now policy for now this is my opinion, got.

A

It thanks China.

E

I remember earlier, called you also raised the similar requirements.

E

uh Actually, I forgot the details, I'm not sure it's either the same or not, but I think what is the in the the mic um diagram by Cody I think he also had the item for low level policy. Is that what you remember to.

B

uh Fighting could happen. I, don't quite remember that.

E

Oh, it's probably not in GitHub um policemen or I'm, not sure seeing any document he has or just our you know, internal discussion.

B

B

Okay, at least we don't, we don't really see many stimulus requests from users themselves. This is the first one for users, yeah and uh yeah.

E

Besides conical, do you know any other thing? I can support uh policy. I, know traffic.

B

uh I I think using ubpf could also do so, so perhaps uh Syrian could do that and I didn't check that, but it just think about it. I think it's possible because they have the hook to handle Ingress traffic and the egress traffic. So.

E

B

There is no technical problem to support that.

B

Yeah I I could check that offline.

E

Okay sounds good.

B

B

The last one is about implemented implementation, implementation.

B

The Nepal State status, API uh in Upstream I, think everything is ready. Just no resource is located for that. Yeah yeah.

D

I, don't I, don't know how that fall under our radar. For some reason um uh I is there? Is there anything related to you know the status of a policy also merge in the recent releases. Is it on the agent side where you know when you were working on some um OBS, realization, statuses as well, um that got merged in recent releases? I. Remember.

B

It doesn't rely on that. We already have status report from agent to control a long time ago.

D

Yeah I know and I I know that I was just wondering you know, for the other thing is, is it an um some more um detail? The status.

B

uh I think currently, kubernetes State airport status has only one condition, uh uh and it's about I remember it's about whether you can support endpoint.

D

B

The portal range: that's what I remember: I'm, not sure whether there is any change, yeah.

D

Yeah I mean I mean I I would assume the um the status field is was set out to design to be more generic than that, but for the for the Upstream case, maybe right now the only error that can can make a pop-up which makes sense is the is that we don't support the import, but obviously that you know we we do so um yeah yeah I, uh uh you you can you can design me on this as well, um so I'll I'll keep it.

D

uh You know under the radar and we'll we'll fit in one of the um get this in one of the releases sure.

A

Thank you, I I, remember that this is also one of the other topics where the community will never reach an agreement over the years. So that's why there is no uh no solution as a part of the network policy specification. Is that correct, Young.

D

A

Yeah well, but it should be fine if we can find the solution, which is a good enough hold on three Electoral policies, at least.

B

Okay, that's all for for my list today, yeah.

A

Okay, thanks uh thanks Chan and we're also reached the end of the scheduled meeting time.

A

So uh before uh closing these uh this meeting, uh there is a comment from janjun and on the chart, as you can read that it might be about the requirement to support security policies on the traffic uh we can probably according to genjun, we can try and add a new crd to the differentiate it from Network policy for pod. uh So that's that's an idea that we can work on um before we finish today's meeting. Is there any other topic that you would like to bring up for discussion.

D

uh Not really, but I just wanted to say that if we were want to support this requirement, I also strongly agree with changing that we probably needed new crnd.

A

B

Will be fine, yeah.

A

B

Have once more comments uh that uh I I recently I found that Auckland is is out of maintenance for a long time and they haven't, they haven't upgraded their kubernetes Library dependency and there's no release I think that at least for one one year more than one year, I guess that project is not in maintenance anymore. So do we want to move to uh to to move to another visible software project for triple flow or the other future that you see we currently have with octant.

A

That's a good point, but I think that we are. This boils down to choosing whether we want to rebuild our UI features for Andrea right.

B

A

We definitely want to do that. I mean I I. Don't think that we will. We are in a position or willing to take over octanta maintenance right.

B

uh Sorry, you you mean take.

A

I mean I mean uh the options are too either we develop a new UI, not based on octand, or we take over octant maintenance and I. Think that uh maybe we don't want to take over uh uh to to take over octanta maintenance and become maintenance for OCTA I. Don't think we want to do that right.

B

Yeah yeah I agree yeah.

A

Yeah uh I completely agree with you that uh this is something that was actually I believe known for a few months already. So we need to take action on this front, but uh I also believe that uh we probably needed to get the feedback from the uh developers that have more experience with the working on the front end.

C

A

This is something that we can bring up in the next community meeting.

B

E

But do you guys have any candidate uh solutions to replace octane? Do you want.

B

Not yet I I just found that recently I want to give a head up to the team here.

E

Sure, yeah I think we talked about that before definitely um probably. Finally, we should definitely alternate support yeah, but I I don't have a good idea. What could be the you know, new UI, to represent.

A

Yeah I'm definitely the last person in the world that can make any sort of comment really that UI is a completely ignorant on this front. So, let's, uh let's bring it up as a topic for the next community meeting.

D

A

Cool and uh anything else for today.

A

Three two one zero, so it appears that uh it's all for today, so thanks everyone for attending again happy New Year. um The next community meeting is uh should be on January, the 17th, which is uh before uh the Chinese Spring Festival vacation. So it should be okay, um but the one after which is on January, the 31st uh I think technically. This is a a working day in China, but uh I know that uh many um many folks in China tend to take two weeks off around the New Year's Day.

A

So I don't know if we want to move that meeting into the first week of February or whether we want to still keep it on uh January 31st I mean we can also discuss this on the Andrea Community Channel, just uh food uh food for toot.

A

Okay, uh that sounds good and, uh and the only thing left for me is to wish everyone a good evening, a good day or a good afternoon and uh talk to you in the next community meeting.

A