Nigel Jones: Hello, Dan!
Dan Wolfson: Morning, Nigel!
Nigel Jones: Hi, David!
Nigel Jones: Oh, hi! David!
david radley: Hi! Nigel! Hi! Done, sir!
Dan Wolfson: Just seven here,
David,
Nigel Jones: That's it!
Dan Wolfson: Well, better than what it will be in the spring.
Number three.
Dan Wolfson: Move ahead. Then it will be six Am.
Nigel Jones: Uh yeah, i'm not sure what dates We're always a couple of weeks apart. Aren't: we? That's always the the pain point. Hello, Chris.
david radley: Yeah, I guess it's for a couple of weeks, though. Isn't it just in the the handover, and then we're back to the same.
Dan Wolfson: Yeah, it's usually just a week.
Christopher Replogle: Yeah, I think the States are a week behind all. Typically,
Yeah, they're usually behind us
being rates. Sorry
Nigel Jones: it's an easy joke.
Christopher Replogle: Well, in time zone in uh daylight savings and a lot of things. We are a little bit behind you
Christopher Replogle: just the way the earth moves. Absolutely.
Nigel Jones: So i'm guessing that we'll expect in Mandy. We'll see if a couple more people uh join.
Nigel Jones: How are you doing. Chris.
Cezar Sîrbu: Hello!
Christopher Replogle: Uh just ping me saying the community call is in one hour, right?
Cezar Sîrbu: Yeah. I I just reset my uh zoom password so I can sign in, so I can join this. So
Cezar Sîrbu: always weird with zoom. I don't know
Nigel Jones: the shows join in as well.
Good.
Dan Wolfson: All good.
Nigel Jones: Yeah, it's uh it's It's looking a little bit nicer outside over here in the Uk on the south coast, because we had. We had a lot of wind and rain over the last few days, so it's quite pleasant to see some sunshine.
Cezar Sîrbu: We're starting to miss the rain here in
Cezar Sîrbu: Romania.
Cezar Sîrbu: Oh, it's very dry, is it? For drying. Yeah, no, it's not cool. It's dry and hot. Actually, it's almost the end of summer to still
Nigel Jones: It's pretty warm here. I think It's about sixteen, seventeen degrees. Hello, Mandy.
Nigel Jones: Fourteen. Actually
Mandy Chessell: sorry. I'm on mute. Hello! That's okay. Um, I mean, I guess we're a few minutes in. Do you want to introduce anything. Are you happy to get started? Monday? No, I'm happy to get started, so I, as Nigel announced on Slack. We're going to talk about Kubernetes and Nigel. I'm going to hand over to you.
Nigel Jones: Okay. Um. So I don't know if we're recording or not. I think we're We're calling in the cloud. So I'm: okay with that.
Nigel Jones: Okay? Or do you want me to switch it to local,
Nigel Jones: which is kind of what we're talking about with kubernetes? Actually, so that's the subject for today. So i'm just going to share my screen. Um, And
Nigel Jones: let's see if this will work.
Nigel Jones: Okay, actually, I need to put it to presentation to you. Hang on a sec.
Nigel Jones: Um.
Nigel Jones: Now, because all my windows move. So let's see if this my share dialogue Isn't working.
Um:
Okay,
Nigel Jones: I'm. Just trying to find where my window's gone to.
Nigel Jones: Sorry having a few technical difficulties to Powerpoint
Nigel Jones: and zoom.
I see
on that again.
Nigel Jones: All right. How do I get
okay, Found it
Nigel Jones: that should work. Can you see that? Yes, looks good,
Nigel Jones: Right? Okay. So this is what we're gonna talk about today, which is where we're at with the work that's going on around uh containers. So that's um. The basic containers as well as um How charts and operators and things of that nature. I think most of you probably know a fair bit about that.
Nigel Jones: Um. So what I was just gonna go through quickly was what we've got currently. Um, what led us up to this point? Some thoughts around um different people that might be using this content. So you know, kind of what are they trying to do um what might they need
Nigel Jones: uh some additional general thoughts, and that what might it mean in terms of the work that we we could do to improve this.
Nigel Jones: So ask questions, because this is very kind of rough content assembled from notes, and, thanks, especially to Dan and Lucia Mandy for the feedback. So far we've had a couple of meetings preparing up to this point,
Nigel Jones: so i'm just thought i'd go through what we have currently, so we have containers, so they run in docker or other container environments, and they're produced by our build processes, and we have a couple of different ones. We have um a corrigeria image, and this is built automatically every time we merge. And it's fundamentally the contents of our assembly that we talk about. This is where we get the service chassis, also the ui chassis. Some of the connectors that are based within the build,
Nigel Jones: and we create an image out of that,
Nigel Jones: and it's um, it's roches the Java application. It also is the service chassis by default. Um. It can also run nigeria ui chassis,
Nigel Jones: and it's based on a um image from Red Hat. They have these images called ubi images, and they've been kind of productionized and made a bit more resilient in terms of worrying about things like dependencies and security scans, and all that kind of stuff, plus some standard
Nigel Jones: uh configurations and monitoring um aspects. So it seemed like a good starting point.
Nigel Jones: We also have a Jupiter image, and that's built in Nigeria notebooks. Um repository. And that's really just using one of the standards Jupiter lab um images that that team provide, but with some modifications that we had to make to to make it work in a secure environment.
Nigel Jones: It'll be good to not have that. But we do.
Nigel Jones: We have another image called configure, which frankly, we don't need um. It basically just runs some shell scripts. So um, we can probably dispose of that.
Nigel Jones: We have our static content for the Ui, the work that shares us doing um, and that's currently um based on engine, and we have the react ui, which is our no based application for the multi tenant ui.
Nigel Jones: So you can use those containers as are they are published to do it io and key to Io um on key to Io. They do have scans against them, but i'm not aware of many people trying to use them direct anyone, really. So we mostly use them within the charts.
Nigel Jones: Um, And that's kind of important. Because if if you know whether we focus on making them available to other people or not may affect. You know how we develop them, or how we make sure that configurable or usable, et cetera.
Nigel Jones: Then we have our helm charts. So today we've got four of them or four main ones. I should say we've got a base chart which get basically gives you um a metadata server. Um! It does support persistence.
Nigel Jones: You get a view server, and you have the multi ten ui. It also has kafka, although it's not configured to use kafka, so it's kind of a bit unnecessary.
Nigel Jones: Um, and we have our lab charts. This is the one based on cocoa pharmaceuticals that we use in our dojos. Um, I think a lot of people have probably seen and use that one. So that's where we have multiple platforms. Uh, I think we have four, and then on top of that we have um a Jupiter
Nigel Jones: um application, and we have our notebooks loaded into Jupiter, and those notebooks will go through and configure things for coco um, Both of the Ui is included in that environment as well, and of course we have um kafka.
Nigel Jones: We have cts chart um, which is one that Chris initially put together, which is purely to run the conforms test suite, so that's run as part of our release process. Um. If you are developing a connector, you might also want to run it.
Nigel Jones: Um! And we have a performance test suite, which we don't really run. But um that is there, and kind of maintain to be deployable. But we don't really look at the results of it, and that's something else we can talk about.
Nigel Jones: So we have Kafka and all of these, and that's based on stream. Z. Uh, which is a operator, and it's open source, and it works really nicely. It makes it easy to to create to those clusters.
Nigel Jones: And so all helm charts are uh they? They really templates um. So it's really like a templating engine. So they're creating standard Kubernetes objects.
Nigel Jones: But you have templates which you kind of run at build time. So when you do it helm install. That's when the templating gets run, so you can um replace various values, and in the chart definitions themselves you can have some conditions. So you might have um a value for security on off, for example, and you could make use of that in your chart to deploy different things to Kubernetes. So this is all really done at install time. There is some support in the chart for for doing some uh things like updates,
Nigel Jones: but that's not really where we're helm sits. It's more about that initial deployment. And just think of it as templated documents,
Nigel Jones: and also depending on how you write the charts. You can make use of standard. Kubernetes features, such as a configuration maps, secrets um to a change the configuration even when something's deployed, or of course we've got the ageria Ui,
Nigel Jones: and Then, finally, we have the operator, and that's in a a separate um repository. Nigeria charts are in a repository called edio charts. The operators in kts operator.
Nigel Jones: And think of this as a a person really trying to manage trying, not just install but manage through the life cycle. Um, Nigeria working so it has to worry about things like how you might scale or um, making sure that things are reliable.
Nigel Jones: Um or monitorable. So you can actually see the state of things. So think of that really as some code that's running in the cub it's. Environment is responding to events, and then it's doing things based on those events
Nigel Jones: and configuration is done through custom documents that that we get to define. When we write that operator, we're not going to talk too much about the operator in the rest of this. Um, but it is. Uh it is certainly a an interesting piece of work, um, especially as we
Nigel Jones: want to make sure that a lot of these capabilities available to people running Nigeria. However, they run them. They need to be scalable. We need to be able to deal with failures. We've got things like a federated query. So it's a useful framework both to run and test that stuff, and and also validate things like Api's are there for detecting health,
Nigel Jones: because it's all about codifying what we need from behavior. But actually, in this this code for the operator,
Nigel Jones: any questions so far on the areas of we which we have, which I've gone through fairly quickly
Mandy Chessell: that it makes sense.
Nigel Jones: Okay,
Nigel Jones: Okay, I thought also it worth going back and and looking at how we actually got to this point.
Nigel Jones: So you may remember this chart. This goes back a long, long, long, long, long time. Um! And this was the virtual data connection connector. And we had this idea of doing this magic
Nigel Jones: um with accessing uh data resources through um business terms, but also in forcing um control and
Nigel Jones: um being able to mask data and and things like that. And we had atlas as a metadata source. We had um igc, and we've got elements of that now. But um the Vdc. Um vision as a whole. We kind of put to one side, and I think we're going to go back to this kind of thing. So I think what we see is a lot of this stuff reforming uh, maybe with some different components.
Nigel Jones: But when we have that environment or trying to create that environment.
Nigel Jones: There were an awful lot of moving parts, awful lot of different pieces, and you know, I know we. We tried to set some of this up in virtual machines, and there was some success in doing that.
Nigel Jones: Um! That could be error prone, not particularly portable and hard to maintain um through a life cycle. So if we add a new version of something, how do you redeploy that? And that's when I started creating the charts is is to say,
Nigel Jones: actually, can we somehow, to define? We We create this declarative documents that say what that infrastructure should look like.
Nigel Jones: And uh, you know, Kubernetes, that's exactly what it does. So that's why I initially chose to to write these charts, and so in that Vdc. Chart we had platforms we had Igc. We had atlas. We had Ranger, we not Ranger. We had Ranger
Nigel Jones: um her guy in Db. Of that postgres and we didn't finish all of the configuration of those different pieces. We did mostly the um Atlas, the Igc. The platform uh a little bit on Guy and and Ranger, and then didn't really finish the rest. Although there was a postgres database deploy. There was an old app server deployed with elder files, but
Nigel Jones: the whole thing didn't completely fit together in a scenario.
Nigel Jones: Um, but that's why um I created the charts initially,
Nigel Jones: and then um I did some hands on labs. I think it was probably thinking around two thousand and eighteen, and it was a pain because everyone's got a different environment. Um! So when you're trying to show people how to use the Apis. You've got to deal with
Nigel Jones: so many variances on platforms. Now I know we still have some of the same issue with with kubernetes, but to some extent we make it someone else's problem, be it?
Nigel Jones: I ran to a desktop or a cloud provider. But the idea there, and why I started creating the lab chart was to try and say to me, Can we kind of capture something together and that evolved? We looked at Jupiter notebooks. We developed our cocoa farmer scenario. We've built that up with a lot of content. And Amanda You've done huge amounts on that one hundred,
Nigel Jones: and we use it for Demos Labs education and all of those kind of things.
Nigel Jones: And so that's really where we got the lab chart from,
Nigel Jones: and then a little bit later. Um! I think it was a team working with Microsoft and Ibm team working with Microsoft, and they were trying to get agery up and running, but they were struggling a bit with the complexity
Nigel Jones: of both running it standalone as well as um. The cocoa charts um, so that's when I put the base chart together to say, Look, all you need is a simple server. Uh, you need the Ui, so you can go and look at um. The types and the instances that you've got
Nigel Jones: um, and you don't really need it all the rest of this complexity. So that's where that chart came from, and the trivia uh the Ibm team working with the trivia use that as a base, and they have actually proposed um updates to the base chart. But
Nigel Jones: there was some work needed to try and integrate it in to make it generic, so we could still do what we did before, and make it generically available, as well as specifically what they wanted. So there's ideas there. But the literal inclusion of those changes were a little bit more complicated, and, in fact, is still sitting there and not integrated.
Nigel Jones: There were also the um the Cts. And Pts charts, As I said that Chris did to try and make that effort to simpler,
Nigel Jones: so lots of ideas, loads of open issues spread around multiple repositories and different things that we could do
Nigel Jones: any questions on that section.
Nigel Jones: So now it was a case of saying, Well, let's take a step back and look at where we're at, and where we might want to go to.
Nigel Jones: So over the last week or so. I've had a couple of discussions with with Mandy, Dan and Luke. Show about um
Nigel Jones: the users and the use cases, and this is not fully fleshed out. This is very, very rough, so please jump in with any thoughts and questions here.
Nigel Jones: So the first kind of user that we thought about um was, and we can make these descriptions better. Um! Anyone who is wanting to get
Nigel Jones: started with learning about Nigeria. Um, so like we have with our dojos that are available. Of course, both online and sometimes when we run in sessions, or we might run a subset of them at a particular event.
Nigel Jones: Uh, We also use them for Demos sometimes. So we show Julia to others. At least we try to do that. The Linux open Source Conference, and then the technology doesn't work. But that's a long story. Um, but we use them for that purpose as well.
Nigel Jones: And so for for that kind of user they really looking for something that's that's
Nigel Jones: pretty simple, but guides them through learning a lot about the different areas in Nigeria. So it kind of needs to be self contained a fairly simple setup. They should be able to do it without a lot of help from us.
Nigel Jones: Um! It should be reliable. Um, but it needs quite a lot of stuff in there. Um! And that's really all of the cocoa content the samples and stuff that we have, because we need that to be able to explain the concepts. We need to be able to describe what the business problem is and how they work through that,
Nigel Jones: but it doesn't have everything. Um! And there are some issues that you know we we think are in there. Um, We got a little thing with notebooks. That's a technical issue to do with um the version isn't locked to the release unless there's working progress on that.
Nigel Jones: But one thing we don't have is all of our well. We do have our content packs, but our content packs the moment included because they're copied in from where they belong, into the aerial repository, which then allows them to go into the connector. So
Nigel Jones: we think this person needs those content packs. Um, and they do have them today. But we might want to change how we get them there.
Nigel Jones: But also, if we want to be able to talk about, let's say our Jdbc. Connector. So we talk about connecting to Jdbc. Databases. I'm sure coco's got some of them. We're gonna need that connector in that environment, and we don't have that today.
Nigel Jones: Um. So how do we do that.
Nigel Jones: Um. We also may have um sample files that that cocoa uses. For For example, the data that comes in from the medical studies, the Csv files um, they need to be able to share that. So maybe we need a file server in that environment for them to use.
Nigel Jones: Um. Coco also have a Corporate directory so held up. We probably want to talk about how we do that integration in the notebooks. Um, and describe how cocoa is using held up.
Nigel Jones: Um. We've talked about reporting there was some stuff done for Grace Hopper which um Dan did especially um, which visualize some of that information through superset, and We probably want to be able to show that in our demos and education,
Nigel Jones: as Mandy's test applications,
Nigel Jones: other possibilities include things like um enforcement. We've got open policy agent we used to use. Ranger. Maybe this is the platform. We talk about it
Nigel Jones: Um. Postgres in terms of both using Uh, that is a a data source. So I you know our postgres, Connector or Jdbc. Connect to be able to explain the business problem and then show a solution using that um, but also potentially postgres, being used by Nigeria for itself for storing things like stats
Nigel Jones: uh mentioned sample data. And also maybe here, if we explore an integration with other projects like open lineage that are ready to be widely shared. Because we think it helps
Nigel Jones: people understand what Igeria can do, and why it may be useful to you, then. That probably means things like open lineage we need to look at in here as well.
Nigel Jones: So that was some thoughts about what we might need for uh education, and some of the things that we don't currently have.
Nigel Jones: Um any thoughts on that
david radley: One one thing that just it. It sounds reasonable. I'm just wondering
david radley: how we choose what to do,
david radley: and don't. We need a stakeholder for a particular
david radley: use, case or or stakeholder that would articulate a goal um, for in the education case, so we'd know that what we were doing would actually have at least one consumer and someone that was passionate about it.
Nigel Jones: It's a good question. Um, I mean in in terms. I honestly like the education used cases. It's a bit like documentation that we have for Nigeria. It's it's almost like
Nigel Jones: I don't know how we can create something without explaining
Nigel Jones: what it is, and it's It's like part of the learning process for Nigeria
Nigel Jones: um. So
Nigel Jones: in that regard
Nigel Jones: I can't name a stakeholder, and I know that's what you're asking, but it feels like It's kind of every potential use of Nigeria out there.
Nigel Jones: But we, as our development team, who own Nigerian, write the documentation a kind of a proxy for that.
What? What? What? To other people think
Mandy Chessell: what I said. So I mean this list didn't come from
Mandy Chessell: the uh, you know we can just just make it did come from experience. And And are you gonna go on to the different used cases we talked about? Yeah. So going to cover some of the other things. Yeah. So I don't want to spoil your thunder there. But but we did go through our experiences of using them in different situations. The different organizations.
Mandy Chessell: Um! And from that um came up with these used cases which which Nigel will go through, and they identify different stakeholder types. So, rather than a name. They are types, and in some respects I would say that
Mandy Chessell: the three of us are the stakeholders in the fact that we do use them in different environments, and and and really anybody who gets involved in the discussion becomes one of those because they have,
Mandy Chessell: I need or use case in the background. I don't know if that helps you, David, or whether you think that's not good enough.
david radley: Well, i'm if I mean again, I think it's sort of um if you can get a
david radley: it can get a passionate stakeholder for a particular item of work. Then it everything becomes easier because they're they're driving it, and you're they might not be forcing the way we do it, I guess, in the absence of of that,
david radley: Then then, this approach is sort of um a best we can do. Approach, I guess
david radley: within, and I guess the the risk is that we do something that potentially
david radley: we hope that we've done enough investigation that we are going to get consumption of whatever we do.
david radley: But there's more risk that we won't. If we haven't actually got people,
Dan Wolfson: we use a lot of this ourselves. So in one sense, you know, taking the label on the top away for a second. This is what we use, as we do
Dan Wolfson: our demonstrations and our testing in our showcasing and other stock
Dan Wolfson: as well,
Nigel Jones: and we also
Christopher Replogle: sorry, Chris, go ahead. Sorry. Um. I mean
Christopher Replogle: coming from the fact that you know I have
Christopher Replogle: several times during the year people are reaching out trying to get figure out how to
Christopher Replogle: spin up a demo or what demo they want to use of. That integration is a great example.
Christopher Replogle: I end up with the same set of questions for them a lot of times. What do you want to, Demo? How do you want to show this. What do you have in that deployment? Right? Are they a postgrad shop, or they have this? Do they have that there's a kind of a set of questions to kind of drive a little bit about what you really want
Christopher Replogle: be able to integrate with. And then there's also the thing about what you want to demo or show, and the education Demo says that's also separate, unfortunately, from a production deployment where you really want to minimize what you have, and only deploy what's necessary.
Christopher Replogle: And And then, lastly, I think the hard part is really the set of questions to ask is the question. Once we have all the questions kind of that kind of leads us really kind of down the workflow of Okay. They've answered our questions. Now, how do we moderately put all this together to give them an environment that allows them to do what they need to do.
Christopher Replogle: I think that's my
Nigel Jones: kinda. That's where my brain get on this? Does that make sense? And maybe it'll make clear It' be a little bit clear when I go through some of the other charts. But um, I think also just to finish quickly on the education. Dem: I just want to pick up one point down made first um, which is, we use them ourselves, and and actually having worked through, you know the release. So it's actually pretty good test of a lot of capability that gives us confidence as part of that release process that we haven't
Nigel Jones: best things that really badly. I know we should have lots more automated tests, but in terms of something a useful asset that we have. It does help to bring all that together and provide some validation that we have a kind of working environment. So
Nigel Jones: that's almost for me personally. Um. The strongest reason why these charts work really well is because they help me when i'm releasing.
david radley: Sorry, David, go ahead. I'm sorry it's um. I was just saying. It sounds like we have. Well, two people that are all my stakeholders with Dan and Chris
david radley: and potentially ing may have um areas here which they would think this would be a big ben for the book if I got this in this space.
david radley: So it might, I mean, i'm just thinking of just in terms of process, I mean how how they, how you both might be more formally involved in some way like with with feedbacks and things. Or do you think that's just too too much like um too too much like agile, or
Ljupcho Palashevski: my
Ljupcho Palashevski: And because you you mentioned to me G um from that perspective it's really uh, then, has to come with more of a street to use cases and then develop against those I I I think the used cases we have with cocoa are sufficient enough so doesn't have to be
Ljupcho Palashevski: uh built from uh
Ljupcho Palashevski: other. I know it's fictitious, but I think it's still sufficient, and we have the knowledge to kind of
Ljupcho Palashevski: he he creative enough to to
Ljupcho Palashevski: uh
Ljupcho Palashevski: try to to have use cases there that showcase the the and and and actually teach about what the capability of fiberia uh capabilities are. So in that sense. I also do agree that this is, uh in in a way, we are our self stakeholders for this,
Ljupcho Palashevski: and so we do see a lot of interest like, for example, what Nigel said I'm, coming now from the perspective of so recently doing the release
Ljupcho Palashevski: quite useful to to actually validate the with the basic functionality. Still, there it's not broken. So
Nigel Jones: I I think in a I mean It's almost as if in a
Nigel Jones: a a real commercial product environment. The product manager would be kind of the key stakeholder for this kind of thing because it's about trying to grow the market right and trying to sell the product and and get people on board with it. So it would seem to be you almost targeting that product manager role.
Nigel Jones: Um, the closest we have to that is us, I think, primarily for this open source project because we don't have a separate product manager.
Nigel Jones: Um! Let me go through a couple of the other um
Nigel Jones: aspects,
Dan Wolfson: and then let's come back.
Dan Wolfson: I thought We'd also talked about, including Hex, Tdb: And this this tries not to. It tries not to talk too much about technology. I got a special section for that. Okay?
Dan Wolfson: Okay?
Nigel Jones: Um, I think it says it should be um
Nigel Jones: reliable.
Nigel Jones: Yes. Needs to be um
Nigel Jones: stable in the platform. Let me get to that bit later down.
Nigel Jones: Um. So another kind of use that we figured there was for these charts is evaluating. If you're a technologies, these may be other business partners or um product owners um, usually the
Nigel Jones: maybe a solution architect who's trying to look at whether Nigeria technology is for them, whether they want to um
Nigel Jones: work with it and it
Nigel Jones: it. It may go alongside the education they may get a ground in in the education. Um, but really they want to use it and play with it in their business. So the cocoa stuff just adds complexity. They don't want all that cocoa. They just want a simple server um to be able to um
Nigel Jones: play with metadata uh. They do want connectivity, probably, so they can get to some of their existing metadata sources, especially now we've got things like the Jdbc connection. Um, They do want to have a living environment, so it wants to be persistent. It needs to be reliable.
Nigel Jones: So for these kind of people. If you look at what we've got in the base chart at the moment, it's not really quite enough. I'll come onto what that is in a minute.
Nigel Jones: The lab chart is too much, and they could also course, run locally um, and just run the jars, and that's fine, but it's a bit more complicated to start putting the moving parts together. So I think, when we're not really satisfying this user as well as we are the kind of education. User
Cezar Sîrbu: uh Nigel does this somehow open up the subject of having and maintaining like uh, an actual environment for, like a demo environment
Cezar Sîrbu: in the
Nigel Jones: it's not something that I had thought about when I was writing these charts. No chezza but um. It is a a good question to ask about for sure. Um, maybe um. Maybe we should come back to that at the end if I go through the material and hold that thought, and we talk about it in terms of
Nigel Jones: that's at the end.
Nigel Jones: So on evaluation, some of the things that we we seem to be missing are Um. We have a lot of connectors which, when people evaluating the product be nice if they could use, you know, like our Jdbc connector or postgres connector, or maybe even our file connectors,
Nigel Jones: we have content packs that um shouldn't really be in Bassigeria. But someone evaluating the product would need them. Xdb:
Nigel Jones: um, as you mentioned Dan um as a resilient good example of a repository um that we can use for Nigeria probably should be there, so I got something solid to work with, and it's missing. Um, or rather they would need to have. I think the business ui! The base chart is missing. Uh that business. So ui! It only has the ecosystem Ui.
Nigel Jones: But if they're evaluating, they want to have all of that stuff, so we should make sure that it's in there.
Nigel Jones: These probably aren't people that are going to be playing with notebooks or wanting to work for examples. They could still run Jupiter externally if they wanted, but it's probably not that key focus. They don't, we think, want to be messing around with security plugins at least not ours. They might want to deploy their own um, but not ours. Um!
Nigel Jones: And there I think there's an interesting question about whether they need any pre loaded data. Um, Maybe that is just the content packs, and that's that's that's satisfies that.
Nigel Jones: So that's what my thoughts around. Evaluation of a zero would be. Um anything to add, Dan, especially
Nigel Jones: Mandy.
Mandy Chessell: No, I think you've got that Um, that that that really well, So we we, the these requirements, are coming from um. A couple of typical scenarios. One is when you got an organization that that wants to
Mandy Chessell: usage area as their message repository um, or their message to integration, capability. Um, And then the other one is a vendor wanting to do some trial integrations with their technology.
Mandy Chessell: And so those are the two main evaluation use cases that we see.
Christopher Replogle: Okay, the other one.
Christopher Replogle: I i'm on. Throw one more in there, and I don't know if it fits in the other two, not man. You can answer the question
also, using Nigeria as a bridge between two vendors
right
Christopher Replogle: where you could say, I've got metadata in two different systems. I want to integrate it, using Nigeria as a bridge. Is that really which one of those that fall into
Mandy Chessell: It's interesting because it pick. I think you've still got the two. You've got a vendor that wants to check that The integration works to another vendor that their customers are asking for. And then you've also got the um
Mandy Chessell: uh You've got the customer who's got two systems, and they want to connect the two together, so I think I think it's a good use case, and we probably should
Mandy Chessell: um put it on our list to remember that that is something that goes on that you're not just going to one mend. You might be evaluating to multiple,
Christopher Replogle: and then usually come from the people paying the bills, the people paying the bills I the customers for both vendors are the ones that usually ask for that use. Case. Um, they, wanna you know I've got. I've started to put data over here in this cloud, and I've got data over here in this cloud. I want to see the two sets of data of metadata connected together. How do I do that?
Christopher Replogle: And easily
Christopher Replogle: both cloud vendors have their own solutions? So you have to figure out how to integrate. So that's where I was coming with that one a little bit.
Nigel Jones: Um, but they all need to be configured. They all obviously have other systems that they connect to. So there is still the whole aspect of how you set that up that isn't really covered in. You know what's on screen here, which is more focused on the charts themselves. But it's an important part of being able to do that kind of evaluation. So I think there's a there's more depth, and we need to dig into this in in more detail to um to capture some of those other pieces in terms of how we improve
Nigel Jones: um people doing that,
Nigel Jones: and a related one um which Dan brought up, I think, was I'm just developing client applications. So I've I've purely got other systems that are interacting with Nigeria over the Api's be a Java or rest,
Nigel Jones: and i'm not sure that there's that much different to the evaluation um use case for this in some ways maybe it is evaluation. Um. So maybe i'm not explaining what this used case is. Very well. Um,
Nigel Jones: it's. Probably it's the fact that they're developing applications that use the Eigeria Api is the main difference.
Mandy Chessell: So one of the things when you're doing that is, you often do want the content packs. Um! I know it was. Sort of do we need that for the evaluation? But in this one, almost certainly,
Nigel Jones: I think. But for evaluation I was thinking. You know how, if you have no content, and you've got to put all the content in yourself, it's actually harder to use, and almost feels like you need some of the content packs for that reason, so you can sensibly get started, and once you've got, then the content packs in the evaluation, you know. Use case. I think
Nigel Jones: this feels very similar. Then, in what you are trying to think what the unique things are. Um, you need to be able to. You know how to use the Apis, but you do for the other one. So whether there's any different hit difference here, i'm not. Sure.
Dan Wolfson: Yeah, I don't know that there's a lot of difference. But one thing for us to come back to another time is
Dan Wolfson: which content packs. Do you want to invest in.
Nigel Jones: Yes,
Dan Wolfson: because the content acts off and reflect a scenario
Dan Wolfson: they do. I mean it should should, should next week. I I could take people through the contacts we have is that Western
Dan Wolfson: modularity, in a sense of for addressing what used Cases map to the combination of charts and content packs.
Mandy Chessell: Um, And so it is useful to for people to
Mandy Chessell: just to know that they're there, and and also to give some feedback on what else should we be capturing.
Nigel Jones: And so, yeah, you know, I agree. And and so another um aspect is what happens when you want to develop a connector. So you're um, maybe working for a vendor, or you're working as a client, and you're trying to build an integration. Connector
Nigel Jones: um to a area. So you want a solid base that you can work with um, which I think is the same as pretty much evaluation.
Nigel Jones: Um, But you also want to be able to um develop and integrate that connector into that environment. So a lot of this screen is the same as we had with um
Nigel Jones: with evaluation. But two things that Dan came up with, was It's hard to add, my connector sometimes. Can we make that easier? Um. So, for example, if i'm building it locally? Um, I want to be able to easily get it into this environment today. You can do this with um
Nigel Jones: a web, Url. You can put a url into the uh parameters used for the chart, which will cause it to download the connector when it initializes um. But could we make that a bit easier if you're working locally? Maybe it should be local or actually just making the directory rightable. So they really two quite simple small things. Um,
Nigel Jones: but are specific to right in a connector. And if anyone can think of other things that you need when you're developing an integration connector,
Cezar Sîrbu: are you also talking about? Maybe mocks?
Cezar Sîrbu: Is it on the same page.
Nigel Jones: When you say when you when you say Marx, I mean I don't mock up. But in in using them, in what context,
Cezar Sîrbu: not really sure. Maybe if you just want to to mark a part of the application, so that your connector is somehow
Cezar Sîrbu: instantiated world,
Cezar Sîrbu: you can somehow sample it.
Cezar Sîrbu: Of course, the
Mandy Chessell: of course, aligned with the way it works. But yeah, they connect to sit in the in the Java space. Um, And so they're dynamically loaded, and you can. There were quite a few best Api's to allow you to sort of
Mandy Chessell: manipulate it while it's in there. But typically you're writing it, building it and then running it in the runtime. So
Mandy Chessell: um! There's no sort of um mocking environment, but you know it's the the biggest thing, the big, the hardest part setting these up is the the thing it's talking to, because they're almost always talking to
Mandy Chessell: a a third party piece of technology.
Ljupcho Palashevski: So I think the mocking part applies to the previous slide, which is developing a client
Ljupcho Palashevski: um in a in a way. So if uh,
Ljupcho Palashevski: I think I think uh assuming from where it is is coming from. It is smoking. Some of the Uh Api's, for example, to develop
Ljupcho Palashevski: uh nice reach uh user experience. So if that's the case, then the first part where you are developing uh using this to develop a client
Ljupcho Palashevski: as the you high it's just a client.
I think it makes sense.
Mandy Chessell: Well, I
Mandy Chessell: So if you're the I thought the yeah for the client one. The assumption is, the Apis are already there. They're in the platform, and so I can't see the value of mocking them. No, no, not working. Using those Api's
Ljupcho Palashevski: provide you sample data to uh instead of um more kps. Maybe I should have put it uh better. Then you can build a Ui functionality with those May Api's that can really uh provide you sample date instead of actually mocking Apis. I think that's better to wait. To put it.
Ljupcho Palashevski: I know a lot of times during this life cycle of developing us. You need the data in a structure that is stable, and and this usually is done through a process of smoking uh, some Api specs. So you you provide the dummy data. But instead of doing that, I think you can use uh uh, this same uh container or image that we are discussing here.
Ljupcho Palashevski: Uh, as is is, you're using it in the same way to develop a client application. You can use it to develop ui application if I can.
Nigel Jones: Well, I guess the other. The other way you could do it is with a content pack, and that would be reusable. It'd be stable content that you could use. I think that's the key thing is that we're talking about needing some data to be able to um develop these client applications, whether they um, you know Java applications or the Ui.
Dan Wolfson: Well, but I think I think. But I think uh that Luke Show's point is still valid Right? I mean you can when you're building a new Ui, It doesn't matter if it's going to ultimately be part of Nigeria, or if it's local to a client
Dan Wolfson: uh
Dan Wolfson: it's basically a client. Application.
Dan Wolfson: And so if you have a stable foundation for that
Dan Wolfson: uh, that that that can use, you know, go against, then. That just makes one of the problems easier in building that you want, and then, later on, it can migrate wherever it needs to migrate.
Nigel Jones: So let me go through. I know we go, and you got fifteen minutes left, so let me go through um a couple of others. Um. So we talked about integration connectors, I think. Okay, repository connectors. I added this one in um. I think this is similar again. Um, but there is. There's something we haven't really talked about much, which is um
Nigel Jones: when you build a repository connector. You want to run the Cts tests and the Pts. Tests.
Nigel Jones: And um, we do have charts that do that. We We probably there is actually a fair bit of documentation in them. But as we, if we develop any venue connectors, we we probably need to sort out what we do with pipelines and things. So this is maybe straying off the charts a little bit more into development other than
Nigel Jones: we want to make this easy for other people right in repository connectors.
Nigel Jones: I don't know that this is the highest priority, because I think more people are going to be doing integration connectors than repository connectors. So i'm not saying this is a top priority. But um! This kind of user will have a different set of requirements, I think, in terms of what they want. It's the conformance testing being key part
Nigel Jones: um, and they may need to do this as part of a cohort, of course.
Nigel Jones: Um! And then we have production. Uh, and I think the thing that's different about production is that um, you know, people may want to build their own own images from source. They want to probably want to scan the source they may want to reduce. What's in those images?
Nigel Jones: Um, you know they want to make sure it's it's a good base, and that's why we do all the work we do around security in terms of a Baseage area as well as the containers. Um, but they might well take the docker file, modify it, build their own um, and again with with with charts. They're not really suited for production.
Nigel Jones: Um, because you. You want to worry about the behavior in a more operational environment, and to some extent I think that's where
Nigel Jones: it's a combination of documentation around how to use a German production, and also technologies like the operator, I think, can help here, too, and we can make that easier by abstracting some things away. And I think that's a whole different area of development around the operator. But I don't think the charts are um a good match um at all, really, for this kind of um approach. Now annotating what we've got makes sense, explaining how we did why we made choices that we did. Maybe people get inspired by that,
Nigel Jones: and they might use charts. But I don't think that should be a focus area for the work around our charts.
Nigel Jones: Any thoughts on that
Ljupcho Palashevski: I great,
Okay,
Nigel Jones: cool.
Nigel Jones: And then finally, Um, We've only touched very briefly on this Um, our Our own development team or people working on the base of Nigeria. Um a lot of the time, You know people are working locally. They want to be able to test and run things, and sometimes there are some integration challenges, whether it's the Ui and the base, or whether it's running in cohorts.
Nigel Jones: Um. But the needs tend to be very different, and also you want very rapid, turnaround time. You want to be able to change a bit of code in bacteria. You want to see that reflected
Nigel Jones: So I. There are tools that help to do this, and there are um pipelines that help to do this. Um, you know there's a lot of stuff on open shift that can help with this, which will um watch your file system for changes automatically. Build a container, deploy it, and then it's there very, very quickly.
Nigel Jones: Um. But I think that requires a lot more research um to to look at how that's helpful. And again I don't think it should be um a focus area of our current charts. I think it's quite a different kind of thing could still be valuable in terms of improving productivity.
Nigel Jones: Um, but it also can be quite varied, because when we're developing we're we're doing all sorts of different things. Um, So
Nigel Jones: I think we put this to one side a bit unless we come up with some wonderful ideas. But this is a little bit outside the focus of the charts. There is um a little bit around testing that we could do. For example, if you know, if we're testing a connector part of that pipeline when we build it, maybe it could deploy one of these helm chats. Maybe it's a completely different helm chart, and that could automatically provide the environment for doing testing as part of that pipeline. We tried that in the postgres um connector, and it does do the deployment. We just never wrote that
in this case.
Nigel Jones: Um. But I think that should be come part of our normal development test discussion as we add capabilities.
Nigel Jones: Um, and we we do it based on those needs. I think it's it's too soon to say we've got some generic master plan around how to tackle this.
Nigel Jones: Is that fair?
david radley: Yeah, absolutely.
Nigel Jones: Um.
Nigel Jones: But so so it's not that it's worthless. I think it's really really appealing. And if you were developing an application as part of your business. So you know the whole kind of devops thing where
Nigel Jones: um you know you make it very regular updates. It deploy to production, deploy to stage in areas, and you can also deploy to Sam pits for developers. You can be quite, I think, precise about that. But when we develop an open source project it feels as if it's It's all a little bit awkward, because we we never go to the you never really go to the deployment or production side of things. So we're only ever focused on the development side.
Nigel Jones: Um.
Nigel Jones: So maybe all I'm saying is, this is probably a topic in its own right to think about. How could we make this better? So, you know, let's branch fork it off as a kind of a separate discussion if we want to pursue it around. How do we improve developer productivity,
Nigel Jones: and whether we can then, you know, demonstrate some best practice that could help clients in how they develop things.
Nigel Jones: Um! But again you've got why you develop in the base. So you develop in a connector trivia or just developing a connector. So that's quite different to develop in the base. So maybe it's a variation of the developing an integration connector um scenario
Ljupcho Palashevski: just to Cross-check something, Nigel. This is also
Ljupcho Palashevski: uh almost one on one we the issue we have open and we are trying to uh address from the last workshop. We had right.
Nigel Jones: Um, I don't know if we uh yes, I think I did open an issue You're right. Yes, that was. That was my thought behind it. Um, but um!
Nigel Jones: The the the main issue here is, there seems to be so many variables.
Nigel Jones: Um, so I I do think it's valid, and I do think your points important, David, about how how can we make it easier? Um!
Nigel Jones: I I just think it's a beefy problem in its own right, so we can't really do justice to it, combined with everything else. We need to probably take it out as
david radley: something separate,
Nigel Jones: but until then we could probably, and it depends. It's too stakehold. We know one of those could be an external stakeholder if it's the um, the integration developing an integration connector, maybe there is a hook on that use case. When I wrote this section my thought was our development team I the core developers in Nigeria,
david radley: and of course we are the stakeholders for that. One of the problems was that if you, if you wanted to deploy a Jerry a call, then at the time the build was, was very, very long, was moving to Gradle might actually help with this as well.
david radley: Yes, I know we got great at the moment, but we at the time we were using um maven.
Nigel Jones: Yeah, no, that makes sense. That makes sense. So I think there are value. I think you're right that there's value in elaborating, maybe, and thinking a bit more about some of these sections. Um, I think I think the other point that we made around this at the workshop
Dan Wolfson: is that the tools and techniques are evolving very rapidly around this.
Dan Wolfson: And so, you know, we just have to
Dan Wolfson: keep an eye out on what looks interesting. And when people find something interesting, then maybe we have a discussion.
Yeah,
Nigel Jones: yeah, that makes sense.
Nigel Jones: Okay, Um, let me move on to. I want to just mention security because I felt I should. Uh, I think I did touch on it briefly.
Nigel Jones: Uh, we creating these containers lots of executable code. They are scanned on key to I. O. Our base container is in a great state. We need to make sure. The other containers we've got are also clean. I know at the moment the engines one is not um. So we do have to address that, I think, because we should show best practice and
Nigel Jones: ensure that the artefacts we create are as as as they should be,
Nigel Jones: and also throughout the containers and the charts. Um! We have got to just get to grips with the configuration certificates which we talked a lot about at the face to face meeting. Um, So that needs to be reflected in in this work as well.
Nigel Jones: So now I was going to summarize where I think some of the work that we need to do sits
Nigel Jones: um. So firstly,
Nigel Jones: in terms of containers, i'm assuming that we're only using them in our charts and operators, they're not. They're not first-class thing the people we use, and I know they're out there and there is some documentation on them. Um, but I don't I none of our used cases have really. We haven't really thought or talked about that, and That's partly because the jury is formed of a lot of moving parts.
Mandy Chessell: I I if you remember the very first ojo I used. I use the docker image.
Mandy Chessell: Um! But there's so little you could do with it, because there was no, I think I remember the right time at the time that you did a little bit, and then it was
Mandy Chessell: Yeah, you you you just ended up switching to a multi
Mandy Chessell: um server environment, such as the home chart. So that's what we see it. It was tried, but um uh, I think it. They probably will get used by somebody who's building their own home charts, but that'll be it
Nigel Jones: so. What I think we need to do in the in the containers themselves is, Let's address those security concerns.
Nigel Jones: We we've got this concept of need in a connector that is more than just baseage area. We need to um, because that's built as part of the Ageria repository. But we've now got these other connectors and content packs that are spread around other repositories, and I I think it's becoming clear that we have scenarios that need that content. They need to connect us to be there, and they need the content packs to be there. So the the
Nigel Jones: well, there's multiple ways of doing that. Um, You know the dynamic loading is something that's in the chart today, but it's a bit cumbersome.
Nigel Jones: Okay. I've I've I've I've I've I've clicked on a link I shouldn't have done Sorry I've done it before, too, and we also have the content packs. Um! So there's a little subtlety in terms of how much is baked in. How much is, for example, retrieved for um get on startup. But we certainly need for these scenarios more of that to be put together, and I think, therefore, we need a big, bigger, combined image. Um that can be used in these places.
Nigel Jones: So that's I think, one additional piece of work to be added, there may be other development tasks that need specific containers like, say, we do some work with Atlas, but I think that's driven really by the development test. Um, General, you know, work as opposed to um what we're doing around these other use cases.
Nigel Jones: Um, there's been a couple of issues come up around reliability and and size, and
Nigel Jones: uh Vms crashing. Um. Sometimes the start at time seems a bit long, so I think there are some things we don't fully understand or Haven't looked closely enough around resource requirements to be honest. That's probably more broadly an image area, and I think, as we go towards production used cases. There's a a bit of a concern there,
Nigel Jones: but it's almost as if these um the the charts and the stuff around the operator, I think, helps to drive some of these, because you're trying to do things like with with the operator, for example,
Nigel Jones: uh trying to make sure that if you kill off a a container that um, you know they operate and automatically manage it coming back and at a process level. Yes, of that's totally reliable. But we also have to make sure that we we don't lose data. We want to know how long it's going to take to come back. Um! What's the footprint when you've got lots of these running. So I think there are some of these operational concerns we'll start to touch on that may impact some of the containers.
Nigel Jones: Um, we've got this to zero configure container we don't use that's a small thing. Um, and we should continue with this refactory. We're doing of the call pulling out these pieces, we don't need simpler, more secure image. Um!
Nigel Jones: And then they can be added back into the um. Yeah. Interesting question to the big image, so we make it smaller, and then we make it bigger again. Hmm. I'm. All that through. Okay,
Nigel Jones: um. And then on the base chart. So this is the one that has a single server at the moment. That configuration is a nice starting point. Um! But we need to use the the bigger container. We want to use the one with the connectors and the content packs. Um, I think we need xtdb in there with persistence. The default.
Nigel Jones: Um, Also we should make it for reuse, because I see that.
Nigel Jones: Um The stuff i'm talking about here is common also to the lab chart, so stuff that is just needed for the base use cases we put in the base chart, and then the lab chart becomes an extension of that. It can have the base chat as a dependency, or we can pull out other things in in common ways.
Nigel Jones: But let's try and do some refactoring for that. Um,
Dan Wolfson: yes, Then one one naive question. Um, you say, use xcd with persistence by default.
Dan Wolfson: If we used x to be x t Db.
Dan Wolfson: With and had both a persistent and non- persistent in memory. Option.
Dan Wolfson: Would that mean that we don't need the in memory
Dan Wolfson: repository anymore?
Nigel Jones: Um. Well,
Nigel Jones: my initial feeling would be to leave uh the in memory as an option.
Nigel Jones: Um! Just not to have it as the default. Um,
Nigel Jones: but
Nigel Jones: you're right that if we had, you know the the chance at the moment have persistence uh as a configuration setting, so you can make them persistent or not persistent. So this is really just saying the same two things. One is saying what the default is, and the second thing is, it's effectively saying, we need to add x, T. Db.
Nigel Jones: Um. So if we want to add X. T. Db. As in memory as an option. Um, I think that makes sense, too, and and probably will be part of the development process to get to the point of having next Ddb. In the chart.
Nigel Jones: Um. But if you look at um also what we need with the operator, which i'll get into again. There we have to have X. T. Db. In that configuration, because it's the only thing we've got to that uh
Nigel Jones: that can work in that way with with shared um back end.
david radley: So that will be the easiest, simplest configuration, so that we've already got that.
Nigel Jones: Yeah. So I I think it's a good point that the base Ch. It would be good to support X. Cdb. Of memory.
Nigel Jones: But I think the statement still correct that it should be with persistence by default.
Dan Wolfson: That's fine. I just
Nigel Jones: that it might simplify things. It's it's it's a good. It's all all all sorts of good ideas. Um, I think we need postgres on the business. Ui in here And, Dan, this is yours. No port configuration
Nigel Jones: out of so no ports. So where um the pods network accessibility to the pods is made available on the Kubernetes nodes themselves directly with no fancy, low balances or anything like that.
Nigel Jones: So if you're running in a kind of local environmental environment. You have full control over, and it's all yours. This can work really nicely, and it's actually how I started doing the charts.
Nigel Jones: Um. Of course it all fails when you're working in the shared environment or out on the cloud, because you don't have necessarily control over those um those nodes, but as a default. Um for people who want to get started with the middle amount of effort. Um, I think it makes sense to go back to this um as the default,
Nigel Jones: and we're not going to entertain server replication stuff in the base chart to keep it simple.
Nigel Jones: Then, for the lab chart um thought on this is we factor, so that we use the base chart as a dependency. So we have all the common stuff in the base chart. Um,
Nigel Jones: and of course that means, then, that we need to add in um the additional platforms and gypsy, and that I books and stuff that we already have in the live chat,
Nigel Jones: but also the other pieces we've talked about cocoa wanting, so that's held up. Super set a shared file storage of some kind. Um. Obviously there's security connectors, although that's done by the notebook rather than any script in
Nigel Jones: um. And there is a an an issue outstanding around Pin in the Jupiter chart versions, which um is partly done, and I realized I need to talk to loop to more about. So um! I'll talk to you, Luke, to about that separately,
Ljupcho Palashevski: sure,
Mandy Chessell: and that and that comes from the fact that um i'm adding more labs Um, but they need later versions of the area. So we What we want to do is to make sure that the version of the Jupiter charts is is in line with the level of Nigeria that you're running.
Yes, that's right.
Nigel Jones: Um. And then finally the operator I won't. Talk about it too much. Here, there's a whole project on it. Um! And that's obviously around the operation. But Xtdb is probably one of the crucial. The next step right? The crucial step for that, and no doubt there'll be. There is a helm chat, in fact, to test the operator. But that's part of the development process of the operator, and ultimately it will be a demo that, using the operator, I think, uh long term we can expect that our use of Theigeria container within uh the existing charts may well be replaced by used to the
Nigel Jones: but that's that's a later thing down the road.
Nigel Jones: So I think i'm all almost there because we're out of time. Pretty much um. So my thoughts on this so far is obviously this: We've got a lot of issues and projects that I've opened at random times. I need to go back and consolidate some of that. Um. Some of the simpler changes, the incremental changes probably could warrant um slightly clearer
Nigel Jones: mit
Nigel Jones: um, because you moving things around that needs a bit of experimentation. Probably the operators is is the hardest work, but I want to try and make figure out how we represent that in get, and also how we make it easier for other people to contribute, because I think that's going to be key,
Nigel Jones: and, in fact, at the bottom um, you know, maybe If there's any interesting parties, we have, say, a work group meeting at least once a month to talk through where we're at in more detail, like we've done recently.
Nigel Jones: Uh, and also um. Anyone on this call to extra help is is wanted to needed, whether that's some requirements, or whether it's um working through some of the get changes, or you know I've had a discussion with lecture on the operator. Um! We need to work out how to expand our um
Nigel Jones: capability in terms of resourcing on it.
Nigel Jones: One other thing that's come up that I should mention is that
Nigel Jones: if someone can new to Ageria, they come along to the Nigeria Project Org, and now they've got a nice button to star. What some projects have is a kind of try it Now link um! And The idea of this is what is the simplest thing that we could get them to do that. Let them see what Nigeria is.
Nigel Jones: I don't know if that is, you know the laptop's got a lot in it. It almost feels if it's something simpler than that. But I think we might want to think about what try it now really means.
Mandy Chessell: Um looked like you were running a demo, but in reality I think you were
Mandy Chessell: a Powerpoint that um that basically had a demo running in the background, but with Bubbles coming out going. Look at this and look at this, and look at this and and and actually, that's quite clever, because you're not requiring any. You know it. That's funny in the browser. Um, but it does give you
Mandy Chessell: um a feel of it.
Mandy Chessell: I think it's a nice idea, I think, for me as a developer I still would want to kind of run some. So maybe it's two, but it's almost like a see it now and try it. Yeah. So so the other is the lab charts. I presented one last week, and there was real dislike of them.
Mandy Chessell: Um, because of the fact that we use monitor space text on the output.
Mandy Chessell: Um. And so i'm not sure. I'm very, very yeah. When I shared the lab charts. It was like, Oh, this is horrible, because it it uses monitor Space text. When we're running the bits that we run come out and honest by text. Um! And so that's why i'm worried about spending time showing these to people.
Dan Wolfson: Yeah, but I think I think, Mandy, what we talked about last week was to investigate a few chart widgets and table widgets, and see if we could. Pretty that up. And
Mandy Chessell: uh, you know, i'm happy to take a look at that. Yeah, So I did. I did look at it. Um. And what makes then hard to do is to find out because we've got a lot of description about what you're looking at.
Mandy Chessell: Um, and it's then becomes difficult to distinguish what's just text and what's running? I mean at the moment It's very, very clear because of the fact,
Nigel Jones: the output. So we in monitor space text, but but it but again it we it there. There was a lot of negative vibes from from showing that maybe this goes back to the use case. And maybe, you know, I I had added um tutorials education and Demos together. But maybe that was wrong. And actually, there should be separate to demo use case, because I think maybe what you want for Demos
Nigel Jones: is is prettier is simpler that that we have in things like the notebooks. Now, if you happen to launch it from the note. But maybe that's okay. But they want to see different things. So maybe
Nigel Jones: maybe it should be a pretty demo. Yeah, maybe it should be pretty. Yeah, It needs to be pretty and cool and probably much quicker. It's not a four hour, Dojo. It's a um five, five minute plus world through Nigeria, or maybe there's a an extended play version as well. But it's that kind of thing. Um.
Nigel Jones: So maybe that demo use case is different.
Nigel Jones: So we should. We should definitely think about that.
Nigel Jones: I'm conscious we've gone way. We've gone rather a bit over.
Mandy Chessell: Yeah, but it was really good that that your summary has been super. If I um.
Nigel Jones: I know what you had on Monday. That's really good. You done cool Well, um I mean i'll put it. I suppose we can add it to the a link to the Wiki. So if anyone's on, and would like to make, you know, make further comments, or or wants to contribute to whatever, then we can set up other calls, I I do think maybe having uh finding some interested parties and having a special work group meeting on this stuff at least monthly, could be a good idea.
Dan Wolfson: I mean, I'm certainly willing to stay
Dan Wolfson: participating,
Dan Wolfson: being the guinea pig, and maybe even being able to contribute a little bit less, you know.
Nigel Jones: Yeah, that would be. That would be really helpful. I know who shows volunteered as well, so that would be great. Um! And i'll have a think about how to clean up what's in in get, and how to figure out how we might track some of this
Um,
Mandy Chessell: Rachel: Thank you so much. Yeah. So next week we'll go through the content packs. Um: And hopefully, that will make sense in the light of Uh Nigel's discussion on kubernetes.
Mandy Chessell: I think it's important. Actually.
Mandy Chessell: Yeah, Okay, Thank you so much. All for joining.
Nigel Jones: See? Talk to you next week.