VMware Cartographer Community Meetings, 17 Nov 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Cartographer community meeting - Nov 17th, 2021

Description

00:00 Intro & announcements (including Office Hours every Monday @ 2:00PM ET)
03:01 The TL;DR
05:38 Documentation structure and what to use for unreleased and most recent versions
10:40 CII Best Practices progress: Code Analysis
Community meetings happen each Wednesday at 8:00 AM PT/11:00EDT
See the agenda here (https://bit.ly/2Z67z08), add any topic you may want to discuss and join us live!

A

Okay, hello, everyone and welcome to the cartographer community meeting. This is november 17th and uh we're getting started right now.

A

Okay, um if uh probably you didn't receive the the update uh via google groups or social media or the slack channel, um we are having office hours. The cartographer team will start holding office hours every monday, 2 p.m.

A

Eastern time, the purpose of that space is in general to deepen the relationship between contributors, maintainers and the the overall photographer project's goals, and and in particular, we will be discussing rfcs rfcs are the methods the cartographer project, use to propose ideas that could potentially change how things are done uh by by the project and the architecture changes uh to it. So you're welcome to attend um again in all of our communication spaces. uh We send the notification, but again it's uh over. Here we have uh details of how it's going to work.

A

um For this. We are evaluating a different approach. First, we we plan to have a notetaker determined prior to the meeting, because some discussions are there are deep enough to have proper note taking and also uh the idea is to add topics to the agenda prior to the meeting.

A

So so the maintainer team and everyone involved who prepare accordingly. um The idea is to divide the 60 minutes evenly among the number of discussion topics. I know that some other projects have this structure of phil. The first 30 minutes uh answering questions from the community and the remaining 30 minutes discussing deeper technical topics um for the uh behavior. So far of our meetings, we are dedicating the whole 60 minutes to discussions, but we are going to divide the time evenly among the topics right, so everyone's welcome to join.

A

Okay, um again welcome everyone and uh we're getting started so tldr for this week, and I see that there are some notes there. So I don't know if josh will elaborate on what's new in the project.

B

uh Yeah, so I wasn't in the project this week um we just uh we added some comprehensive auditing of error logs in the reconcile loop. um So this is a follow-on from all the informer work that we've that we did before.

B

Just making sure that you know we're returning an error when appropriate and not when we don't need to.

B

And then so now we're working on uh reducing controller permissions, um which is all about giving the the minimum number of permissions to to your controller um right now it your controller starts up with uh very permissive surface account that it uses to create all the objects under the hood, and so we want to narrow that down to only the minimum objects required.

B

So we're working on that.

B

Yeah, it's a good discussion um and then we're the other big thing. We're working on right now is uh we're revamping our logging, um so we're standing uh seeing on some log levels and then we're gonna be taking a a pretty big pass over what we have already and just making sure that we have some consistent logging um throughout the project. So those are the big things.

A

That's great um isos release candidate. I don't know if uh we could share briefly about this. What's the overall theme of this uh release, candidate.

B

Yeah these release candidates are uh just for uh some internal testing we're doing right now, um and so we will um yeah they're really not for public consumption. At this point,.

A

That's great okay! Thank you, josh, um okay. Well, from the previous meeting, we had a couple of action items so just reminding that creating an issue regarding testing practices and also adding providing additional use cases for rfc 15., just a friendly reminder.

A

um Okay, there are please add your discussion topics there status updates. If there are not anything else, I'll start with the docs structure, um we've been, you know reviewing how to approach the the oss docs in terms of how to keep the base on versions and potentially how to automate at that. But the first step is doing it manually and reach some consensus there.

A

So there's this pr on which, let me show you the render here uh what we have here is a um well now. The version in here for the latest version so far, and the first kind of decision or proposal that I want to discuss here was having a main folder uh for the unreleased version docs.

A

So now I see there's a comment from sierra. Thank you, sir. uh He proposed using latest. um I think it makes sense. In terms of um you know, the website play main has more to do with the github context, but here using latest I think it makes sense, and I'm just this is the the first, the first run of the process, I'm just using what other projects are using right now, but uh these suggestion from xero, I think, makes sense. So I don't know what do you all think.

C

You seem to say: maine would hold documentation for the unreleased code. Is that right latest seems to me that it would be the latest released code, so that would change what's actually documented.

D

I forget we, the meeting we had with the docs people. We came up with a nice name. What did I don't remember what we settled on.

E

I mean it's really yeah development in progress right, yeah maine is that is.

B

A

Preview yeah. Well, my my memory is failing there, but I thought that we discussed about using latest, but if there's something different, uh it's just a matter of changing a couple of files. So.

A

um Yeah, probably main is not the best option.

D

Yeah, I don't like latest either, so maybe we can have a like uh people can go and comment on what they prefer. The unreleased.

C

To be do we want to document unreleased features? Is that a standard thing to do.

F

Yes, it's useful for, like oh, it's very, like working on something delivery related right like we can put in the same pr that changes to docs and then it's out there. People can look at it and make use of it.

G

A

So yeah, I think.

G

We I was just gonna, give my I like development. I I think it would be useful for end users to have a latest, but I would expect latest to be a mirror of right now. For example, v7 it should be the latest released thing and development. I think will be very clear to folks that this is not.

G

Not what you're going to get if you do the safe, install.

F

Yeah another argument for like latest is pointing at the latest released version. Is that that's the same for github so like if you're looking at the releases of a project? The latest is like this soft link to going to the latest release, so I agree with not making it the what preview it is.

A

I think I will add the the options to the pr and we can vote there to reach an agreement. If you don't mind right, that's uh great yeah. This is a process that we can indeed automate. uh The valero project, for example, has a nice script to to automate this. So that's probably next step to start uh modifying this script to serve uh cryptography project um yeah. Thank you, sarah! That's! That's the the pr where you can come.

A

Okay, um now for the the ci best practices batch. um I wanted to touch briefly here um arrow here. The analysis section um this section: will we don't need to meet all the criteria here right? If you see other projects there, for example, again the letter project is at 100.

A

They don't meet all the all the criteria here. um Some other criteria is not applied and it's fine. So we just need to see what we have right now in the project. What we don't have right now and and if there are features there requirements there, that we don't plan to have so um yeah it requires reading. All of that. Actually, the goal is not to complete this during the call, uh but I just wanted to open up this.

A

This is one of the main areas that we are missing to fill in here, um and we will need to to have a separate time probably to cover this. uh It's there in the agenda. You can take a look, there's additional details in each one of the requirements to see um what we plan to to answer them right.

A

Any questions like that.

A

Great um next item annotating rfc status like.

G

Yeah, um I dropped a question I think, into uh slack um uh rc3 we're closing in favor of rc14 and as I went to close it I was like. Oh, this is just going to live on a branch for forever. That sounds not great. It should be merged in and somehow uh noted that it.

G

That it's been withdrawn, that we're not going to do that. um I can send actually david. Can I share for just a second?

G

um So uh this is uh the python pep? I should I guess, how did I get here? There's an open issue um about clarifying our rfc process uh that has to do with a lot of uh different.

G

uh You know there are a lot of things that we can clarify. This is the one that I think is.

G

Timely since we actually are withdrawing in rfc at the moment, um I I reading through the examples here uh I liked what I saw from python, uh their pet process, one they have this nice diagram. You know these are all the different statuses that uh things can go through and uh what they do is just in the heading of a proposal.

G

There would be a status field.

G

um I I know that stephen in a stock message mentioned the option of instead of putting a status on it, having an actual folder structure, uh which would make it a lot easier to see like ah these are all the things that we're that we've committed to doing, and these are the things that have been withdrawn, and these are the things that are still pending. um I, when I first read that it struck that struck me as it as a good idea, uh curious to hear what other folks think.

E

I didn't mean instead of the status field or just in addition to that, to keep it separate. um I think I think both are your status field also seems important if you're given a link- and you don't look at the url or something.

G

G

The silence says: yes, these are great ideas. Let's do it.

A

Any okay, great um here.

A

um Okay, that's great um anything else. Any question update.

A

Okay, I believe that's it for today. Thank you for your time and see you next week.

A